Will Coleda 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.
The advantage of allowing unlimited registers per sub is that it frees
us from spending quite so many cycles on register spilling. What's the
advantage of adding a limit?
PIR/PASM should of course parse whatever register numbers we decide are
legal. But, the lexer should only impose limitations that are also
imposed internally. PIR/PASM are not the only ways to generate bytecode.
If we set a lexer limitation of, for example, 250 registers, the
internal register allocator could validly create and use registers that
can't be directly accessed from PIR/PASM code, which could prove
problematic for debugging tools.
My take:
- Change the lexer to allow the maximum size of a 32 bit integer. (This
doesn't cost anything, since we're already storing the value as an integer.)
- Leave it to the interpreter and optimizer to decide when a sub should
have enough registers for every possible value, and when to employ
register spilling/reuse.
- Set coding standards for hand-written PIR to use the temporary
register variables ($P0) or local variables (.local pmc foo) instead of
direct registers (P0), except when direct register access is absolutely
necessary.
If at some point we put an internal restriction on how many registers a
sub can have, then we change the lexer to match.
Allison
