flat assembler
Message board for the users of flat assembler.

Index > Main > 64bit ver close to done?

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Consumed



Joined: 30 Sep 2004
Posts: 13
Location: Right behind you
Consumed
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. Very Happy
Post 03 Feb 2005, 19:45
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
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.


Last edited by Tomasz Grysztar on 14 Feb 2005, 11:06; edited 5 times in total
Post 07 Feb 2005, 10:10
View user's profile Send private message Visit poster's website Reply with quote
beppe85



Joined: 23 Oct 2004
Posts: 181
beppe85
I have a question about relative addressing. This is from TEST.ASM:
Code:
mov [0],r9        ; automatic RIP-relative addressing
mov [dword 0],rbx ; forces absolute 32-bit address    

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
Code:
mov [rip+0],r9     ; no automatic RIP-relative addressing anymore
mov [0],rbx ; absolute 32-bit address(default)    


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

_________________
"I assemble, therefore I am"

If you got some spare time, visit my blog: http://www.beppe.theblog.com.br/ and sign my guestmap
Post 07 Feb 2005, 13:01
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 07 Feb 2005, 13:47
View user's profile Send private message Visit poster's website Reply with quote
beppe85



Joined: 23 Oct 2004
Posts: 181
beppe85
Hmmm, thank you for the info. I'll not use x86-64 for the foreseeable future, but curious about. Smile
Post 07 Feb 2005, 13:54
View user's profile Send private message Reply with quote
Consumed



Joined: 30 Sep 2004
Posts: 13
Location: Right behind you
Consumed
The preview looks great. Hope you finish soon. Smile
Post 08 Feb 2005, 06:30
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 08 Feb 2005, 22:18
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
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.
Post 08 Feb 2005, 22:24
View user's profile Send private message Visit poster's website Reply with quote
Tommy



Joined: 17 Jun 2003
Posts: 489
Location: Norway
Tommy
I have an amd64 processor as well.. I will be glad to help you testing the instructions...
Post 09 Feb 2005, 09:15
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
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.


Last edited by Tomasz Grysztar on 16 Feb 2005, 15:46; edited 1 time in total
Post 09 Feb 2005, 17:41
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Post 09 Feb 2005, 23:13
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Laughing

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.

_________________
x86asm.net
Post 10 Feb 2005, 19:18
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 11 Feb 2005, 02:09
View user's profile Send private message Visit poster's website Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
Privalov wrote:
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.

Yup I got one Smile

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

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

_________________
... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself.
- Bradley Kuhn
Post 11 Feb 2005, 12:40
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
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)

_________________
x86asm.net
Post 11 Feb 2005, 19:55
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
Yes, it's true, and fasm 1.60 will tell you so. Smile
Post 11 Feb 2005, 19:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
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:
Code:
mov ah,sil
mov ah,[r8]    

are not encodable - fasm will show you a "prefix conflict" error message.
Post 11 Feb 2005, 20:06
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Your informations are very worth, thanks Privalov!
Quote:
Yes, it's true, and fasm 1.60 will tell you so. Smile

That's pretty annoying, isn't it? Confused
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...

_________________
x86asm.net
Post 11 Feb 2005, 20:14
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 11 Feb 2005, 20:23
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
I worried about it Evil or Very Mad

One more question Wink
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?

_________________
x86asm.net
Post 11 Feb 2005, 20:31
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.