<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><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">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:0 0 0 .8ex;border-left:1px #ccc solid;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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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 class="gmail_signature" 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>