[fpc-devel] Windows 64 for amd

[Giulio BERNA]

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

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.

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

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.

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

bye
Giulio