3

I only learned of BASIC09 today, and I'm trying to wrap my head around it.

The manual talks about it being a compiler, but I'm not sure I see significant differences between its I-code and tokenized BASICs in general. I know you can PACK it, but that seems more like a symbol stripper.

I am also curious if anyone out there has a working version of BASIC09, preferably on the CoCo3? I would love to run the Ahl and Byte benchmarks through it.

  • Benchmarks: I don't know of any for the 6809. Here typewritten.org/Articles/Benchmarks/primes.html you have some for the 68k version (filter for "68000"). That shows it's outperforming MS Basic on a comparable platform nearly by a factor of 4 on a prime benchmark. Here vintageisthenewold.com/want-fast-basic-try-basic09 is a comparison with ColorBasic on the CoCo - factor 15 slower. – tofro May 14 at 12:04
  • It's a huge difference between tokenized BASIC, which is still the same source code and bytecode, where actions according to data and context get coded. For example adding two integers result in a direct call to an integer add instead of calling a generic adding routine with all the type conversion overhead. Similar for variable access and so on. – Raffzahn May 14 at 15:38
  • I'm pretty sure that the standard NitrOS-9 distro includes Basic09. You shouldn't need to go searching for it separately. – Brian H May 14 at 15:49
3

I can't speak to BASIC09 specifically, but there's quite a difference between an "i-code" and a tokenized form.

At a minimum, the i-code, in the end, need not look at all like the source code, whereas the tokenized form effectively IS the source code.

Many BASICs, when you type LIST, simply parrot back out the tokenized data in long form. With i-code, you can't do that.

Another example is if you look at the DEC BASICs. They used "statement modifiers".

Consider:

10 SUM10 = SUM10 + A(I) IF A(I) > 10 FOR I = 1 TO 10

While this could be represented in tokenized form (in order to regenerate the source line), it can not be easily interpreted executed from that tokenized form.

Token based runtimes, much like i-code, simply take what they see and execute it in the context their in. But you can easily see the runtime encountering the SUM10 = SUM10 + A(I) with out knowing that it should do so yet (due to the IF statement) or even that I is properly in range or not (since it's not even been initialized properly yet).

Sure, you could jump through hoops. Put in "invisible tokens" or whatever specifically to support this kind of construct, but in the "every byte counts" of vintage BASICs, that's a lot of work for not a lot of value. But since the DEC BASICs WERE compiled, rather than just interpreted raw, the system was able to take statements like this and rewrite them internally to be more "normal".

Also, consider:

10 A = 1 + 2 * 3 / 2 + 4 * SQR(2)

In a normal tokenized system, the expression runtime has to account for the operator precedence AT runtime to properly evaluate this expression. Having to do the multiplication and such before the additions, etc.

Whereas in a compiled form, it can be reduced to an RPN style where the evaluator doesn't have to worry about that any more. This makes the runtime faster, since it's much simpler.

1 2 3 * 2 / 4 SQR(2) * + +
  • "Many BASICs, when you type LIST, simply parrot back out the tokenized data in long form. With i-code, you can't do that." - actually, it did just that. There turned out to be a discussion in the printed version of the manual that talks about this in more detail. The big difference is that variables were not in lookup tables but replaced by direct memory references, and likewise pointers to lines and similar were replaced by offsets. – Maury Markowitz May 15 at 0:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.