I've seen the topics about a fasm for amd64 and I was wondering how far along it is, and if we could see a preview/demo ? I'm making an os and want a 64bit version of it, which is why I can't wait until the 64bit fasm comes out.

After making some initial progress I paused because it required some problematic syntax decisions and then I forgot about it for a several weeks. But I returned to it two days ago and managed to solve all the problems this time - I'm going to finish encoding of all the long mode instructions soon, and this will make final 1.60 release (the development is aimed at 1.64 as a final stable release with full 64 bits support, this will also need to implement some additional output formats). For the impatient ones, here's the first preview of the forthcoming 1.60 release.

Note: 1.5x line may still be updated independently for those who don't want x86-64 support, however 1.6x is its natural successor.

Attachment removed - the pre-release is now available in Download section.

I have a question about relative addressing. This is from TEST.ASM:

Currently, FASM would use the same (absolute) addressing for both. IMO this is of concern when porting to 64 bit.

Would not be better to use other scheme to represent relatives? I propose exposing rip, like


OFF-TOPIC: There's relative addressing in IA32? I mean for data. Thank you.

The absolute addresses cannot be used by default, they are 32-bit only and only RIP-relative addressing will work for 64-bit addresses above 4 GB. Please also note that [0] after conversion to relative address is [rip+0-offset_of_next_instruction], not [rip+0]. There is no 64-bit direct addressing (with one exception for MOV instruction with accumulator operand) in AMD64 and therefore RIP-relative addressing should be used by default (and it also fits into the fasm's optimization ideas).

Hmmm, thank you for the info. I'll not use x86-64 for the foreseeable future, but curious about.

The preview looks great. Hope you finish soon.

Updated the preview version, the large part of instruction set is now fully supported.

Does anyone have an AMD64 architecture processor? I need to test a few instruction and I would be very grateful if someone helped me.

I have a 64-bit amd64 Linux box that I can test on if that'd be a help.

I have an amd64 processor as well.. I will be glad to help you testing the instructions...

The problems I have met so far:

Problem 1: 32-bit addressing in long mode
There is a special SIB-based encoding which allows to use 32-bit displacement as an absolute address value. What interests me is whether the address size prefix (67h) has the effect on it (and therefore whether fasm should put this prefix there). I suspect that without 67h prefix it would sign-extend the 32-bit value to 64-bit address, and with 67h it would zero-extend it, but the manuals are not clear enough about it.

Possible solution:
Execute LEA RAX,[DWORD -1] in long mode with and without the 67h prefix. Compare the results.

Problem 2: special NOP handling
Since the default operand size in long mode is 32 bits, the 90h opcode should mean the XCHG EAX,EAX instruction. But when doing the operations on 32-bit registers in long mode, processor zero-extends them into the full 64-bit registers. So opcode 90h would not act as NOP, as it was before, because it would clear the upper 32 bits of RAX register. The AMD64 manuals mentions that the 90h opcode is a special case and is treated as NOP anyway, so to perform XCHG EAX,EAX operation the longer form of XCHG instruction should be used. The Intel IA-32e manuals define NOP as 90h and XCHG EAX,EAX too, not even noting the inconsistency.
What I need to know in order to make fasm encode those instructions correctly is whether the 90h is really treated specially, and in case of positive answer, whether it can still be used with REX prefix, to encode things like XCHG EAX,R8D.

Possible solution:
Execute the 90h opcode with RAX=-1, check whether RAX changes. Execute the 41h,90h opcode with R8D different than EAX, check whether the exchange happens.

Problem 3: JMP, CALL and RETF
These are really a mess. The near jump, call and return default to 64-bit, so 32-bit form is not encodable, and RET is the same as RETQ in 64-bit mode. So far, so good. The 16-bit ones can be encoded with 66h prefix, and AMD64 manuals seems to allow it, however the IA-32e manual mentions that 16-bit forms are not supported and the results are unpredictable. Well, I can still allow fasm to encode them and leave the risk to the programmer. The real problems begin with the indirect far branches (the direct far branches are forbidden in long mode - at least this is clearly stated in both manuals): they do not default to 64 bits, so it's possible to branch with mem16:16 and mem16:32 addresses. Intel manual lists also the mem16:64 form, but nothing like that is mentioned in AMD books. It's also possible to encode the 16-bit, 32-bit and 64-bit version of RET. The default, without any prefix, is 32-bit one - and I really don't know whether fasm should encode simple RET as RETD (without any prefix) or RETQ (with the 48h prefix). With the IRET I have already decided to encode simple IRET as a two-byte IRETQ, because in 16-bit and 32-bit modes fasm encoded IRET always as the size default for the given mode. Even though all Intel and AMD manuals define IRET as a 16-bit instruction and IRETD as a 32-bit one, (there is not such thing is IRETW there).

Possible solution:
Don't know yet.

you could ask MazeGen, he is living processor manual. he is registered on forum, but i can't find his profile to PM him now.

Since I still have a lot of work on my dynamic x86-32 code analyser, my knowledge of x86-64 is poor.

It is also necessary to test conclusions from the manual practically in some dis/assembler, but I still don't own such processor.

BTW, I personally don't like x86-64, it is horrible double-patched x86-16 architecture (from 1978) with many complicated constructs. I believe that sooner or later we will switch to Itanium.

I also didn't like it at first, but - after all - it has its logic (except for the few things that caused the problems I noted above).

Yup I got one

I'll donwload the latest copy, and see if I can give some i/o

[edit]Hint for linux users: unzip like this to get nice names =) "unzip -d fasm160-pre4 -LL fasm160-pre4.zip"[/edit]

If the following question is an off-topic in this thread, simply ignore it.

I'm actually finding my way to understand x86-64. There was a question about REX prefix and so on, so I would like to know whether we can do PUSH r/m32 in long mode. According to AMD manual and the refered discussion, it is seems we can only do PUSH r/m16 and PUSH r/m64 without PUSH r/m32, is that true?

(Look at the PUSH description with r/m32 (FF /6) and r32 (50+r) operand)

Yes, it's true, and fasm 1.60 will tell you so.

As for that discussion: REX prefix 40h is needed to access the SPL, BPL, SIL and DIL registers - without REX prefix their codes would still mean AH, CH, DH or BH. Also for this reason you cannot use one of the high-byte registers and a register that needs REX to be encoded in the same instruction. So instructions like:

are not encodable - fasm will show you a "prefix conflict" error message.

Your informations are very worth, thanks Privalov!

That's pretty annoying, isn't it?
That's why I said "horrible double-patched" architecture.

Could you say yet whether we can run x86-32 code without modifications/recompilation in long mode? EDIT: I have in mind, of course, pure OS-independent code, I didn't mean API calls or so.
As I see it, heavily used implicit 64-bit instructions like CALL/RET, PUSH/POP, PUSHFQ/POPFQ will not cause problems so it should be working...

Not really, since the memory addressing in long mode changes meaning - first it defaults to 64-bit, second - the 32-bit displacement encoding in long mode means the RIP-relative address.

I worried about it

One more question
Say I never use indirect jump with an explicit operand (such as jmp eax or call [eax]) and never call any external function, such as winapi. Will my x86-32 code compile for long mode without any modifications?