<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-09 0:53 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi David,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 4:43 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
On Thu, Jul 07, 2016 at 11:14:20AM -0700, Eliot Miranda wrote:<br>
><br>
> Hi David,<br>
><br>
> On Thu, Jul 7, 2016 at 9:03 AM, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
><br>
> ><br>
> > sqInt is not always large enough to hold a pointer, in particular for the<br>
> > common case of a 64-bit VM running a 32-bit object memory (yes I know<br>
> > there is not currently such a configuration for Cog/Spur). It would be<br>
> > good to avoid that assumption if possible.<br>
> ><br>
><br>
> I wonder what the benefit of trying to maintain the 64-bit VM running a<br>
> 32-bit object memory configuration is, now that we have an efficient 64-bit<br>
> on 64-bit configuration. This is costly to maintain, and unless people<br>
> really want to use it for me it feels like wasted effort. I realise it's<br>
> your baby, and that it may have meaning. But it's also a hungry mouth to<br>
> feed...<br>
><br>
<br>
</span>Hi Eliot,<br></blockquote><div><br></div><div>forgive me. I don't want a knock down fight, but I really do disagree. I'm sure you won't take this personally.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regarding the type declarations, it is a lot easier to put effort into<br>
doing it right the first time, rather than trying to fix it later. It is<br>
also easier to find and fix problems in that area if you are working in<br>
a mixed environment with 64-bit pointers and 32-bit sqInt. So yes there<br>
is value in maintaining that configuration.<br></blockquote><div><br></div><div>There is no practical benefit to a 64-bit pop upon 32-bit address space configuration. Because...</div><div>- 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</div><div>- every access must fetch two words, use two registers, etc, etc</div><div>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.</div><div><br></div><div>So I reiterate, IMO this is pure overhead.</div><div><br></div><div>In contrast, a 32-bit oop over 64-bit address space configuration can provide considerable benefits:</div><div>- access to 64-bit instructions and 64-bit registers for efficient streaming computation</div><div>- more compact images/footprint for small machines (Pi)</div><div><br></div><div>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.</div><div><br></div><div><br></div></div></div></div></blockquote><div>Hi Eliot,<br></div><div>I think we're focusing on most interesting case:<br><br>32bit-oop (sizeof(sqInt)==BytesPerOop that is ==4) on 64bits address space (sizeof(void *)=BytesPerWord that is ==8).<br></div><div>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.<br>Note that 'm mixing the two features (LLP64 & 32bits image on 64bits VM) voluntarily otherwise we would do the job twice.<br><br></div><div>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 signedMachineInteger.<br>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...)<br></div><div><br>I've started the job in a VMMaker branch VMMaker.oscogintptr-nice.1900 at <a href="http://smalltalkhub.com/mc/nice/NiceVMExperiments/main">http://smalltalkhub.com/mc/nice/NiceVMExperiments/main</a> and I'm testing if no regression on mac 32/64.</div><div><br></div><div>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?<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Kudos to Nicolas for taking the time to think the issue through and get<br>
the declarations right. It is the right thing to do, and it will save a<br>
good deal of pain for other people in the years to come :-)<br>
<br>
Dave<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br></div></div>