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

[Nicolas Cellier]

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
>>>> <http://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 ;) ).



> 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/1da01753/attachment-0001.htm