Talk:BASIC09

I-Code details

My understanding is that I-code is simply a series of JUMP instructions to the RunB module. Thus, the (perhaps) one byte op-code token is replaced with a three byte jump. Because the interpreter does not need to search in a tokenization table, and do all sorts of processing, the i-code runs much faster. Can anyone tell me if all of this (my recall of the BASIC09 documentation) is correct? I would like to update this article... --Reefpicker (talk) 16:32, 23 May 2008 (UTC)

My memory of the BASIC09 doc is also hazy. However, I recall that i-code versions of BASIC09 source are very much smaller than the source. Some of this is surely due to removal of extraneous information, conversion of variable names to pointers when needed, etc. But the size reduction (plus something said in the doc?) led me to conclude that something more significant than a straight translation to a sequence of JMP instructions. However, I cannot be definitive and so can only relay hints from my porous memory. ww (talk) 09:11, 24 May 2008 (UTC)

The BASIC09 manual does not specify I-code; it just says that it exists and states its purpose. I don't believe that Microware anticipated third parties doing anything directly with I-code. The only description of I-code I know of is the reverse engineering done by a fellow who wrote an I-code decompiler; the results of his work are on the CoCoPedia wiki in The Structure of I-Code. — Preceding unsigned comment added by 97.125.133.237 (talk) 03:10, 11 April 2020 (UTC)

Basic09 (effectively a text-only IDE for BASIC09) converts what the user types or loads into I-code as quickly as possible. I-code keeps variable references (all variables are local) as offsets, converts constants to internal form, and keeps expressions in RPN. Basic09 only keeps enough extra information around to prettyprint nicely-indented listings and to let one refer to variables by name when debugging--namely a symbol table for variables and a table to look up the code corresponding to a line number. (For all I know it may be a single table; variable names can't be numbers.) Names of variables thus appear exactly once in memory--and BTW, since the lookup is case-insensitive, it gives you camelCase without having to hit the shift key over and over. Because basic09 has to be able to regenerate the listing, there's an I-code statement corresponding to each control flow statement rather than those being compiled down to virtual machine conditional and unconditional branches. Contrast with Microsoft BASIC interpreters of the time, which, aside from putting line numbers in a sorted table of line numbers in internal form and a pointer to the corresponding statement and encoding keywords and names of built-in functions, source code appears almost exactly as it's entered--so constants are reconverted to internal form, variable names go through a linear search of the symbol table for each reference, expressions are reparsed, and GOTO/GOSUB destinations looked up (again via linear search) every time a statement is executed. Basic09 code thus runs far faster.

Constant folding?

The article claims that packing I-code includes constant folding and references the BASIC09 manual, but if you look at the cited page, it just points out that x:=x+SQR(100)/2 has the same effect as x:=x+5 but is much slower and then goes on to recommend that the programmer do constant folding. Packing could do constant folding, but the cited page doesn't prove that it does so. — Preceding unsigned comment added by 97.125.133.237 (talk) 02:58, 11 April 2020 (UTC)