<div dir="ltr">Hi Bert,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 12, 2018 at 1:34 PM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 April 2018 at 16:31, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi <br><blockquote type="cite">On 12.04.2018, at 16:05, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br><br>Hi Bert,<span><br><br><br>On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>> wrote:<br><br><blockquote type="cite">If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.<br></blockquote><br></span>How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.<br></blockquote><div><br></div><div>But wasn't that done once already?</div><div><br></div><div>I see Squeak 5.7.4.1 (John Macintosh did it I think).</div><div>Wich advertises itself as</div><div><img id="m_-3229136317089257631m_835808206385109338118D10F12-7B77-4D3A-8308-572652F01A86" height="21" width="176" src="cid:891DE8B9-5BF4-43C0-AE3C-4FE4DB2755A0@l.certwifi.com"></div><div><br></div><div>and worked very well. Not saying every bits are there for the present (spur etc)</div><div>but at least, we have been there already at least once…</div></div></blockquote></div><br></div></span><div class="gmail_extra"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked without big problems on the interpreter. I don't know what additional constraints are imposed by Cog / Spur, but I thought at least for intel, the 32 bit instruction set was a strict subset of x64, so there should be no big problems.</div></div></div></blockquote><div><br></div><div>The main problem is in arranging that the heap is allocated in the 32-bit addressable part of the address space. It's also effectively another VM to support, with its won bizarre configuration of FFI (64-bit) for a 32-bit client. That could be expensive.</div><div><br></div><div>The thing that the above 64-bit system did that made it quick to port but under-performant was to keep oops exactly the same as in 32-bits, but simply make them occupy 64-bits. SmallIntegers had the same range as in 32-bits. And I'm guessing that this predated Andreas' FFI, so it could avoid addressing the FFI issue. We can't. If we wanted full support we would have to provide a way of loading 32-bit dlls and calling them via the FFI through the 32-bit calling convention. That's not trivial.</div><div><br></div><div>That's why for me by far the simplest thing is to convert.</div><div><br></div></div><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>