Hello.
Since I love to play with things I don't understand ( :P ), I collected some infos on win64 for amd calling convention, played a little with cl and ml64 to see how code was generated.
I put infos on win64 for amd wiki page
(http://www.freepascal.org/wiki/index.php/Win64/AMD64_API), they might be useful if someone is starting to write something for that target. I don't know fpc internals and I don't ever know where to start to make a port, so this is all I can do :P

Well, as already pointed out in the wiki talk page, the problem for a usable port is a good assembler/linker/debugger tool chain.

did u try any contact with AMD ?
(a little 'powered by AMD64' logo on fpc site could help ;-) )

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

fasm is usable.

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

A binary reader helps very little.

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

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.