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
