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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Jul 8 23:29:30 UTC 2016

2016-07-09 0:53 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

> 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.
> Hi Eliot,
I think we're focusing on most interesting case:

32bit-oop (sizeof(sqInt)==BytesPerOop that is ==4) on 64bits address space
(sizeof(void *)=BytesPerWord that is ==8).
Because of LLP64 and windows x64 support, we cannot rely on long as a
universal uintptr_t, nor on sqInt that is too short in this case.
Note that 'm mixing the two features (LLP64 & 32bits image on 64bits VM)
voluntarily otherwise we would do the job twice.

For windows, we are forced to introduce the sqIntptr_t anyway and use it in
the plugins that exchange pointer with image, and a few places in the VM.
That means that we must use (u)sqIntptr_t in positiveMachineInteger and
For 32 bits image on 64bits VM, we must distinguish again BytesPerOop for
sqInt from BytesPerWord for sqIntptr_t in CCodeGenerator (for infering int
type length, int type harmonization, etc...)

I've started the job in a VMMaker branch VMMaker.oscogintptr-nice.1900 at
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main and I'm testing if
no regression on mac 32/64.

I don't think we have to care too much of 64bits image on 32bits pointer
indeed, but I don't think that we are putting much effort in it, do we?

> 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/20160709/510dd40a/attachment.htm

More information about the Vm-dev mailing list