Re: Interpreter for old basic programs from the line number era

On Mar 6, 5:26=A0pm, Guy Macon <http://www.guymacon.com/>
wrote:

> >There's Cheesecake BASIC V 3 that does.
>
> >http://noktosoft.megafolio.com/
>
> Now that is cool! "Cheesecake BASIC is written in BASIC, and
> can be compiled with the PowerBasic Console Compiler (2.0 or
> above), with QuickBASIC 4.5, or with Cheesecake BASIC V3"

I did some research on this compiler but I never published my
findings. Too busy, I guess.

V1 and V2 were interpreters that were similar to QBasic and they can
even run the gorilla program (as least V2 could run gorilla.bas - I
never tried V1).

He shifted gears in version 3 because he wanted to try writing a
compiler that generates a p-code type of pseudo language that he then
interprets at runtime. This came in a DOS and Windows flavor. The DOS
flavor still supported DOS graphics, but the Windows one did not
support graphics. The Windows flavor had to be compiled with Power
Basic for Windows, or by itself. The DOS flavor could be compiled by
Microsoft PDS, or Quickbasic 4.5, or Power Basic for DOS.

His runtime interpreter was written in Basic and compiled, and was
glued together with the p-code generated by compiling user programs.
This made stand-alone .exe programs. At runtime the interpreter would
fire up and then start executing the p-code by reading from the same
file that it was running from. To make things more confusing he called
this interpreter an "RTL", which most people assume is just a runtime
code library. Many people mistakenly thought user programs were
compiled to machine language because they saw the .exe stand-alone
outputs (of course, Quickbasic did this also).

However, despite the cool design, there was a problem with version 3
and that's why it died shortly thereafter. The runtime performance of
compiled programs was horrible! His version 2 interpreter was much
faster at running programs.

It turns out that he selected his p-code instruction set based on
making the compiler easier to write. He wasn't really thinking about
runtime efficiency. And the Basic code for the runtime intepreter was
elegant but quite inefficient.

He made an effort to fix the problem by writing a new runtime
interpreter in C. By getting closer to the metal and using pointers
instead of arrays, he figured he could make that part of it much
faster. But he never really finished the C interpreter.

Remember that the term Virtual Machine is just a fancy term that means
the runtime interpreter that executes the p-code instructions. "cvm"
is the Cheesecake virtual machine. Once this is compiled it is called
the "RTL".

The main parts are:

  ccbasic.exe  (32 bit windows compiler, comes from PB compiled
               code, only has a 32 bit version)

  ccwinrun.exe (32 bit windows interpreter/VM, comes only from
                PB compiled code)

  ccdosrun.exe (16 bit DOS interpreter/VM, comes only from
                QB or PDS compiled code)

  dos.rtl      (embeddable 16 bit DOS interpreter/VM, comes only
                from QB or PDS compiled code)

  windows.rtl  (embeddable 32 bit windows interpreter/VM, comes
                only from PB compiled code)

These C compiled programs are in the SRC\C\LCC subdir:

ccrun.exe - a CC basic VM for Win32. This can run foo.exe, but
            only in debug mode - this is not a finished program.
            It only outputs status info and doesn't run anything.

foo.exe - a compiled CC basic program that prints 3 when run. This
          has an embedded CVM interpreter. He got this by executing
          "make foo.bas" inside CCBASIC.

Although the compiler can theoretically compile itself, none of
the .exe's he released were compiled by itself. Maybe he wasn't
completely confident that it was bug free. I never tried the self-
compiling thing to see if it worked.

Why did I study this compiler? I wanted a cross-compiler than can
generate code for a microcontroller, such as the AVR. My plan was to
finish his C runtime interpreter, but have it compiled by a cross-
compiler (gcc for the AVR) so it can be embedded in a chip's flash
memory. A p-code type of compiler is much easier to work with and I
would hopefully be able to leverage most of the work he's already
done. I never got around to finishing this.

Freebasic is a much better compiler but is x86 specific and would be
extremely difficult to port. The Freebasic code generator and
optimizer are tightly bound to the compiler and there are no p-code
files anywhere.

Eric