<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-06 9:04 GMT+02:00 marcel.taeumel <span dir="ltr"><<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Eliot Miranda-2 wrote<br>
> Hi All,<br>
><br>
> On Tue, Jul 5, 2016 at 8:06 AM, Nicolas Cellier <<br>
<br>
> nicolas.cellier.aka.nice@<br>
<br>
>> wrote:<br>
><br>
>><br>
>><br>
>><br>
>> 2016-07-05 15:40 GMT+02:00 marcel.taeumel &lt;<br>
<br>
> Marcel.Taeumel@<br>
<br>
> &gt;:<br>
<div><div class="h5">>><br>
>>><br>
>>> Nicolas Cellier wrote<br>
>>> > I don't promise to spend any time on it, but I've inquired a bit a few<br>
>>> > months ago.<br>
>>> > The 1st thing required is to convert a bunch of (int) type declaration<br>
>>> > into<br>
>>> > sqint in platforms/win32 because they're not compatible in 64bits.<br>
>>> ><br>
>>> > 2016-07-05 11:20 GMT+02:00 marcel.taeumel &lt;<br>
>>><br>
>>> > Marcel.Taeumel@<br>
>>><br>
>>> > &gt;:<br>
>>> ><br>
>>> >><br>
>>> >> Hi, there.<br>
>>> >><br>
>>> >> I happily observe the recent efforts to make 64-bit VMs stable for<br>
>>> Linux<br>
>>> >> and<br>
>>> >> Mac OSX.<br>
>>> >><br>
>>> >> Although Tobias and myself agreed to support the Windows platform in<br>
>>> >> terms<br>
>>> >> of internal and external plugins such as SqueakSSL and FilePlugin,<br>
>>> adding<br>
>>> >> 64-bit seems like a lot of work. We have only so much time.<br>
>>> >><br>
>>> >> Who's out there interested in, thinking about, or already<br>
>>> contributing<br>
>>> to<br>
>>> >> a<br>
>>> >> 64-bit OpenSmalltalk VM for Windows?<br>
>>> >><br>
>>> >> Best,<br>
>>> >> Marcel<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> --<br>
>>> >> View this message in context:<br>
>>> >><br>
>>> <a href="http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953.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-tp4904953.html</a><br>
>>> >> Sent from the Squeak VM mailing list archive at Nabble.com.<br>
>>> >><br>
>>><br>
>>> Hi Nicolas,<br>
>>><br>
>>><br>
>> Hi Marcel,<br>
>><br>
>><br>
>>> if we target Cygwin as a build environment, this might be worth<br>
>>> noticing:<br>
>>> <a href="https://cygwin.com/faq.html#faq.programming.64bitporting" rel="noreferrer" target="_blank">https://cygwin.com/faq.html#faq.programming.64bitporting</a><br>
>>><br>
>>><br>
>> As currently generated, the Spur Vm for 64 bits expects sizeof(long) ==<br>
>> 8.<br>
>> So it is cygwin64 x86_64 compatible, but not so much MSVC... (or<br>
>> mingw-w64<br>
>> variants...)<br>
>> IMO, this is the easiest target. then we could inquire about alternate<br>
>> compilers.<br>
>><br>
><br>
</div></div>> This is great to hear. So there is a model where sizeof(long) == 8? If<br>
> that's so, we should target it. There's a /lot/ of work to do if we have<br>
> to support the Win64 sizeof(long) == 4 model.<br>
<span class="">><br>
>><br>
>><br>
>>> If we (eventually?) target MS Visual Studio (resp. its C compiler), the<br>
>>> code<br>
>>> might look different. Not sure.<br>
>>><br>
>>> In the Windows (kernel) code, I noticed the use of typedefs, which we<br>
>>> could<br>
>>> also establish in the vm's windows-specific platform code:<br>
>>><br>
>>> <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ff381404(v=vs.85).aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-us/library/windows/desktop/ff381404(v=vs.85).aspx</a><br>
>>><br>
>>><br>
>> I wonder if we could manage to write code that compiles in both Cygwin<br>
>>> 64-bit and the (free) MS Visual C/C++ compiler:<br>
>>> <a href="https://www.microsoft.com/en-us/download/details.aspx?id=41151" rel="noreferrer" target="_blank">https://www.microsoft.com/en-us/download/details.aspx?id=41151</a><br>
>>><br>
>>><br>
>> Yes, it's doable, it's a matter of defining the sq* types and sticking to<br>
>> these types.<br>
>> But that might mean revising VMMaker package to avoid direct references<br>
>> to<br>
>> long/unsigned long/, as well as some of the platforms/* files...<br>
>><br>
><br>
</span>> There ar emote issues in the type inferencer. It, and a significant<br>
> ammount of code in VMMaker would have to be rewritten to support 64-bit<br>
> sizeof(long) == 4. I think it's infeasible given our current person<br>
> power,<br>
> and I don't think its wrath it. If we can get there using cygwin ad/or<br>
> mingw we should do so.<br>
<span class="">><br>
><br>
>><br>
>><br>
>>> ... or maybe MS Visual C/C++ only? It would remove Cygwin as a layer of<br>
>>> indirection between dev tools and execution platform... *duck-and-run*<br>
>>> :-D<br>
>>><br>
>>><br>
>> Using MSVC requires additional support like atomic operations (see<br>
>> ../../platforms/Cross/vm/sqAtomicOps.h)<br>
>><br>
><br>
</span>> Minor difficulty. MSVC has support for asm. Further, later versions are<br>
> using clang for their compiler and that *may* just have extended asm<br>
> support. And do we know that MSVC doesn't support the relevant<br>
> intrinsics?<br>
<span class="">><br>
> Overall, it should be really simple (and cheap?) to setup a Windows dev<br>
>>> environment for VM developers. Maybe for real, maybe in a VirtualBox<br>
>>> only.<br>
>>><br>
>><br>
</span>> +1. Please, something that is either arasllels or can be converted into<br>
> Parallels.<br>
<span class="">><br>
><br>
>> This helps Eliot and other cross-platform VM developers to debug like<br>
>> they<br>
>>> are doing now.<br>
>>><br>
>><br>
>> Using IDE has a lot of advantages, but maintaining the IDE-specific or<br>
>> even worse IDE-version-specific project files is not sustainable<br>
>> For these reasons, Eliot removed the Xcode projects for Mac, I don't<br>
>> think<br>
>> re-introducing them for windows would be a good idea.<br>
>> Instead, I much much prefer to generate the project files via cmake.<br>
>><br>
><br>
</span><span class="">> Why do we need project files? Why do we need cmake? I don't want to keep<br>
> on fighting this battle, please. Esteban is already working on the issue<br>
> of generating the header file that generates just the defines that<br>
> describe<br>
> the platform facilities. Plugins are selected via <a href="http://plugins.int" rel="noreferrer" target="_blank">plugins.int</a> and<br>
> plugins.ext. Optional compilation can be controlled with the relevant<br>
> code<br>
> in platforms/PLATFORM/plugins/Makefile which can test for available<br>
> support<br>
> libraries and abort creation if so.<br>
><br>
> We. Do. Not. Need/ A. CMake. Step. Other, Than. To. Define. The.<br>
> Platform's. Facilities.<br>
><br>
> I. Do. Not. Want. Project. Files. Under. Any. Circumstances.<br>
><br>
> Please, I thought we had reached agreement on this when we discussed<br>
> moving<br>
> to github.<br>
><br>
><br>
</span><span class="">>> The question remains whether we maintain the cmakelists.txt or generate<br>
>> them from Smalltalk (like Pharo VM)<br>
>><br>
>> I like the idea of a virtual machine prepared for dev, but what about:<br>
>> - license (unless we can redistribute windows 10?)<br>
>> - security (download a virtual machine with unknown installed software,<br>
>> backdoors, etc... )<br>
>><br>
>><br>
>>> Best,<br>
>>> Marcel<br>
>>><br>
>>> --<br>
>>> View this message in context:<br>
>>> <a href="http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953p4905015.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-tp4904953p4905015.html</a><br>
>>> Sent from the Squeak VM mailing list archive at Nabble.com.<br>
>>><br>
>><br>
</span>> _,,,^..^,,,_<br>
> best, Eliot<br>
<br>
Hi,<br>
<br>
oh, I did not explain it sufficiently what I mean by saying "dev<br>
environment". I did not mean putting project files into the repository or<br>
using cmake. No, no, no. I mean a simple document that says how to install<br>
and configure Cygwin or Visual Studio to setup the project. There is imo no<br>
urgent need to provide ready-made project files. A documentation about paths<br>
and compiler flags would be a good first step.<br>
<br>
Best,<br>
Marcel<br>
<br>
<br></blockquote><div>OK my bad, I think i missunderstood.<br></div><div>Still, an IDE does boost productivity, especially when navigating from error messages to source code for example when porting win32 to x64...<br>we don't develop in Smalltalk with vi. But let this apart, it's another thread. With a mixture of SourceTree / WinMerge / cygwin bash ./mvm -f ; less LOGF ; grep -r x86_64 ../../platforms / vim / Notepad++ etc... I've got an ersatz of IDE ;)<br><br></div><div>I've cherry picked a few changes required for compiling a X86_64 windows versions and pushed to main cog branch.<br></div><div>There are many others waiting, but I don't want to commit a massive blob, so I'll continue to slowly decompose if it's ok.<br></div><div>Fortunately the win32 flavour should continue to compile, so I didn't open a separate feature branch (if it lasts too long I fear it would require many rebase and/or merge and that would be boring).<br><br></div><div>Reviews are welcome.<br><br></div><div>cheers<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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-tp4904953p4905088.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-tp4904953p4905088.html</a><br>
<div class="HOEnZb"><div class="h5">Sent from the Squeak VM mailing list archive at Nabble.com.<br>
</div></div></blockquote></div><br></div></div>