Re: 64-bit experiment

On 4/7/2017 1:37 PM, Keith Marshall wrote:
> 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).
> 

-mingw64 already exists as a choice in config.guess and config.sub.

>>> ... 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.
> 

The 64bit references also do not carry the @# suffix to indicate the
argument bytes.

>>> 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.
> 

IIRC _win64 is defined as well as _win32 by the compiler.  The absence
of _win64 is what can be used to indicate 32bit versus 64bit.

>> Please go forward with your work.  Put it in the repository
>> somewhere.
> 
> Maybe create a "branch" for 64-bit development?
> 

That was my thought.

>>> 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 :)
> 

I knew that, just took longer than _I_ wanted. :D

>>> 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.

Yes.

-- 
Earnie

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