[Coco] a désigne document about BASIC for the 8080 & 6800- Microsoft

James Jones jejones3141 at gmail.com
Wed Jan 27 07:31:09 EST 2016


>A step further, a BASIC compiler goes to far
in my opinion (for several practical reasons).

And, I believe, we've just reconstructed the reasoning that led to BASIC09.
I-code is compact, and one only pays the price of parsing once.

On Wed, Jan 27, 2016 at 6:26 AM, Johann Klasek <johann+coco at klasek.at>
wrote:

> On Wed, Jan 27, 2016 at 05:59:04AM -0500, James Jones wrote:
> > As Mr. Evans says, limited resources just about forces an interpreter.
> The
> > sad part is that the interpreter persisted after the constraints were
> gone,
> > leaving people without reasonable control or data structures, without
> local
> > variables, and having to contort their code (packing as much as possible
> on
> > each line because line numbers use up memory, finagling variable
> references
> > so that the interpreter's linear search symbol table lookup didn't take
> > quite as long on frequently-referenced variables) to deal with the
> > interpreter's limitations--though none of that got rid of the overhead of
> > having to interpret each statement each time it was executed.
>
> This hits the point pefectly. The programmer is forced to "play" as a
> human BASIC optimizer (felt this so often)... something that could be
> accomplished automatically. A step further, a BASIC compiler goes to far
> in my opinion (for several practical reasons).
>
> > (Didn't
> > people also store numeric values in variables to avoid making the
> > interpreter rescan and reconvert them from text over and over?)
>
> Yes! But there is a floating limit on which a number constant is better
> to be stored in a variable and depends on the number of digits and the
> position in the variable table. For sure a neat computational challenge. :)
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>


More information about the Coco mailing list