On Fri, 8 Jul 2005, Fred Quimby wrote:
> You're right, I do know C but not perl, sed, awk or other language that
> might be easier. I've only recently learned about lex/flex/yacc/bison and
> I've been reading up on them - I will definitely use these once I learn how.
> If someone can help to get me started, that would be great - to start, I'd
> like to know how to get a parser going with these tools that accepts the
> line number, then a valid keyword or variable declaration for now so I can
> get a feel for how these tools work.
I highly recommend the book "Lex & Yacc" from O'Reilly.
Actually, Stella's getting a lex/yacc (well, flex/bison) based expression
parser for the debugger, too, so you'll be able to say things like "watch
(*(myLabel+y)&$80)" (or whatever complicated expression you might need). I
don't know that you should look to my parser as a shining example of
what a parser should be: I'm pretty new at lex/yacc myself.
> I've also thought about fixed point math. I could set aside a few
> variables, or require them to be declared this way. They would use one byte
> for the whole number and another byte for the decimal - they would be useful
> for fractional movement of objects across several frames. I also plan to
> allow one to use any variable instead of just a-z, I just need to figure out
> how...!
I dunno how practical this would be, but my advice would be to let them
declare any variable as fixed-point, then do math on it normally:
10 fixed(a)
20 a = 1.25
30 a = a + 1
40 a = a + 0.25
50 b = a
60 b = 0.125
You'd round constants to the nearest 1/256, possibly printing a warning
for constants that had to be rounded. Lines 50 and 60 would be an error,
since b hasn't been declared fixed-point.
When it comes time to extract just the whole number, I'd say they do
it like:
70 b = int(a)
... or if they need just the fraction, use frac(a). int() and frac()
are present in several BASICs already, so the learning curve isn't bad.
The other alternative is implicit casting, like C does, so line 50 would
give b the whole-number part of a, and line 60 would assign 0 to b. You'd
probably still need at least frac(), though, and you'd have to decide
whether to round (1.875 becomes 2) or truncate (1.875 becomes 1).
The weird thing here (to an old ex-BASIC programmer) is that in other
BASICs, variables are generally floating-point by default, and to
make them integers you either use DEFINT(x) or call them A%, B%, etc.
(or maybe you do both on some systems? It was a loooong time ago). In
2600 BASIC, variables are integer by default, and probably most 2600
BASIC programs will never use fixed-point math at all...
Maybe instead of declaring a variable to be fixed point, you could stick
a # after the variable name (like $ for strings in other BASICs). Then
people would get less confused by implicit casts: they'd *know* they
were assigning a fixed point number to a non-FP variable.
Anyway, that's enough rambling from me. If I had a point to make, I'd
make it already :)
--
B.
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
