Author Topic: C BASIC Runtime  (Read 18542 times)

Mike Lobanovsky

  • Guest
Re: C BASIC Runtime
« Reply #15 on: May 21, 2014, 10:21:22 PM »
This is exactly what I'm talking about. If you manage to describe the above-mentioned ring allocator as a multiline #define (a macro), your preprocessor will re-duplicate (expand) a new instance of entire ring allocator into each and every function that would happen to need to create even a single temporary empty string variable. The same happens with C functions carelessly declared as inline - they ceise to be regarded as standalone functions and are treated as preprocessor macros, i.e. re-duplicated (inlined) in each place where they happen to be "called".

This is how you end up with 60KB of C-equivalent machine code where you're expecting to see 6KB at the most.

You need to resort to genuine C functions instead of a simple header file if you want to have worthwhile BASIC-to-C translation. You can't beat Kevin Diggins on that. :)
« Last Edit: May 21, 2014, 10:43:02 PM by Mike Lobanovsky »

Offline John

  • Forum Support / SB Dev
  • Posts: 3510
    • ScriptBasic Open Source Project
Re: C BASIC Runtime
« Reply #16 on: May 21, 2014, 10:31:42 PM »
The BaCon libraray is linked in with only the runtime functions used. The memory manager (MyAlloc) is a set of functions and called when needed. That doesn't pan out with what you are saying.

Keep in mind that BaCon is a text to text translator. The end result is C code. I see no difference making C's already BASIC like flow look more like BASIC with symbol substitutions and doing what BaCon does now calling it's runtime. I'm just skipping the text to text translation step.

This is the #define for CHOP(). (see CHOP C BASIC runtime function above)

Code: [Select]
#define CHOP(...) cbrt_chop(__VA_ARGS__, 0)


« Last Edit: May 21, 2014, 10:53:54 PM by John »

Mike Lobanovsky

  • Guest
Re: C BASIC Runtime
« Reply #17 on: May 21, 2014, 11:30:20 PM »
Even if your task is obviously hiding the ...-to-C stage of translation from the user's eyes by letting the C compiler read your C BASIC header and use the BaCon library with or without the addition of MyAlloc for immediate compilation, you will not get by with a C BASIC header file alone. You need much deeper parsing capabilities to efficiently translate Dim ... As String and similar declarations and other BASIC language features to equivalent C.

Forget the header file. Write a simple recursive descent parser that would turn your canonical-BASIC "X BASIC" or whadayacallit sources into decent C equivalents without those horrible semicolons or neoteric BEGIN_FUNCTION placeholders. In short, go the BCX way and try to keep your "X BASIC" syntax closer to tradition.

I repeat I do not see any sense or benefit in C BASIC over BCX. The latter does a much much better job of converting a BASIC-style dialect to C. Replace BCX' ring allocator with your MyAlloc routines if you want to. What's the problem of forking the open-source GNU GPL BCX project for that if you wanna stay open-source all the way through yourself? Disgust towards that Kevin Diggins character? ;) Come on, John! :D And you can simply add a BCX post-processing step of automatic C compilation and immediate deletion of intermediate C code files from your disk. What else would you want or should the user need and why?

Offline John

  • Forum Support / SB Dev
  • Posts: 3510
    • ScriptBasic Open Source Project
Re: C BASIC Runtime
« Reply #18 on: May 21, 2014, 11:44:34 PM »
For grins embed in FBSL a BCX version of the C BASIC like integer Mandelbrot benchmark of Ed's. After about 5 pages of GLOBAL defines, we might start seeing user code and then more pages of runtime code with IF switches in case the function is used.  :o

Sorry, not interested.

Mike Lobanovsky

  • Guest
Re: C BASIC Runtime
« Reply #19 on: May 21, 2014, 11:51:22 PM »
After about 5 pages of GLOBAL defines, we might start seeing user code and then more pages of runtime code with IF switches in case the function is used.

Sorry to say it John but that's the only way to keep a BASIC-to-C translator syntax consistent, reliable and fool-proof on both ends.

Offline John

  • Forum Support / SB Dev
  • Posts: 3510
    • ScriptBasic Open Source Project
Re: C BASIC Runtime
« Reply #20 on: May 21, 2014, 11:59:36 PM »
Look at the Script BASIC GFX extension module I did with C BASIC on the C BASIC Bitbucket site. Looks like a BASIC program to me and I haven't added in the BaCon runtime yet.

C BASIC is not a translator. It is a C preprocessor overlay and BASIC runtime library. As one starts feeling more comfortable with C, the programmer can ween them self off the C BASIC crutch. It's that simple. Think of C BASIC as your first paint by numbers set.  :)
« Last Edit: May 22, 2014, 12:26:47 AM by John »

Mike Lobanovsky

  • Guest
Re: C BASIC Runtime
« Reply #21 on: May 22, 2014, 12:28:14 AM »
Ay-ay captain!

But put me ashore first. :D

P.S.

Quote
besSUB_START
  DIM AS long *p;
  besMODULEPOINTER = besALLOC(sizeof(long));
  IF (besMODULEPOINTER EQ NULL) THEN_DO RETURN_FUNCTION(0);
  p = (long*)besMODULEPOINTER;
  RETURN_FUNCTION(0);
besEND

besSUB_FINISH
  DIM AS long *p;
  p = (long*)besMODULEPOINTER;
  IF (p EQ NULL) THEN_DO RETURN_FUNCTION(0);
  RETURN_FUNCTION(0);
besEND

You can prepend your function declaration list with an __attribute__((noreturn)) attribute and your GCC will allow the redundant trailing RETURN_FUNCTION(0); statements to be omitted from your pseudo BASIC Subs.

Offline John

  • Forum Support / SB Dev
  • Posts: 3510
    • ScriptBasic Open Source Project
Re: C BASIC Runtime
« Reply #22 on: May 22, 2014, 07:59:48 AM »
Getting back to the original request.

Anyone have any ideas how we can emulate BASIC like string usage in C BASIC?

I'm looking for a BASIC like way to do string assignments.
« Last Edit: May 25, 2014, 04:35:39 PM by John »