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

[Eliot Miranda]

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?
Seriously.


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