The writer wonders if a compiler would fit in 14K of ROM.
I remember, for the Commodore 64, in some old Compute! book, a compiler called "Sprint" if my memory is correct.
This book featured programs you could type in using their program "MLX" (which was a BASIC program you had to type in as well). "Sprint" was one of these. The program was about 6K (it definitely was the biggest program in the book).
I never typed it in. I remember it having limitations, like considering all variables integers and not supporting the DIM statement fully.
I'm not too familiar with BBC BASIC but my understanding was you could mix 6502 opcodes in with BASIC statements and basically do inline assembly. That would seem to be the optimum strategy for old 8-bit computers that would have to store the source and object code in as little as 64K or less of RAM.
----------
> A NEXT, however, must check each time the stack of FOR statements to find the variable to increment and the line to jump to.
This is why on most BASICS we always left out the variable, most BASICs would "automatically" loop to the outermost FOR.
Integer and string only, no parentheses (strict left to right evaluation), array sizes were limited to 126 elements and one dimension, but longer variable names. Converting a normal C= 64 program to work with it was daunting.
This issue also has a machine language assembler, which I did use extensively.
Also, I don’t think that solves the fundamental problem that (edit: you can get very close. If you maintain a stack of ‘for loop contexts’, NEXT without loop variable name(s)) is little more than an indirect jump), in Basic, for loops don’t introduce a scope, making ‘innermost’ not really a thing (“most recently encountered” is a better way to phrase it)
My Basic is very rusty, but I think this is valid in a classic Basic interpreter:
10 input f
20 if f = 0 goto 50
30 for i = 1 to 10
40 goto 60
50 for j = 1 to 25
60 print “foo”
70 next
Whole-program analysis likely can convert most, if not all, uses of NEXT to jumps in ‘normal’ code, but fitting that in 14 kB may be problematic.
Regarding Basic compilers, there were plenty to choose from, and relatively fast versus any other high level language, C only started to matter on 8 and 16 bit platforms, after UNIX started to gain market adoption.
Naturally an Amiga was much powerful as an Apple IIa, but stuff like AMOS did wonders on the demoscene.
Not sure why you're being downvoted, but I owned a copy of AMOS and AMOS 3D after it came out, and I certainly don't recall anybody using it for much that I recall, other than a few homebrew games and such. Certainly not any demos I ran across.
That said, last week I went on a spree looking up AMOS - and interestingly, I found that the author released it as open source a while back, and recently released a new cross-platform language that supposedly is AMOS compatible (IIRC), and open source too. I think he had a patreon or something to sponsor it's development:
Though the wikipedia article mentions a few commercial games that were made with it...
Anyhow - via finding that, and some other searching, I found that there is still an active AMOS community out there. I'm not sure I need another BASIC-ish retro-language in my repertoire, but I find it fascinating nonetheless!
My computer as a teen. I would literally stay up late reading the monitor ROM listing and thinking Woz was some kind of super hero. Anything Apple did after the ][ seemed like a betrayal to me (although I do own an iPod I love).
I remember, for the Commodore 64, in some old Compute! book, a compiler called "Sprint" if my memory is correct.
This book featured programs you could type in using their program "MLX" (which was a BASIC program you had to type in as well). "Sprint" was one of these. The program was about 6K (it definitely was the biggest program in the book).
I never typed it in. I remember it having limitations, like considering all variables integers and not supporting the DIM statement fully.
I'm not too familiar with BBC BASIC but my understanding was you could mix 6502 opcodes in with BASIC statements and basically do inline assembly. That would seem to be the optimum strategy for old 8-bit computers that would have to store the source and object code in as little as 64K or less of RAM.
----------
> A NEXT, however, must check each time the stack of FOR statements to find the variable to increment and the line to jump to.
This is why on most BASICS we always left out the variable, most BASICs would "automatically" loop to the outermost FOR.