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

[David T. Lewis]

On Fri, Jul 08, 2016 at 03:53:38PM -0700, Eliot Miranda wrote:
>  
> 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.
> 

Hi Eliot,

I don't agree, aside from your point about not wanting to argue about it.

Dave


> 
> >
> > 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