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.

Other languages like PHP, Perl, and JavaScript are regarded as scripting languages because they are not compiled – the runtime engine processes source code all the way down to the machine code for the specific OS. In short, scripting languages are pseudo-compiled and executed at runtime. This has benefits and detriments. On the pro side, there is no compilation process, you run your source code and get immediate gratification. On the con side, sometimes obvious issues are not found until the runtime hits them, and this could be after the software has been deployed to end-users.

Many people are confused about the difference between Java and JavaScript. Some people tell me they write Java code and I’ve found out later they really meant JavaScript. I hope these last couple paragraphs have helped with that. In short, the JavaScript looks and functions a lot like Java, but it is interpreted, not compiled (to tokens) like Java. The name JavaScript implies that it "is" Java, only somehow different, but this is not the case at all. The Java language has access to many features that JavaScript does not. And JavaScript is an ECMA Standard, while Java was only recently released to open source. For these reasons and others JavaScript is frequently referred to as ECMA Script.