[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid
macro for LLP64 case in sqWin32Backtr...
David T. Lewis
lewis at mail.msen.com
Fri Jul 8 23:18:11 UTC 2016
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.
I don't agree, aside from your point about not wanting to argue about it.
> > 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
More information about the Vm-dev