At 09:43 AM 9/13/2001 -0700, Damien Neil wrote:
>On Thu, Sep 13, 2001 at 10:06:51AM +0100, Philip Kendall wrote:
> > If we are going to keep on doing fancy stuff with pointer arithmetic (eg
> > the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an
> > integer type which is guaranteed to be the same width as a pointer, so
> > we can freely typecast between the two.
>
>The language lawyer in me insists that I point out that this is
>inherently nonportable. C does not guarantee that it is possible to
>convert losslessly between pointers and integers; there have been
>systems on which this was impossible (or hugely inefficient) for
>hardware reasons.
Oddly enough (given I wrote the code in question... :) I'm painfully aware
of this. The code in memory.c is pretty much a placeholder, there to
provide basic functionality but we will have something a lot better.
(There's no provision for GC, it leaks like a sieve, is horribly wasteful,
and is about as portable as your average 12-ton rock)
Once we get things a bit more stable and documented, memory.c needs to be
completely trashed and redone.
> > Also, if we've got a system with 64 bit IVs, are the arguments to Parrot
> > opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any
> > way of loading a 64 bit constant?
>
>This reminds me of something I've been meaning to ask: Is Parrot byte
>code intended to be network-portable?
Yes. The bytecode will have word length and byte-ordering markers embedded
in it. When the bytecode loader finds 'inefficient' bytecode it will,
instead of mmapping it in, process it in and build a more efficient
in-memory version. (I expect generally that'll be restricted to big/little
endian issues, but for platforms that don't do 32-bit integers, or do them
really slowly relative to 64-bit ones, that'll mean expanding things
appropriately)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
