[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Eliot Miranda eliot.miranda at gmail.com
Fri Jul 8 22:53:38 UTC 2016

Hi David,

On Thu, Jul 7, 2016 at 4:43 PM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Thu, Jul 07, 2016 at 11:14:20AM -0700, Eliot Miranda wrote:
> >
> > Hi David,
> >
> > On Thu, Jul 7, 2016 at 9:03 AM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> >
> > >
> > > sqInt is not always large enough to hold a pointer, in particular for
> the
> > > common case of a 64-bit VM running a 32-bit object memory (yes I know
> > > there is not currently such a configuration for Cog/Spur). It would be
> > > good to avoid that assumption if possible.
> > >
> >
> > I wonder what the benefit of trying to maintain the   64-bit VM running a
> > 32-bit object memory configuration is, now that we have an efficient
> 64-bit
> > on 64-bit configuration.  This is costly to maintain, and unless people
> > really want to use it for me it feels like wasted effort.  I realise it's
> > your baby, and that it may have meaning.  But it's also a hungry mouth to
> > feed...
> >
> Hi Eliot,

forgive me.  I don't want a knock down fight, but I really do disagree.
I'm sure you won't take this personally.

> Regarding the type declarations, it is a lot easier to put effort into
> doing it right the first time, rather than trying to fix it later. It is
> also easier to find and fix problems in that area if you are working in
> a mixed environment with 64-bit pointers and 32-bit sqInt. So yes there
> is value in maintaining that configuration.

There is no practical benefit to a 64-bit pop upon 32-bit address space
configuration.  Because...
- 64 bits are used in every oop yet only a 32-bit address space can be
accessed, so the excess bits don't increase address space, but actually
reduce it since pure pointer objects are twice as large
- every access must fetch two words, use two registers, etc, etc
So this configuration only provides overhead.  It does not provide
additional functionality; and given 64-bit machines are common these days,
it does not provide any useful testing.

So I reiterate, IMO this is pure overhead.

In contrast, a 32-bit oop over 64-bit address space configuration can
provide considerable benefits:
- access to 64-bit instructions and 64-bit registers for efficient
streaming computation
- more compact images/footprint for small machines (Pi)

So please, can we knock the 64-bit pop in 32-bit address space
configuration on the head and bury it quietly?  Who's going to miss it?

Kudos to Nicolas for taking the time to think the issue through and get
> the declarations right. It is the right thing to do, and it will save a
> good deal of pain for other people in the years to come :-)
> Dave

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160708/012fd6b2/attachment-0001.htm

More information about the Vm-dev mailing list