<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body 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">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 class=""><br>
<br>
> On Jul 12, 2016, at 12:24 PM, marcel.taeumel <<a href="mailto:Marcel.Taeumel@hpi.de">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 class=""><div class="h5"><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>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>I had hoped we could avoid outright butchery :-(<br><div><br><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">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 class=""><div class="h5">
><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">Nabble.com</a>.<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></div></div></body></html>