[fpc-devel] Windows 64 for amd

[Florian Klaempfl]

Giulio BERNA wrote:

> 
>> Well, as already pointed out in the wiki talk page, the problem for a
>> usable
>> port is a good assembler/linker/debugger tool chain.
>>
> Yes, I sent this mail yesterday after writing wiki, but mailing list
> seemed to have problems since message arrived only today. You saw wiki
> before my mail arrived (hehe, I wasn't aware of "Recent changes" link in
> wiki :P )
> Since mailing list seems to work now I'll write here instead of writing
> on the wiki talk page.
> 
> I played a little and discovered that you were right, ml64 isn't used at
> all by cl, it uses an internal assembler (nothing illegal: i simpy
> replaced ml64 with a program that would display command line arguments,
> but cl didn't call it).
> 
> There is free edition of visual c++ 2005 (visual c++ 2005 express
> edition) but it does not include ml64, so I think that the "working" one
> is in full edition of visual c++ 2005, which costs a lot of money and is
> not available for free (you must pay something and subscribe to some
> microsoft thing and then you can download the beta).
> So, very bad news from ml64 side.
> 
> Well, there is yasm. It should be a nasm-compatible assembler with
> x86-64 support (and also support for pe+ files, so currently you can
> make programs for win64 with it).
> 
> In fpc there is nasm output syntax, so it can be upgraded to handle 64
> bit syntax.
> Bad news: yasm is very young and is not considered to be stable at all,
> so neither this option seems to be usable :\

fasm is usable.

> 
> However, I understand that nothing official and usable can be made
> before binutils and gdb are ported on win64, so I tried to focus on what
> could be done that can be used later without "losing time" with
> temporary hacks.
> So I still haven't understood a couple of things (I'm ignorant on fpc
> internals :P ), tell me if I am wrong:
> - calling convention is now well defined. I thought it could be
> developed and tested on linux-x86_64.
> I mean, it can be tested and debugged writing pascal code like:
> 
> function letstry(various arguments);
> whateverthiscallingconventionwillbenamed;
> 
> ...
> 
> letstry(various arguments);
> 
> This should allow testing of calling convention mechanism.

This is easy to do. Real testing must be done when calling api functions.

> 
> - binary writer thing: it exists for i386, in todo for 2.2 there is a
> "Internal assembler for non-x86 platforms" line.
> So binary writer for x86_64 is something from which today platforms
> (linux and bsd for x86_64) could benefit, regardless of win64 port.
> I thought that a binary writer is almost identical on various targets
> that run on the same architechture (machine code is the same, even if
> it's put in different places in elf64 files or pe+ files, but that
> shouldn't be a big issue) so once written and tested on x86_64 linux it
> should be ready for win64 without a lot of additional testing.

A binary reader helps very little.

> 
> I thought that these things could be made regardless to toolchains
> available for win64. This will not lead to a working win64 port since
> debugging support is still missing, but it can be a big step forward
> while waiting for binutils and gdb, and maybe windows rtl could start to
> be adapted meanwhile.

How do you want to get things running without usable debugging
facilities? Debugging basic rtl, calling conventions etc. require a
working debugger.

> 
> You wrote:
> "Making an internal assembler for FPC wouldn't be that hard but it makes
> debugging harder because source code can't be inlined to have at least
> some kind of source code debugging "
> I don't understand: are you talking about debugging win64 programs? Ok,
> this couldn't be done until gdb is ported but I wasn't thinking about
> this: I simply said that it could be a step forward while waiting for
> gdb to be ported.ù

With a working ml64 and windbg it could be done reasonable.

I think the way to go would be that we adapt binutils and gdb ourself.