On Fri, 2003-06-06 at 21:47, Benjamin Goldberg wrote:
> And for the former... well, we'd be wasting half of the memory that's in
> our "32-bit" registers (since we'd still use 64 bits of storage for each
> of our registers, even though we're "using" only 32 bits of it), but
> there's no speed penal
On Fri, 2003-06-06 at 16:34, Leopold Toetsch wrote:
> > *) Integer constants are limited to 32 bit signed integers because
> > they're inline.
>
> Yep. But this will cause problems with JIT/Prederef and multi threading,
> and its already causing problems inside JIT on architectures with only
> sma
On Fri, 2003-06-06 at 15:12, Dan Sugalski wrote:
> Our options, as I see them, are:
>
> 1) Make the I registers 64 bits
> 2) Make some way to gang together I registers to make 64 bit things
> 3) Have I registers switchable between 32 and 64 bit somehow
> 4) Have separate 32 and 64 bit I registers
On Tue, 2003-06-03 at 03:54, Henrik Tougaard wrote:
> On Sat, May 31, 2003 at 09:54:45AM -0400, Bryan C. Warnock wrote:
> [snip]
Part of what was snipped was this line:
(For the sake of using real numbers, I'll assume 32/64.)
> > Currently, the flow is, in variable sizes:
> >
> > Opcod
Gopal V <[EMAIL PROTECTED]> wrote:
> What I wanted to say was to have fixed size variables and an interpreter
> specific internal notation would be ideal. And only if you wanted to
> operate stuff with direct int registers.. The fixed size variables allow
> the JIT to decide if we use half-a-regis
If memory serves me right, Bryan C. Warnock wrote:
Reply inline ... and I've said more than I've quoted ... It could be
called as a critical appreciation ... though not much has been appreciated
below ... and what I know about parrot can be written on a shirt sleeve ;-)
Please do tell me if I've g
On Sun, 2003-06-01 at 10:08, Gopal V wrote:
> If memory serves me right, Bryan C. Warnock wrote:
> > > No .. to add large numbers very quickly ... ie split registers and
> > > enemies ;-)
> >
> > Understood. My point was that - to parallel virtual machines with
> > physical ones - the big drive
If memory serves me right, Bryan C. Warnock wrote:
> > No .. to add large numbers very quickly ... ie split registers and
> > enemies ;-)
>
> Understood. My point was that - to parallel virtual machines with
> physical ones - the big drive for 64-bit has never been about squeezing
> out another
On Sat, 2003-05-31 at 11:43, Leopold Toetsch wrote:
> Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
>
> > The flow *really* is, in value sizes:
>
> > Opcodes: 32 (constants are limited by the spec)
>
> In which spec? How would we handle 64 bit INTVAL constants on 32 bit
> systems?
Parrotbyte.
On Sat, 2003-05-31 at 11:15, Gopal V wrote:
> If memory serves me right, Bryan C. Warnock wrote:
> > Not to mention all the *other* problems we'll have if we've got more
> > than 2^31 different opcodes. (Although that's why there's UUIDs now,
> > isn't there?)
>
> I think parrot has already cross
Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
> The flow *really* is, in value sizes:
> Opcodes: 32 (constants are limited by the spec)
In which spec? How would we handle 64 bit INTVAL constants on 32 bit
systems?
> PMCs : 64
> Regs : 32
> Guts : 32
> System : 32
Yep, g
If memory serves me right, Bryan C. Warnock wrote:
> Not to mention all the *other* problems we'll have if we've got more
> than 2^31 different opcodes. (Although that's why there's UUIDs now,
> isn't there?)
I think parrot has already crossed the limit of 1024 ...
(I can't even keep 256 opcodes
12 matches
Mail list logo
