Having a limit is more than reasonable, agreed: the goal of this
patch was to bring the code into agreement with the docs.
Consider this a poke to the Architect to verify/replace the previous
overturn of the original 32-register limit.
On Mar 13, 2007, at 6:45 PM, Leopold Toetsch wrote:
Am Dienstag, 13. März 2007 11:55 schrieb Nuno Carvalho via RT:
so IMHO the max allowed size of the register name in the lexer
should be the max allowed for an INTVAL.
Please folks, get serious. INTVAL allows 2^31/2^63 registers. A
register is
taking 4/8 bytes of mem. Multiply.
Or IOW allowing arbitrary PASM register numbers (n) is super
inefficient.
Parrot will allocate contiguous memory (per sub/recursion where
it's used) to
hold 0..n register cells [1] [2]. Limit it to some reasonable
amount (e.g.
1024) and make a commandline switch to increase that for special
purpose
code.
As a side note: when you now say, we could compact these register
numbers to a
contiguous range, yes: that's what the default dumb & fast register
allocator
is already doing now with e.g. $P123456 and $P10.
Thanks,
leo
[1] making this sparse will slow down interpreter execution time by
magnitudes
and is totally non-sensical.
[2] using huge ~INTVAL-ranged register numbers will produce
meaningless error
messages, when dying due to out of memory errors.
--
Will "Coke" Coleda
[EMAIL PROTECTED]
