[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid
macro for LLP64 case in sqWin32Backtr...
eliot.miranda at gmail.com
Fri Jul 8 22:53:38 UTC 2016
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>
> > >
> > > sqInt is not always large enough to hold a pointer, in particular for
> > > 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
> > 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
- 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
- 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 :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev