Re: 64-bit experiment

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/04/17 14:52, Earnie wrote:
> On 4/2/2017 3:47 PM, Cesar Strauss wrote:
>> Following a recent thread on building a MinGW.org cross-compiler
>> from scratch, I became curious about seeing how far I could get by
>> targeting "x86_64-pc-mingw32" ...

What does this oxymoron mean?  32-bit code, for use on a 64-bit CPU?  
Why would I want that?  Or is it just an innately stupid choice of
name?  If the latter, *we* should avoid it; surely for preference it 
should be "x86_64-pc-mingw64", (and "mingw64" should be adequate 
shorthand).

>> ... instead. After severely hacking at the MinGW.org runtime and
>> w32api, I finally got a 64-bit "hello world" executable which runs
>> on Wine and Windows 10. I neither looked [at] nor used any code
>> from the mingw-w64 project.

Good.  Please keep it that way.

>> I did not try building a 64-bit DLL yet.
>>
>> 64-bit support in binutils and gcc was already there, thanks to
>> Kai's work upstream. For w32api, I used our gendef tool on the
>> Windows 10 kernel32.dll and msvcrt.dll. For the runtime, I removed
>> from the build all files with 32-bit assembly code.

Ultimately, those will need to be converted, (or better still adapted 
for multi-arch use); it may still need some work, but I added _some_ 
64-bit awareness in (e.g.) mingwex/math/log_generic.sx

>> Also, exported symbols now have a different number of underscores.

IIRC, the 32-bit compiler prefixes a single underscore to each public 
symbol name, in generated assembly code, whereas 64-bit does not.  In 
hand-crafted assembly code, the additional underscore must be added 
by hand.

>> A few routines in the startup code had to be removed to avoid
>> crashes at runtime.

Can you enumerate them, please?

>> Going forward, we could begin to develop a proper 64-bit port of
>> our runtime and w32api.  The first roadblock, I think, is the
>> startup code.

Seems like a good place to start; we should conditionalize, to make 
it as multi-arch as possible.

> Please go forward with your work.  Put it in the repository
> somewhere.

Maybe create a "branch" for 64-bit development?

>> Now, this brings the question: does our reservation against using
>> the w32api of the mingw-w64 project extends to their startup code?
>> If not, it would be much easier to simply merge back their runtime
>> code.
> 
> I've been waiting on Keith to respond.

As I fully intended to do; it's just taken me a few days to acquire 
a tuit of the appropriate form factor :)

>> Otherwise, we can proceed by trial and error. In that case, we can
>> take the opportunity to properly document the process for which we
>> arrived at the final result. If this does not work, we can later
>> reconsider looking at their startup code.
> 
> This may be the better choice.

I agree; better to avoid the poisoned chalice.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJY585BAAoJEMCtNsY0flo/TZcP/2I307Ri46RpLjbw4Nn2kgRb
0Gd+7aKqFgOKcmV54FXy/TX+qnIeGnYlgm6cLzq96B2QBtSgg0xlpoa9NXjflVDT
jYj4WP/v2fVVZzwTjukMI9ZjuBWt/eYhKvjvjzXon0ciZ9/VmNt/jd1pr7/oH0wG
NLLsOOROZcw4pVy8iMBWjJ8jbpYhgegsYtEqMBY1QOaG9sO2EplwD7j3NExHqHfA
G4vNDBIAO+0opv7tJQLC+7ioFd5uPEUMX67VwYOVFeJaRlG6nDpAafF54WYKI0mQ
ye9pJUUr+yVGofs0IBN0juYCKJpdtDFBZAwPdXdVdD8UjE6tWwlJ5MzC1e/VbBJz
LmQd11RPUFZNia150rjGeGpacxaVYJyZ/ZzUPXhm/UUTjgYwtW+PzMUPDsJbXbTG
vJYQisNhmGnp6pWh1brRo+oG7ANR9jOMQdYYDcNO/g2Ka5NwEjFfbAQeEGvm43D7
MzJm1M+pgtsm0Phv+1BXtReTDqAzxsun5WZbAXyBmEPB8HiXTm8tGcUTglofiMbO
MrTqSFDFn/2uPGiMOJGcwKQktSg/D9cfEaTxQVnUbxUVUUaP2LqouMo+PjHB1lsd
9RcWhbBDAOl+SguNRtkA1o5gQgeepKHzRd0lhtHVHuaR2w8YkKndCtQdRb1vJ2PP
pXGw3WvWNsDL5NqlmNre
=Fsfm
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot