D3 FlashBASIC History and Usage
Questions frequently arise in forums about how FlashBASIC works. So I thought I’d summarize it here.
First, a primer on compilation and object code in general
Pick BASIC source code is not compiled down to machine code, it’s only partially compiled down to what is called PCode. PCode is what results when you compile source down to an intermediate, human readable set of instructions (tokens) that are just a level up from assembler.
There are two separate engines required to process BASIC code, the compiler engine and the runtime engine. If you watch the "where" status in D3 you’ll see that during a BASIC Compile a port will run through various BC.* modes (assembler modules), and non-flashed applications run through the BASIC Runtime modes identified as BR.*. Once the compiler has generated tokens it’s no longer needed. Every system requires a runtime to parse and execute the tokens, and the BASIC Runtime code is slightly different on each platform, which is why some issues appear in BASIC on one platform and not others.
In many other environments, object code is real "machine code" that interacts directly with the host OS. Code like this (generally C, C++, or low-level assembler) is generally faster than interpreted code. But machine code is platform-specific, different between Windows, Linux, AIX, Solaris, etc. A Pick application, specifically the object code, is intended to be cross-platform without recompilation, so if object code is delivered as tokens then a common runtime engine can be used on all platforms to run it. It’s not quite as fast as machine code, but speed is traded for portability and security. This exact same process is used with the Java Virtual Machine, and with the Microsoft .NET Common Language Runtime which executes Commom Intermediate Language. Most .NET people are fairly familiar with the concepts of the CLR and CIL, also known as MSIL.
1 thought on “D3 FlashBASIC History and Usage”
Thanks for this interesting history and usage of flashbasic.