<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 11, 2014 at 12:25 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div style="word-wrap:break-word"><div>Eliot,</div><div><br></div><div>maybe this came across as if we wanted to somehow interfere with your 64 bit work. On the contrary! We simply think it wise to use clearly defined type declarations that allow all sorts of implementations, even ones you would consider silly. Nobody is expecting you to make the silly stuff work :)</div><div><br></div>On 11.12.2014, at 19:28, 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">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><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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>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><div> </div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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. </div></div></div></div></div></blockquote><div><br></div><div>Not for people who can't easily run a 32 bit VM on their 64 bit system. I'm with you that the Linux folks got it wrong, that their zealous goal of making a 64-bit-only system is misguided. Nevertheless, it is legitimate to want to compile a VM on these crippled 64-bit-only systems and have it run a normal (32-bit) image.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><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></div></div></div></blockquote><div><br></div>Sure. That does not imply we need to make our respective goals harder to achieve, if that is simple to avoid. And using "sqInt" throughout is pretty simple IMHO.</div><div> <br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></div></blockquote><div><br></div><div>As I said, I don't particularly care how we make this work. If a child takes their image from the school computer and wants to run it at home, and one machine happens to be 64 bits and the other does not, then it would be dreadful if it had to run it through a converter. But we may be able to hide that in the VM startup script.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></div></blockquote><div><br></div><div>No. Maybe I miswrote, or you misread. We do want to use sqInt for oops, because that is defined by us, not by the compiler.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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. </div></div></div></div></blockquote><div><br></div><div>I meant "do *not* use 'long' for oops", with which I think you actually agree.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> long is an integral type defined to be large enough to take a pointer. If sqInt is out, as you stipulate above,</div></div></div></div></blockquote><div><br></div><div>I didn't. I advocated using sqInt.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> 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></div></div></blockquote><div><br></div><div>That would only be the case for a 64-bit image running on a 32-bit platform. Which is very expensive, sure, and not something we would advise anyone to use in production.</div><div><br></div><div>Much more relevant is the case of sizeof(sqInt) == 4 when sizeof(void *) == 8, as I wrote above.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Now, I don't ant to fight anymore.</div></div></div></div></blockquote><br><div>Yeah, fights are no fun if you can't scream at each other and have a beer after. But then again, apart from use of the n-word (for which there was an apology), we're not even really fighting :)</div><div><br></div><div>The only thing we questioned was that you said "long" was a fine replacement for "sqInt" in general. But as I understood it that was just an off-hand remark and not an actual advice to go and replace every use of "sqInt" with "long". </div></div></div></blockquote><div><br></div><div>Right. I suggest using long to declare parameters that take pointers encoded as integers. As in the fileNamePtr argument in</div><div><br></div><div>int asyncFileOpen(AsyncFile *f, int fileNamePtr, int fileNameSize, int writeFlag, int semaIndex);<br></div><div><br></div><div>The simplest fix to this code is</div><div><br></div><div>int asyncFileOpen(AsyncFile *f, long fileNamePtr, int fileNameSize, int writeFlag, int semaIndex);<br></div><div><br></div><div>Of course it should be written</div><div><br></div><div>int asyncFileOpen(AsyncFile *f, char * fileNamePtr, int fileNameSize, int writeFlag, int semaIndex);<br></div><div><br></div><div>or void *, but that requires modification of the body of asyncFileOpen which is more work than I want to put in on this.</div><div><br></div><div>Of course it should /really/ be written</div><div><br></div><div>long asyncFileOpen(AsyncFile *f, char * fileNamePtr, long fileNameSize, long writeFlag, long semaIndex);<br></div><div><br></div><div>because on 64-bits there may actually be code generated to convert to the 32-bits tat int defines, whereas long is natural and requires no nonsense by the compiler to pass as a parameter, put in a register etc.</div><div><br></div><div>Hence my advice, don't use int.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>So we just wanted to clarify that the right type to use for oops was in fact sqInt (or as David said a yet-to-be introduced "oop" type).</div></div><div><br></div><div>Peace?</div></div></blockquote><div><br></div><div>Peace.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><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></div></span></div></div></blockquote></div><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>