My modifications to NASM for general x86-64/x64/AMD64/EM64T support have been uploaded to the NASM CVS.
It will probably take some time for some possible bug fixes and various "official" testing before it will be considered a stable release, but you can be apart of this process to help bring it out as a full release by compiling the latest CVS version and testing various 64-bit code against it!!!
Enjoy :)
It will probably take some time for some possible bug fixes and various "official" testing before it will be considered a stable release, but you can be apart of this process to help bring it out as a full release by compiling the latest CVS version and testing various 64-bit code against it!!!
Enjoy :)
There has already been some major code overhaul due to NASM now trying to be c99 compliant. All significant warning/error messages have been suppressed and I've confirmed this with Dev-Cpp 4.9.9.2 (MinGW 3.4.2), GCC4 for Linux and Pelles C for Win32.
The CVS should reflect this change. However it seems to take SourceForge anonymous CVS from 24-48 hours to sync with the developer CVS.
Also, Charles Crayne has volunteered to implement ELF64 support in NASM. With win64 (MS COFF) support already available, this should complete support for the mainstream 64-bit object formats. Not to mention that Flat Binary and RDOFF already support 64-bit :)
The CVS should reflect this change. However it seems to take SourceForge anonymous CVS from 24-48 hours to sync with the developer CVS.
Also, Charles Crayne has volunteered to implement ELF64 support in NASM. With win64 (MS COFF) support already available, this should complete support for the mainstream 64-bit object formats. Not to mention that Flat Binary and RDOFF already support 64-bit :)
is the syntax for 64bit code already decided, or are only your internal changes uploaded?
is the syntax for 64bit code already decided, or are only your internal changes uploaded?
EDIT: I just remembered one of our previous conversations :!:
If you are referring to how RIP-relative addressing will be handled, we are probably going to keep it consistent with the other segment-relative forms.
In summary, we are shooting for as the syntax of choice for RIP-relative addressing. Simple, yet effective ;)
If THAT wasn't what you were referring to, vid, please let me know as to what you are asking and I'll try to respond as soon as I can :)
yes, i was asking about RIP-relative addressing. But i don't really understand your response.
You mean that "mov eax, " uses absolute addressing, and "mov eax, " uses RIP-relative addressing?
If yes, i don't think it's really the best idea, RIP-relative addressing is what you want 99.99% times in 64bit code.
Also, how will then look like instruction with segment prefix and RIP-relative addressing? "mov eax, "?
You mean that "mov eax, " uses absolute addressing, and "mov eax, " uses RIP-relative addressing?
If yes, i don't think it's really the best idea, RIP-relative addressing is what you want 99.99% times in 64bit code.
Also, how will then look like instruction with segment prefix and RIP-relative addressing? "mov eax, "?
From how I see it, I think it should be a flag, which selects the default behavior (so that one can choose his/her preferred style) and a method to override it. The flag should be changeable at any desired location in the source to allow easy mixing of functions written by different people.
yes, i was asking about RIP-relative addressing. But i don't really understand your response.
You mean that "mov eax, " uses absolute addressing, and "mov eax, " uses RIP-relative addressing?
If yes, i don't think it's really the best idea, RIP-relative addressing is what you want 99.99% times in 64bit code.
Then that is what the programmer must use when they want RIP-relative addressing. NASM doesn't ASSUME.
Also, how will then look like instruction with segment prefix and RIP-relative addressing? "mov eax, "?
CS doesn't apply in long mode, just like DS/ES/SS... but FS and GS are still addressable. Nice catch vid. I'll let the others know about this little oversight. Not much of an issue though, NASM is internally capable of both ATM.
From how I see it, I think it should be a flag, which selects the default behavior (so that one can choose his/her preferred style) and a method to override it. The flag should be changeable at any desired location in the source to allow easy mixing of functions written by different people.
I don't think this would be in tune with NASM philosophy. NASM, more or less, requires the programmer to specify, with an exactitude, what instructions they wish to use. I think one of the things people enjoy about NASM is that it does not make assumptions or hide anything from the programmer.
However, 64-bit (long mode) might break this tradition. I guess we'll see which way things go ;)
SpooK, nasm already added jump destination size optimization ages ago, RIP addressing would be a smart thing as well... ti_mo_n's suggestion sounds like the best way to handle it.
SpooK, nasm already added jump destination size optimization ages ago, RIP addressing would be a smart thing as well... ti_mo_n's suggestion sounds like the best way to handle it.
All-in-all, it is not up to me... but I've forwarded the request to the project managers :)
CS doesn't apply in long mode, just like DS/ES/SS
are you sure about this? No segmentation with CS/DS/ES/SS in longs mode, but yes for FS and ES? Sounds weird to me.
CS doesn't apply in long mode, just like DS/ES/SS
are you sure about this? No segmentation with CS/DS/ES/SS in longs mode, but yes for FS and ES? Sounds weird to me.
If you meant "yes for FS and GS", then I am 100% positive as the others are "allowed" but ignored in long mode... and as per the official docs...
AMD x86-64 Architecture Programmer's Manual, Volume III, Revision 3.12, Appendix C, Page 396 (absolute page 426 in Adobe Acrobat)
Segmentation:
CS, DS, ES, SS segment bases are ignored
CS, DS, ES, FS, GS, SS segment limits are ignored
CS, DS, ES, SS Segment prefixes are ignored
GoASM, YASM, diStorm and GAS agree... not sure about FASM, though.
"mov eax, "?
That would be kinda weird, but don't forget that NASM also supports the regular prefixing syntax:
cs mov eax,Which wouldn't look as bad. I tend to use this method when working with structures in other segments that are pointed to by variables. ie (taken from some REALLY old code of mine) :lol:
ES mov , AX ; store color in screen table.If you meant "yes for FS and GS", then I am 100% positive as the others are "allowed" but ignored in long mode... and as per the official docs...
Bleh, does it say why it ignores them now? Doesn't really make since to me to drop support for segment prefixes, as it does add for code clearity and organization.
"mov eax, "?
That would be kinda weird, but don't forget that NASM also supports the regular prefixing syntax:
cs mov eax,Which wouldn't look as bad. I tend to use this method when working with structures in other segments that are pointed to by variables. ie (taken from some REALLY old code of mine) :lol:
ES mov , AX ; store color in screen table.That would be kind of interesting... and I would have to re-train myself... again :O
Right now we are leaning towards simply using . However, we are contemplating using , in the same manner that works. In this case, FS/GS would be and it should stay rather consistent. The catch being that we would also have to implement for cases where would look a bit bulky.
However, I think we've firmly decided to stay away from the over-complexity that YASM uses (e.g. ). The reason being is that NASM can (and does) internally make the distinction between labels (local and global addresses) and immediate values (numeric constants and assigns/defines)... and RIP-relative addressing is no exception.
At any rate, some things are up in the air ATM and I will let people know if anything is decided before I go on my vacation :)
If you meant "yes for FS and GS", then I am 100% positive as the others are "allowed" but ignored in long mode... and as per the official docs...
Bleh, does it say why it ignores them now? Doesn't really make since to me to drop support for segment prefixes, as it does add for code clearity and organization.
Probably due to the fact that segmentation is all but deprecated (still used for privilege checks, but forced to be "flat") in long mode. Personally, I think it is about time that they stop waisting their effort on an obsolete addressing mechanism. Though, as an OS developer who favors "paging" if anything, I am biased in that respect :P
It almost seems FS/GS are still used to appease the please-don't-break-Microsoft-code gods :lol:
Well, segmentation is a relic from the past, so that's why it's now deprecated ;) Paging is a lot more cool ^^ The stuff that SpooK quoted from AMD's manuals also holds true for Intel CPUs, obviously, since there is a similiar sentence in their manuals ^^
FS is useful enough for pointing at per-thread information, which is probably why it was kept - easier (and faster?) to change FS on a thread context switch instead of, say, remapping a virtual address.
True, this is precisely why fs and gs were kept ^^ They are, kind of, "general purpose, OS-specific registers" :)
True, this is precisely why fs and gs were kept ^^ They are, kind of, "general purpose, OS-specific registers" :)
Darn, I was hoping it was from all that hard work in adding FS and GS to the 386 :(
Poor SpooK :( :P