<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-12 23:29 GMT+02:00 Henrik Sperre Johansen <span dir="ltr">&lt;<a href="mailto:henrik.s.johansen@veloxit.no" target="_blank">henrik.s.johansen@veloxit.no</a>&gt;</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>
Eliot Miranda-2 wrote<br>
&gt; Hi Marcel,<br>
&gt;<br>
&gt;<br>
&gt;&gt; On Jul 12, 2016, at 12:24 PM, marcel.taeumel &amp;lt;<br>
<br>
&gt; Marcel.Taeumel@<br>
<span><br>
&gt; &amp;gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Hi Nicolas,<br>
&gt;&gt;<br>
&gt;&gt; I suppose there are several places in some low-level parts of Cog/Jit<br>
&gt;&gt; where<br>
&gt;&gt; Long and Pointer-Type are used interchangeably. One would have to fix<br>
&gt;&gt; that<br>
&gt;&gt; first. Only then, we can start caring for interfacing the win-api<br>
&gt;&gt; correctly.<br>
&gt;<br>
&gt; That&#39;s right.  Throughout the Cogit is the assumption that sizeof(long) ==<br>
&gt; sizeof(sqInt) == sizeof(void *).  That&#39;s why I&#39;m hoping we can use a C<br>
&gt; compiler which obeys this for win64.  It is nontrivial to fix, as I&#39;ve<br>
&gt; already discussed.  Did my words fall on deaf ears and you&#39;re proposing to<br>
&gt; go ahead?<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Best,<br>
&gt;&gt; Marcel<br>
&gt;&gt;<br>
<br>
</span>Hi Eliot.<br>
Not deaf ears, but neither option seems trivial to me; a large portion of<br>
the platform support code on Windows link against platform libraries.<br>
Given the choice between having to rewriting all that to use only<br>
Cygwin-provided libs*, or changing to a  non-cygwin mingw-w64 based LLP<br>
build env, and fixing cogit to disambiguate long and void */usqintptr, I&#39;d<br>
rather spend what effort I can on helping achieve the latter.<br>
<br></blockquote><div>+1 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The nice thing is the three required parts (platform, cogit, build env) can<br>
all be achieved independently, while keeping the 32bit-build stable; there&#39;s<br>
no explicit requirement to get an LLP build env running before even starting<br>
to look at fixing cogit, and only when that works, look at platform<br>
integration (ref. Nicolas&#39; comments about warning-based fixes)<br>
 </blockquote><div>+1<br><br>allmost independent.<br></div><div>There&#39;s for example:<br><br>   extern unsigned long maxOldSpaceSize;<br><br></div><div>in sqWin32Main.c<br><br></div><div>Transformation to usqIntptr_t has to be synchronized with VMMaker.<br></div><div><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">
Cheers,<br>
Henry<br>
<br>
* As well as disallowing all use of natively compiled 64-bit libraries on<br>
windows that include a long argument (or, to stay safe, anything not<br>
provided by cygwin), and forever more binding the windows 64-bit build to a<br>
Cygwin environment/compiler<br>
<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
--<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-tp4904953p4906365.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-tp4904953p4906365.html</a><br>
<div><div>Sent from the Squeak VM mailing list archive at Nabble.com.<br>
</div></div></blockquote></div><br></div></div>