[Vm-dev] Re: [Poll] Who is interested in, thinking about, or already contributing to a 64-bit OpenSmalltalk VM for Windows?

Eliot Miranda eliot.miranda at gmail.com
Wed Jul 6 02:04:16 UTC 2016


Hi All,

On Tue, Jul 5, 2016 at 8:06 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
>
> 2016-07-05 15:40 GMT+02:00 marcel.taeumel <Marcel.Taeumel at hpi.de>:
>
>>
>> Nicolas Cellier wrote
>> > I don't promise to spend any time on it, but I've inquired a bit a few
>> > months ago.
>> > The 1st thing required is to convert a bunch of (int) type declaration
>> > into
>> > sqint in platforms/win32 because they're not compatible in 64bits.
>> >
>> > 2016-07-05 11:20 GMT+02:00 marcel.taeumel &lt;
>>
>> > Marcel.Taeumel@
>>
>> > &gt;:
>> >
>> >>
>> >> Hi, there.
>> >>
>> >> I happily observe the recent efforts to make 64-bit VMs stable for
>> Linux
>> >> and
>> >> Mac OSX.
>> >>
>> >> Although Tobias and myself agreed to support the Windows platform in
>> >> terms
>> >> of internal and external plugins such as SqueakSSL and FilePlugin,
>> adding
>> >> 64-bit seems like a lot of work. We have only so much time.
>> >>
>> >> Who's out there interested in, thinking about, or already contributing
>> to
>> >> a
>> >> 64-bit OpenSmalltalk VM for Windows?
>> >>
>> >> Best,
>> >> Marcel
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953.html
>> >> Sent from the Squeak VM mailing list archive at Nabble.com.
>> >>
>>
>> Hi Nicolas,
>>
>>
> Hi Marcel,
>
>
>> if we target Cygwin as a build environment, this might be worth noticing:
>> https://cygwin.com/faq.html#faq.programming.64bitporting
>>
>>
> As currently generated, the Spur Vm for 64 bits expects sizeof(long) == 8.
> So it is cygwin64 x86_64 compatible, but not so much MSVC... (or mingw-w64
> variants...)
> IMO, this is the easiest target. then we could inquire about alternate
> compilers.
>

This is great to hear.  So there is a model where sizeof(long) == 8?  If
that's so, we should target it.  There's a /lot/ of work to do if we have
to support the Win64 sizeof(long) == 4 model.

>
>
>> If we (eventually?) target MS Visual Studio (resp. its C compiler), the
>> code
>> might look different. Not sure.
>>
>> In the Windows (kernel) code, I noticed the use of typedefs, which we
>> could
>> also establish in the vm's windows-specific platform code:
>>
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ff381404(v=vs.85).aspx
>>
>>
> I wonder if we could manage to write code that compiles in both Cygwin
>> 64-bit and the (free) MS Visual C/C++ compiler:
>> https://www.microsoft.com/en-us/download/details.aspx?id=41151
>>
>>
> Yes, it's doable, it's a matter of defining the sq* types and sticking to
> these types.
> But that might mean revising VMMaker package to avoid direct references to
> long/unsigned long/, as well as some of the platforms/* files...
>

There ar emote issues in the type inferencer.  It, and a significant
ammount of code in VMMaker would have to be rewritten to support 64-bit
sizeof(long) == 4.  I think it's infeasible given our current person power,
and I don't think its wrath it.  If we can get there using cygwin ad/or
mingw we should do so.


>
>
>> ... or maybe MS Visual C/C++ only? It would remove Cygwin as a layer of
>> indirection between dev tools and execution platform...  *duck-and-run*
>> :-D
>>
>>
> Using MSVC requires additional support like atomic operations (see
> ../../platforms/Cross/vm/sqAtomicOps.h)
>

Minor difficulty.  MSVC has support for asm.  Further, later versions are
using clang for their compiler and that *may* just have extended asm
support.  And do we know that MSVC doesn't support the relevant intrinsics?

Overall, it should be really simple (and cheap?) to setup a Windows dev
>> environment for VM developers. Maybe for real, maybe in a VirtualBox only.
>>
>
+1.  Please, something that is either arasllels or can be converted into
Parallels.


> This helps Eliot and other cross-platform VM developers to debug like they
>> are doing now.
>>
>
> Using IDE has a lot of advantages, but maintaining the IDE-specific or
> even worse IDE-version-specific project files is not sustainable
> For these reasons, Eliot removed the Xcode projects for Mac, I don't think
> re-introducing them for windows would be a good idea.
> Instead, I much much prefer to generate the project files via cmake.
>

Why do we need project files?  Why do we need cmake?  I don't want to keep
on fighting this battle, please.  Esteban is already working on the issue
of generating the header file that generates just the defines that describe
the platform facilities.  Plugins are selected via plugins.int and
plugins.ext.  Optional compilation can be controlled with the relevant code
in platforms/PLATFORM/plugins/Makefile which can test for available support
libraries and abort creation if so.

We. Do. Not. Need/ A. CMake. Step. Other, Than. To. Define. The.
Platform's. Facilities.

I. Do. Not. Want. Project. Files. Under. Any. Circumstances.

Please, I thought we had reached agreement on this when we discussed moving
to github.


> The question remains whether we maintain the cmakelists.txt or generate
> them from Smalltalk (like Pharo VM)
>
> I like the idea of a virtual machine prepared for dev, but what about:
> - license (unless we can redistribute windows 10?)
> - security (download a virtual machine with unknown installed software,
> backdoors, etc... )
>
>
>> Best,
>> Marcel
>>
>> --
>> View this message in context:
>> http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953p4905015.html
>> Sent from the Squeak VM mailing list archive at Nabble.com.
>>
>
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160705/fbcf925b/attachment.htm


More information about the Vm-dev mailing list