At 5:57 PM +0100 on 12/7/99, M. Uli Kusterer wrote:
>> 1. There are a finite number of variables allowed. This would make
>> it so that the temp space would be small.
>
>Anthony,
>
> limited by memory, or limited by concept? If the latter, you'd better
>remove that limit ASAP.
Limited by concept. But the limit is much higher than HyperCard's.
Did you even know HyperCard had one? Probably not -- no human can use all
that it does. HyperCard gives you 512 for all pending handlers. I've got
256 or 512 (not sure yet) for _each_ handler [including temps].
Anyway, where does this limit come from? The fact that a NullCPU
instruction is 32-bits, and that I've got to fit a destination and two
source variables in those 32 bits, as well as what the instruction does. So:
5 bits: opcode [what it does] 32 possibilities
9 bits: destination var # 512 possibilities
9 bits: source1 var # 512 possibilities
9 bits: source2 var # 512 possibilities
-------------------------------------------------------
32 bits: instruction 4,294,967,296 possibilities
I'll try and make these easy to change, but the bigger the instruction the
slower it goes. I _have_ tested that.
Also, the size of a compiled function (single handler or function) is
128MB, because the maximum jump offset is 2^27, or 128MB. This can be
worked around, but anyone writing a SINGLE function/handler compiling to
over 128MB deserves what they get :)
The maximum size of a variable, variable name, function name, etc. is
availible memory, or 4GB on 32-bit machines (whichever is less)
I don't think there are any other built-in limitations.
