On 7/9/05, Christopher Walton <cwalton@xxxxxxxxx> wrote:
> > >But I think it would be important to be able to reuse variables as we do in
> > >ASM with overlays.
> >
> > Yes, I didn't think of that. Does anyone have a good solution to this?
>
> I believe this is the same problem as register allocation in a regular
> compiler, which is a classic NP-complete problem. Most compilers
> address this by using a variant of a graph coloring algorithm, first
> proposed by Chatin, but things can get very complex. I would
> recommend the comp.compilers group and the classic "Dragon book" for
> details:
> "Compilers: Principles, Techniques and Tools", by Alfred V. Aho, Ravi
> Sethi, and Jeffrey D. Ullman
> Alternatively, it might be best to leave this until later!
Or, umm... "never"...this is pretty far beyond the scope (as I see it)
of what we're trying to set out. The two recommended approaches so far
have been:
1. the user is of course free to use any variable name they want, and
can take their own responsibility if they use it for a different task
at a diffferent section of the program
2. the user can give a variable more than one name, but still has to
ensure the multiple uses don't overlap, which overlays can help
enforce
Having the compiler analyze the code and autodetect that a value can
be overwritten is just way beyond what I think Mr. Quimby wants to do.
To a certain extent, Batari Basic is more of a mighty macro than
anything else. Like all computer languages, its utility will be found
in two main areas: the friendliness of its syntax (i.e. Basic-like
being friendlier than ASM, and chunking frequent sets of ASM
operations into single commands) and the richness of its libraries
(like, right now it has a very good kernal for the players, missiles,
and a score.)
Fred, Getting back to the original question...
If you had a syntax like
10 dim monsterxpos as A
20 dim monsterypos as B
30 dim titlescreentimer as A : rem monster not on title screen!
40 dim titlescreenmusicptr as B : rem monster not on title screen
that would let them assign arbitrary names to RAM
an overlay approach might look something like this
10 variableset ingame : rem name for this group
12 dim monsterxpos : rem would be assigned 'a'
14 monsterypos : rem would be assigned to 'b'
20 variableset titlescreen : rem name for this group
30 dim titlescreentimer : rem would be assigned 'a'
40 dim titlescreenmusicptr : rem would be assigned 'b'
and then later on
100 usevariableset titlescreen
110 titlescreentimer = 0
.
.
500 usevariableset ingame
510 monsterxpos = 40
and in this case a line like
520 titlescreentimer = 100
should throw an error at compile time, since it's not in the current
variableset/overlapy
actually, any variable declared before the first "variableset"
declaration should probably be 'global', and available to any part of
the program. and that way if they don't want to use variablesets at
all, it just ducks out of the way and they don't have to think about
it ('til they start running out of memory at least!)
I think requiring "dim" statements is a good way to go if you're going
to allow variable names. some Basics required it anyway, and it maps
up well to the set of ram predeclares that often are at the head of an
ASM program.
BTW, for floats (actually "floats" is the wrong word, since it doesn't
really "float", it's usually always 8 bits integer 8 bits fractional)
I still think it might be useful to make it clear that you're taking
two bytes, some thing like
10 dim xpos, xposfrac as fixedpoint
which means they can then use xpos by itself for the the display, and
then also refer to xpos for the math. I know you're history with
Basic makes you lean towards hiding the complexity from the user, but
I don't think that's the best strategy.
also, then
15 dim bigscore, bigscore2 as doublebyte
which would also take 2 bytes but treat it as a giant single integer...
Hope this makes sense. I'm trying to make sure this stays practical.
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
