<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-13 14:32 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="auto"><div>Hi Nicolas,<br><br></div><div><br>On Jul 12, 2016, at 11:33 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-12 23:23 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>
Hi Marcel,<br>
<span><br>
<br>
> On Jul 12, 2016, at 12:24 PM, marcel.taeumel <<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>> wrote:<br>
><br>
><br>
> Hi Nicolas,<br>
><br>
> I suppose there are several places in some low-level parts of Cog/Jit where<br>
> Long and Pointer-Type are used interchangeably. One would have to fix that<br>
> first. Only then, we can start caring for interfacing the win-api correctly.<br>
<br>
</span>That's right. Throughout the Cogit is the assumption that sizeof(long) == sizeof(sqInt) == sizeof(void *). That's why I'm hoping we can use a C compiler which obeys this for win64. It is nontrivial to fix, as I've already discussed. Did my words fall on deaf ears and you're proposing to go ahead?<br>
<div><div><br></div></div></blockquote><div><br></div><div>Hi Eliot,<br><br></div><div>for sizeof(long) != sizeof(void *) that's not a big problem from what i see in VMMaker (unless I'm also blind)<br>there are not so many usage of long/unsigned long<br></div></div></div></div></div></blockquote><div><br></div>It means that sizeof(long) is undefined in Spur 64-bit, as it may be either 4 or 8 bytes in size. So we have to either eliminate it or post-process it to emit it as eg long64 and have #defines to map it to int64 on win64 and long everywhere else.<div><br></div></div></blockquote><div>Right. Solution is to replace with usqIntptr_t<br><br></div><div>The most annoying case is printf... See <a href="http://stackoverflow.com/questions/1255099/whats-the-proper-use-of-printf-to-display-pointers-padded-with-0s">http://stackoverflow.com/questions/1255099/whats-the-proper-use-of-printf-to-display-pointers-padded-with-0s</a><br></div><div>Complete madness. If we support pre C99, that means going through our own macros...<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="auto"><div></div><div>If we keep it, it is a source of confusion that must be documented and learned. If we eliminate it, its absence <span style="background-color:rgba(255,255,255,0)">is a source of confusion that must be documented and learned.</span></div><div><br></div></div></blockquote><div>We must keep it only for case when an external function uses an (unsigned) long prototype.<br></div><div>Otherwise, we could raise a Warning/Error in type inferencer, harmonizer, etc...<br></div><div>That would document it properly.<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="auto"><div></div><div>I had hoped we could avoid outright butchery :-(<br><div><br></div></div></div></blockquote><div>Let's call it surgery :)<br> <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="auto"><div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>longAt() answers a sqInt so it's OK.<br></div><div>I've published VMMaker.oscogLLP64-nice.1901 on <a href="http://smalltalkhub.com/mc/nice/NiceVMExperiments/main" target="_blank">http://smalltalkhub.com/mc/nice/NiceVMExperiments/main</a> and the list of changes is rather short.<br></div><div>Maybe I forgot some places though, it needs consolidation.<br></div><div><br></div><div>for sizeof(sqInt) != sizeof(void *) that's really more difficult.<br>There are assumptions that objectMemory == machineMemory and avoidance
of oopForPointer() pointerForOop() macros spreaded across Cog/Spur as I
understand it.<br>But we ain't gonna need it until we try to run 32bits image on 64bits VM.<br></div><div><br><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><div>
><br>
> Best,<br>
> Marcel<br>
><br>
><br>
><br>
> --<br>
> View this message in context: <a href="http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953p4906337.html" rel="noreferrer" target="_blank">http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953p4906337.html</a><br>
> Sent from the Squeak VM mailing list archive at <a href="http://nabble.com" target="_blank">Nabble.com</a>.<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></blockquote></div><br></div></div>