On Mon, Mar 16, 2009 at 2:15 PM, Philippe Marschall <
philippe.marschall at gmail.com> wrote:

> 2009/3/16 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> > On Sun, Mar 15, 2009 at 1:57 PM, Nicolas Cellier
> > <nicolas.cellier.aka.nice at gmail.com> wrote:
> >>
> >> 2009/3/15 Hans-Martin Mosner <hmm at heeg.de>
> >>>
> >>> nicolas cellier schrieb:
> >>> > Hans,
> >>> > Tagging/untagging could be very fast! See my other post
> >>> >
> >>> > 1) UnTagging a double= No op
> >>> > 2) Tagging a double= a isnan test (so as to have a representable nan
> >>> > in Smalltalk)
> >>> > 3) This trick does not had any extra cost to tagging/untagging of
> >>> > other oops
> >>> That's true for a 64-bit processor, and on such hardware I see the
> >>> advantages of this scheme.
> >>> For 32-bit hardware, it won't work.
> >>> Hopefully we'll all have suitable hardware in the near future...
> >>> But for example, I'm running 32-bit linux here on my 64-bit AMD
> >>> processor just because the WLAN card I'm using only has a 32-bit
> Windows
> >>> driver, and ndiswrapper on 64-bit linux would require a 64-bit driver
> to
> >>> work correctly (which is somewhat stupid IMHO but I'm not going to hack
> >>> ndiswrapper).
> >>> In the real world, there are tons of silly constraints like this which
> >>> still prevent people from fully using 64-bit hardware.
> >>>
> >>> Cheers,
> >>> Hans-Martin
> >>
> >> Of course, most of the nice properties come from the 64 bits
> adressing...
> >> Hey, wait, I don't even have a 64 processor in my house!
> >> For the fun I imagine we could emulate by spanning each oop over two
> int32
> >> typedef struct {int32 high,low;} oop;
> >> I would expect a slower VM by roughly a factor 2 - except for double
> >> arithmetic...
> >
> > In theory, but only for memory-limited symbolic applications.  If you
> have
> > an application that fits entirely in cache then I would expect parity.
>  The
> > argument for symbolic applications is that a 64-bit symbolic app has to
> move
> > twice the data as a 32-bit symbolic app because each symbolic object is
> > twice the size.
>
> Couldn't you compress the oops? AFAIK HotSpot was the last remaining
> JVM that got this.


I don't see the point.  Memory is cheap, getting cheaper.  64-bits means
extremely cheap address space.  Why slow down the critical path to save
space?


>
> Cheers
> Philippe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090316/9046e82e/attachment.htm