Talk:Win64/AMD64 API

Using ml64 is indeed an option, however that one published in the platform sdk from May 2005 is too buggy:

idata$1 segment
; i dd @imagerel(l)
l db "test"
idata$1 ends
_TEXT SEGMENT
PUBLIC myentry
myentry:
       andps xmm0,XMMWORD PTR l
       paddb mm1,mm1
_TEXT ENDS
END

I never got this assembled though it is derived from a file generated by Microsoft-C. Maybe somebody knows how to this.

Using WinDBG would be an option because FPC could insert the source lines as comments in the assembler output so limited debugging should be possible.

--FPK 22:55, 1 Sep 2005 (CEST)

Yes, ml64 is buggy. I wrote a simple wpr0.as with ML64 (without all that idata and rva stuff since I don't know what it's used for :P ) just to keep compiler quiet and tried to compile system unit in win64 to masm output. I didn't expect to have something working (since calling convention was missing), but I was curios to see if masm output would be ok with ml64.

I noticed that ml64 from platform sdk doesn't recognize XMMWORD directive. This keyword was added to visual studio 2005 version of ml64, as this link says: http://msdn2.microsoft.com/library/cw0399sf(en-us,vs.80).aspx and not in platform sdk one (I think). But if cl calls ml64 to produce object files, how is this thing accomplished? It's called with some undocumented parameter?.

I also had some "statement too complex" from ml64 while trying to assemble system unit, and some other problems that now I don't remember.

That's why I was talking about binary writer: all x86_64 targets would benefit from it, and no bothering about buggy external assemblers, though I don't know whether this is an easy thing to do.

Giulio 11:12, 2 Sep 2005 (CEST)

I see no way how to work around the missing xmmword, maybe somebody has an idea. I guess cl uses an internal assembler.

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 and I never found an official documentation about the debugging info used by MS because implementing at least source code/line debugging info shouldn't be that hard.

--FPK 11:28, 2 Sep 2005 (CEST)