At 07:35 PM 5/21/2003 +0200, Leopold Toetsch wrote:
Okay, I've looked at everything I could gather on IMCC from the source tree
and I've got a list of questions before I can IMCC-ize BASIC
completely. (It *is* marching in that direction, slowly.) Consider these
the questions of a raving clueless lunatic, and calmly point me to
documentation if I've missed it somewhere.
[I realize that I horribly over-complicated some aspects of BASIC and it's
slower than it needs to be. I'm doing *way* too much at runtime and am
trying to solve that. Speed is my motivation for IMCC-izing and
simplifying everything. I'd like a 3-ply chess game in BASIC to be
* When dealing with an expression that I've determined needs to have
intermediate values stored like this (a simplistic example):
I'd naively interpret this as:
2 * 3 -> store result on stack
4 * 5 -> becomes operand 1
restore operand 2 from stack
multiply (result becomes operand 1)
set operand 2 to "1"
add (result becomes operand 1)
return operand 1 as the expression result
What's the approved way of implementing this "stack"? Which stack should I
use? Right now, the expression parser allocates a PerlArray and just
pushes the result. This doesn't get weird, of course, until in the middle
of an expression you need to call a function with another scope, in which
means I have to get another PerlArray; or when there's functions with
multiple arguments. Am I doing this right?
* BASIC sometimes doesn't lend itself to "compilation units" very
well. With modern-day Q-BASIC function calls:
function myfunc$(a, b)
Sure, but with:
100 gosub 999
1000 print "Hello"
1100 print "World"
1200 print "!"
Is this a compilation unit? There's no scope or anything. Nothing to
save, restore, or anything. No "one entry" point. Is this going to fly
well with IMCC?
* BASIC also has some odd scoping rules. In most programs, everything's
global. Within subroutines, everything's private unless it's been declared
as shared in the outer scope, or explicitly passed in.
print i # My own i, =0
print foo # foo from outer scope
dothis=100*a # a is local, and has z's value
So would a BASIC program essentially want to declare *everything* local
(given how IMCC works) and just those things that are explicitly declared
SHARED would be declared as global in IMCC? Is IMCC going to be happy with
that many globals (or that many locals)? Is there anything I can do to
make it happier?
* Are BASIC arrays my own problem? (I can't see how it'd be possible for
IMCC to handle those in any way.) Right now I'm using a PerlHash/PerlArray
structure to manage those, and lookups are handled much in the same way
that function calls are performed.
* Is there a nice way to handle mixed-precision operations? Will there
be? Or is this just something I need to watch?
.local int a
.local float b
.local int c
* What's your advice on when to go through the whole calling convention stuff:
.local int r
call _foo # (int)foo(x,y)
.local int r
.param int a
.param int b
and when to just slug some things onto a stack or into some registers and
bsr there. I've got a few examples, your thoughts?
utility functions that the runtime will need (array lookups, etc...)
builtin functions that the runtime calls ( int, abs, str$, mid$,
That's it for now. But its enough to get me started. Thank you!