[Vm-dev] [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
Tue Jul 12 21:19:52 UTC 2016


Hi Nicolas,

> On Jul 12, 2016, at 12:45 PM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> 
> 
> 2016-07-12 17:37 GMT+02:00 Henrik Johansen <henrik.s.johansen at veloxit.no>:
>>  
>> 
>>> On 07 Jul 2016, at 12:45 , Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> 2016-07-06 4:04 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>>>  
>>>> 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>:
>>>>>> 
>>>>>> >>
>>>>>> >> --
>>>>>> >> 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.
>>> snip...
>>> 
>>> After inquiring a bit more, that's not going to be that easy...
>>> Yes, x86_64-pc-cygwin-gcc.exe is LP64 and Spur64 compatible, but it lacks all the interfaces used by platforms/win32 (like _fmode _O_BINARY etc...)
>>> On the other hand, x86_64-w64-mingw32-gcc.exe has all the required win32 interfaces but is thus LLP64.
>>> 
>>> Thus, either we use cygwin, switch to a unix architecture, and loose a bunch of win32 specific features (Direct3D etc...). But how to provide the interface to window manager/GUI?
>>> Or we take the longer path to get VMMaker work on LLP64 (sizeof long == 4, sizeof(long) < sizeof(char *)).
>>> 
>>> Nicolas
>> 
>> In the interest of making this switch easier, I've looked into setting up a build env on Windows using MSYS2 + mingw-w64 rather than cygwin (which would also mean a substantial upgrade of gcc version for windows builds to 5.4), here's what I've done so far to get a building (but crashing) vm:
>> 
>> - Download and install MSYS2 (https://msys2.github.io)
>> - Run update procedure of base system (update-core + exit,  followed by repeated pacman -Suu + exit. Might need to make new shortcuts to msys2_shell.cmd -mingw64 / msys2_shell.cmd -mingw32 after all is said and done)
>> 
>> - Install compiler:
>> x86: pacman -S mingw-w64-i686-gcc
>> x64: pacman -S mingw-w64-x86_64-gcc (currently unused)
> 
> Yes we can do it directly through MSYS+MINGW or load the appropriate MINGW cross compiler packages in CYGWIN64...
> I think the cygwin64 setup is easier (see the *.yml files for setting up the bot jobs)
> 
>> Install tools:
>> make: pacman -S make	(yeah, it's needed)
>> git: pacman -S git    (for updateSCCSVersions)
>> 
>> Install additional packages used by VM + plugins, for corresponding i686 or x86_64 compiler:
>> Haven't determined what's actually needed for a non-crashing build yet.
>> 
>> copy build.win32x86 to build.win32x86.MSYS2 folder, as new base for modified build.
>> I chose to run test .mvm's in squeak.cog.spur target directory, so when that's referenced below, the same changes would be needed in other target dirs as well.
>> All "run" steps below in a mingw32 shell; I did however check in mingw64 shell that the combo is LLP on 64-bits.
> Yes it's LLP64.
>  
>> remove cygwin-specific flags removed in new gcc's/ add flags for newer gcc:
>> in build.XXXX/common/Makefile and Makefile.plugin, 
>> remove -mno-cygwin params (removed in GCC 4.something, shouldn't have much affect since we're not using cygwin at all)
>> add -mno-stack-arg-probe after -mno-accumulate-outgoing-args (prevents lots of warnings that maccumulate-outgoing-args is needed to probe stack args)
>> Same flag changes needed to Makefiles in 
>> platforms\win32\plugins\BochsIA32Plugin
>> (should probably be moved to build.XXXX\somewhere if possible, 
>> or -mno-cygwin made a var like EXPORT below that is easy to change; 
>> since these files are outside target directory, just removing like I did will  affect cygwin builds).
>> 
>> remove -lcrtdll from STDLIBS, (lets MinGW link to msvcrtdll.a only, with both there will be duplicate definition errors)
>> comment out line 160, remove comment on 161 in Makefile (aka use EXPORT:=--export-all-symbols)
> 
> Yes the makefile are for a really outdated cygwin version (1.4.something).
> But you can workaround most problems by passing extra arguments to make (via mvm -- EXTRA-MAKE-ARGS)
> 
> As long as Eliot use this cygwin config, I hesitate to change anything. It would be necessary to test compatibility of changes with legacy cygwin. But this brand is not distributed anymore. With time machines I succeeded into installing a cygwin 1.5, but it was not functional, so I gave up...
> 
> We ought to convince Eliot that it's time to revise (Hi Eliot ;) ).

I bought a copy of 64-bit XP and so am looking for time to create a fresh Cygwin install.  Feel free.  Provided that Travis can correctly build the win32 VM I'm happy.

> 
>  
>> disable SocketPlugin:
>> It had some fun issues redefining stuff, dunno if the subsequent removal of crtdll would have fixed things, but for now, I disabled it.
>> To do so, some source changes were needed to avoid build failures:
>> - add -DNO_NETWORK to DEFS  in Makefile (line 146-147)
>> - add #ifndef NO_NETWORK guards around
>> 	int win32DebugPrintSocketState(void);
>> 	in platforms\win32\vm\sqWin32Exports.c and platforms\win32\vm\sqWin32Prefs.c
>> - remove SocketPlugin from plugins.ext
> I think it's better to use winsock 2 (-lws2_32.lib or something like this)
>  
>> fix Mpeg3Plugin defining things it assumes is missing on windows, but isn't with mingw64:
>> change #if (... || defined(WIN32)) 
>> before NEEDSTRFUNCS 
>> in platforms\Cross\plugins\Mpeg3Plugin\libmpeg\changesForSqueak.c
>> to #if (... || (defined(WIN32) && !defined( _WIN32 ))) 
>> (could probably be nicer, however _WIN32 is defined on mingw / microsoft compilers, but not on cygwin platform, so works as distinguisher)
>> 
>> setup git and update vm versions, so rc compilation doesn't fail:
>> git config --global user.email "your at email.com"
>> git config --global user.name "John Doe"
>> run /scripts/updateSCCSVersions
>> 
>> configure bochs: 
>> change
>> --target=i686-pc-mingw32 \ 
>> to
>> -target=i686-w64-mingw32 \
>> in build.win32x86.MSYS2\bochsx86\conf.COG
>> then ./conf.COG and ../../processors/IA32/bochs/makeem from that folder
>> 
>> build vm:
>> run .mvm -a in build.win32x86.MSYS2 (with -a to build just the assert version, for speeding things up)
>> 
>> VM will now build, but crash after selecting an image file.
>> Time to investigate what additional packages are needed, and/or look at resolving some of the warnings generated during build, there's lots of "implicit definitions" to start from.
>> 
>> Cheers,
>> Henry
> 
> Hmm I've produced the 32bits VM with i686-w64-mingw32-gcc on cygwin64, and I think I tested it succesfully, but now you give me a doubt. I have to try again. This is how the travis (appveyor...) artefacts are built.
> 
> On the 64bits side, I've managed to eliminate the warnings about (conversion to/from pointer from/to integer of different size) realted to LLP64, with appropriate changes in VMMaker and platforms files.
> Still the 64 bits image does not start yet (the VM quits).
> 
> Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160712/91a4ec38/attachment.htm


More information about the Vm-dev mailing list