> Currently, IMCC still has a 2-digit limit for PASM registers.
> I think we can easily extend this to any number, as long as it fits in
> an INTVAL.
Last time I checked, register allocator and some other imcc parts used
unsigned char for register numbers in several places.
--
Salu2
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 r
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
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 lim
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:
A
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 allowin
On Tuesday 13 March 2007 07:54, Nuno Carvalho via RT wrote:
> I've allowed for any number of digits in register names, as long that
> the number specified always fits in a 32 integer value. Meaning, if the
> number defined in the register name is less than MAX_INT then it's ok to
> proceed, else g
Greetings,
On Mon Mar 12 15:25:38 2007, [EMAIL PROTECTED] wrote:
> chromatic wrote:
> > On Monday 12 March 2007 10:52, Nuno Carvalho via RT wrote:
> >
> >
> >> I've run the tests and didn't find any test failling because of
> this
> >> change. With this change we can have "P999..999", if a
chromatic wrote:
On Monday 12 March 2007 10:52, Nuno Carvalho via RT wrote:
I've run the tests and didn't find any test failling because of this
change. With this change we can have "P999..999", if a limit to
the number of digits (or size) in the register name is defined i can
change
Am Montag, 12. März 2007 21:34 schrieb chromatic:
> What does this do to the register allocator and to memory usage? If I use
> integer registers 10,000 and 100,000, will Parrot allocate a sparse data
> structure?
Of course not ;) PASM regs are "physical" registers. The register allocator
alloca
On Monday 12 March 2007 10:52, Nuno Carvalho via RT wrote:
> I've run the tests and didn't find any test failling because of this
> change. With this change we can have "P999..999", if a limit to
> the number of digits (or size) in the register name is defined i can
> change the lexer to a
Greetings,
On Sun Mar 11 08:03:06 2007, kjs wrote:
> Currently, S, N, I and P registers are limited to 2 digits; that is, you
> can only use:
>
> [S|N|I|P]0 to [S|N|I|P]99.
>
> For instance, this fails:
>
> .sub main
> P333 = new .Integer
> P333 = 1
> .end
>
> Since Parrot does not have a
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #41788]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41788 >
Currently, S, N, I and P registers are limited to 2 digits; that is, you
can only use
13 matches
Mail list logo
