Nuno Carvalho via RT wrote:
Hi again,
On Tue Mar 13 16:17:56 2007, coke wrote:
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.
I agree with most POVs, and i'm available for changing the patch as soon
as anyone makes a 'sane' and final decision on the limit.
Best regards,
./smash
To mention another reg.based VM: the Lua VM has 250 registers (but it's
a build option) (http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/jucs05.pdf)
my 2c,
kjs
