Yab to C converter

[SamuraiCrow]

I know a technique to write a Basic compiler using C or C++ as a backend. Currently the stand-alone executable codes from Yab appear to just link an interpreter to a zipped copy of the source and I think I can do better.

Since BASIC isn't fully structured it'll have to be written using a Switch command in a While loop to act as a state machine. Also, to implement declaration of variables on-the-fly, it will have to be a pass-and-a-half compiler. That's a fancy way to say the compiler will have to write to a header file or so at the same time as the C source that includes it using its preprocessor.

Is there interest? My goal is to have some code written to serve as an example for another BASIC compiler I want to write. I may need help with the Haiku runtimes.

[bbjimmy]

To work well with the Haiku GUI, one would have to incorporate some c++ to make the appropriate calls. The yab source code could be used as an example as yab uses c and c is ueed to cal c++ wrappers to call Haiku GUI elements.

[SamuraiCrow]

Thanks for your reply! I'll see what I can do.

[SamuraiCrow]

After looking at the YABASIC parser source, I am not quite familiar with Flex and Bison so I may have to start my YAB transpiler some other time after I have finished the Kitten transpiler for running AmosPro on AmigaOne PowerPC.

[SamuraiCrow]

I'm getting around to looking at the Yab source again.  I may yet be able to make a transpiler to C++.

[bbjimmy]

Any progress? this would be great!

[SamuraiCrow]

Any progress? this would be great!

Sorry about the late response.  I'm trying to stick to one project at a time.  I'm certain it is possible to do.  I just recently got a day job but with some help, I'm certain it's possible.  The hard part is finding the time to figure it out.

The central aspect of the runtime consists of an intrusive singly linked list stack as a base class.  The activation records of each function extend that base class by creating a record of all the local variables.  Because function definitions can't be nested inside each other in Yab, the definitions will be written one after another in the call_stack.h file.

The global definitions extend a class containing the stack pointer and any other static runtime states.  This gets written to the heap.h file.

The actual executable code gets written to the main.cpp file.  However, since some BASIC commands are not strictly structured ordering we can't use structured C++ as a representation of them and therefore are implemented as labels and branches.  The way to do that in C++ is to use a simple state machine.  The runtime errors are defined as a list of consecutive constants and every additional state is an extension of that list.  The error constants along with all nonvariants of compilation are in a fixed header called yabcompile.h and the additional states are written to states.h as we go.

This only leaves the state machine itself.  It will be formatted as a while loop containing a switch statement.  The case commands within the switch statement will signify the destination labels.  A jump statement is represented by assigning a label constant to the state variable and issuing a break statement.  This loops back through the while loop reentering the switch statement.  An example main.cpp file might look something like this:

while (state>endWithoutError) {
   switch (state) {
      case start:
         var1=0;
      case do1:
         printf("var1=%d\n", var1);
         var1=var1+1;
         if(var1<10) {
            state=do1;
            break;
         }
         state=endWithoutErrors;
         break;
     }
}

That should give you an idea how this can work.

[SamuraiCrow]

Continuing from where I left off yesterday, I know how to generate the C++ code but interfacing to the parser is where I start to run into trouble.  A fully implemented parser may not lend itself to the "stone soup" approach of adding pieces little by little.

One central portion is the expression parser.  If it generates a parse tree, converting the expression to C++ format may be as simple as implementing a inorder traversal of the tree, even if it generates a lot of extra grouping symbols.  Complications include function calls because our non-structured call-stack will need some extra work to produce inline results from the equivalent of preloading local variables into a class structure and invoking the equivalent of a Gosub and having a temporary variable to copy the returned value into before executing a Return command.  Perhaps passing a pointer to the result variable into the subroutine will work.

[lorglas]

Hello,
you have a big project ahead of you. Please take a look at yab.besly.de for an explanation of how to use flex and bison. I have a request. Please do not use the name yab for your project so that we do not get any collisions between the programs. We may also have to consider whether we have to rename yab, at least in the file extension, because I'm trying to port the original yab without the gui elements from haiku. furthermore I have a yab-sdl in mind.

Regards lorglas

[SamuraiCrow]

Hello,
you have a big project ahead of you. Please take a look at yab.besly.de for an explanation of how to use flex and bison. I have a request. Please do not use the name yab for your project so that we do not get any collisions between the programs. We may also have to consider whether we have to rename yab, at least in the file extension, because I'm trying to port the original yab without the gui elements from haiku. furthermore I have a yab-sdl in mind.

Regards lorglas

Since the other branch of Yab is actually not called Yab but YABasic, the name should be clear which is which. As for the suffixes, I'll be using .cpp and .h for the ouptut so that shouldn't be as ambiguous as the .yab file extension. I'll just make it accept the file input from the command line with whatever file suffix is on it without a specific check. If you and BBJimmy do change the name, I'll reflect the change in my repo also.