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

Wed Jul 6 17:36:18 UTC 2016

2016-07-06 9:04 GMT+02:00 marcel.taeumel <Marcel.Taeumel at hpi.de>:

>
> Eliot Miranda-2 wrote
> > Hi All,
> >
> > On Tue, Jul 5, 2016 at 8:06 AM, Nicolas Cellier <
>
> > nicolas.cellier.aka.nice@
>
> >> wrote:
> >
> >>
> >>
> >>
> >> 2016-07-05 15:40 GMT+02:00 marcel.taeumel &lt;
>
> > Marcel.Taeumel@
>
> > &gt;:
> >>
> >>>
> >>> 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
>
> Hi,
>
> oh, I did not explain it sufficiently what I mean by saying "dev
> environment". I did not mean putting project files into the repository or
> using cmake. No, no, no. I mean a simple document that says how to install
> and configure Cygwin or Visual Studio to setup the project. There is imo no
> urgent need to provide ready-made project files. A documentation about
> paths
> and compiler flags would be a good first step.
>
> Best,
> Marcel
>
>
> OK my bad, I think i missunderstood.
Still, an IDE does boost productivity, especially when navigating from
error messages to source code for example when porting win32 to x64...
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 ;)

I've cherry picked a few changes required for compiling a X86_64 windows
versions and pushed to main cog branch.
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.
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).

Reviews are welcome.

cheers

>
> --
> 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-tp4904953p4905088.html
> Sent from the Squeak VM mailing list archive at Nabble.com.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160706/9c18826c/attachment-0001.htm