<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 11, 2014 at 3:12 AM, 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"> <br><div style="word-wrap:break-word">On 11.12.2014, at 03:01, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br><div><blockquote type="cite"><br><div><div dir="ltr">There's an oddity of a 32-bit VM compiled in 64-bit mode on a 64-bit machine. I don't know of anyone using it.</div></div></blockquote></div></div></blockquote><div><br></div><div>Right. But since the rationale for this VM is only to interface with 64-bit libraries, it depends on a 64-bit FFI, which we do not have. So in the absence of a 64-bit FFI it is pointless. Instead running the 32-bit VM on the 64-bit platform is a perfect replacement. For me having a 64-bit VM/image working is a higher priority than having a 32-bit image/64-bit VM. Both are dependent on the 64-bit FFI but the latter also lifts the address space limit, so it kills more birds.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>This actually is *the* single most requested VM people want on Linux. It's just not quite stable because Dave has been working on it all on his own.</div><br><blockquote type="cite"><div><div dir="ltr"> But on that config<br><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><div> sizeof(int) == 4</div> sizeof(long) == 8<br> sizeof(sqInt) == 4<br></div><div><br></div><div>I'm in the process of providing a real 64-bit system with 61-bit SmallIntegers, immediate floating point, a segmented memory, etc, etc. I am /not/ going to be held up trying to maintain the old 64-bit VM oddities. A 32-bit VM on a 32-bit platform and a 64-bit VM on a 64-bit platform are enough, and expensive enough to maintain.</div></div></div></div></div></blockquote><div><br></div><div>Dear VM. You have *one* job. Be virtual. Make my image run no matter what actual platform we are on.</div></div></div></blockquote><div><br></div><div>That's fine. You break your back doing that. My definition of a VM is different. Provide a performant, safe, interoperative platform on which to run Smalltalk et al. I'm not interested in virtuality per se. I'm interested in being able to get work done. I will choose popular platforms and performance over slowness and portability. I will choose FFI over plugins. We differ. Let's accept that difference.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Seriously, we need to be able to take an image from one platform and run it on another. </div></div></div></blockquote><div><br></div><div>But that can be done with off-line tools. It doesn't need to be done with an all-in-one VM that is slow, complex and difficult to maintain.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>If your particular VM cannot cover all platform-image combos, fine. You trade performance for cross-platformness. That's cool. But please don't make it harder for those of us who *do* value cross-platformness in futzing around with sqInt. It is *defined* as being a type of the image's word size, not the machines's word size.<br></div></div></div></blockquote><div><br></div><div>OK, so use long.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div><br></div><div>Please do *not* use "long" in VM code. </div></div></div></blockquote><div><br></div><div>Bollocks. long is an integral type defined to be large enough to take a pointer. If sqInt is out, as you stipulate above, and the existing code is written to take an integer parameter in which is passed a pointer then long is the only choice. Rewriting all the platform code to take pointers where pointers are passed is work for the future, not busy work that advances nothing.</div><div><br></div><div>But if th absurdity of sizeof(sqInt) == 8 when sizeof(void *) == 4 is accepted then we can use sqInt.</div><div><br></div><div>Now, I don't ant to fight anymore. I'm getting back to getting a 64-bit Spur stack VM running on linux. You do what pleases you.</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"><div style="word-wrap:break-word"><div><div><br></div><div>+1 to what Dave wrote. (*)</div></div><br><div>
<span style="border-collapse:separate;border-spacing:0px;font-family:'Lucida Grande';font-size:12px"><div style="word-wrap:break-word"><div style="font-family:Helvetica"><span style="font-family:Helvetica">- Bert -</span></div><br></div></span></div>(*) The first word coming to my mind was the same one Dave used.</div><br></blockquote></div><br><br clear="all"><div>Whatever Bert...</div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>