flat assembler
Message board for the users of flat assembler.

Index > Main > 64bit ver close to done?

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Well, it should. Assuming you don't use any of the instructions that are forbidden in long mode (like PUSHA/POPA) and your code will have to reside in the 32-bit addressable memory (in case when you do some addressing like [ebx]).
Post 11 Feb 2005, 20:36
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 reckon that a lot of assembly programmers will ask similar questions many times soon, since new architecture is going to be widely used, thanks.
Quote:
your code will have to reside in the 32-bit addressable memory

Could it be a problem, say, under 64bit windows OS?
Post 11 Feb 2005, 20:45
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
I don't know enough about the 64-bit Windows yet.
Post 11 Feb 2005, 21:05
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Yea, we have to learn something new...
Privalov wrote:
...So instructions like:
Code:
mov ah,sil
mov ah,[r8]    

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

Shouldn't it be "invalid operand combination"? Coders who don't know about machine encodings, like REX prefix etc. will be confused and say "hey, fasm bug - I didn't use any prefix there!"

_________________
x86asm.net
Post 11 Feb 2005, 21:28
View user's profile Send private message Visit poster's website Reply with quote
gumletis



Joined: 18 Dec 2004
Posts: 128
gumletis
Im happy with 16-bit and 32-bit windows gui programming Razz
Post 11 Feb 2005, 21:47
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
I've updated the attachment with the fifth pre-alpha - now should encode properly all the general-purpose and system instructions in long mode. The FPU/MMX/SSE instructions may still need to be fixed, but generally there won't be many changes needed in that code, so the first beta release of 1.60 is near.
I've decided to encode RETF in the way similar to IRET and also to support even the Intel-only extensions to the instruction set (like the 80-bit far jump/call and the CMPXCHG16B) - the problem 3 might be considered closed.
As for the prefix conflict error message - I've changed it to "unallowed combination of registers".
Post 11 Feb 2005, 22:16
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
just a litte typo there: "unallowed" should be "disallowed" (afaik),but imo "invalid combination of registers" is even better.

btw, does anyone here know any kind of debugger that remotley resembles of ollydebug for linux? (gdb/ddd is imo not quite working...)
Btw, will there be support for something like "format ELF64"/"format ELF64 executable" in the beta (or earlier)? Or must one write the elf64 headers manually for the time beeing?
Post 11 Feb 2005, 22:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
The complete x86-64 instruction set is now supported, and I've put the pre-release into the official "Download" page.

I've decided to use the new versioning system, where the even minor version number means the stable release, and odd one means the development release. So the 1.58 and 1.60 mean the stable versions, while 1.59 is the development stage.
Post 14 Feb 2005, 11:16
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Time to add some 64-bit output formats...
Have you seen any AMD64-specific reference for ELF64? I've got the general ELF64 specification, but I need some field values and guidelines for x86-64 that are not given there.
Post 14 Feb 2005, 12:44
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
This far all I've found are these docs:
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p39.html
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p40.html#CHAPTER6-35342
http://uw713doc.caldera.com/en/SDK_cprog/OF_ELFHeader.html
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p40.html#CHAPTER6-35342

I'm currently trying to get a basic elf 64-bit working... not sure how it works, tried to get a elf 32-bit working first, but only got " ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, corrupted section header size" from file and the app didn't run... I haven't yet tried to compile/run the 64-bit test yet - I'll report if I get it working.
Post 14 Feb 2005, 15:28
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
btw. i like fasm 1.64 more than 1.60 it has something about it and i don't think anyone will loose those 3 versions.
Post 14 Feb 2005, 15:33
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Post 14 Feb 2005, 15:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Quote:
btw. i like fasm 1.64 more than 1.60 it has something about it and i don't think anyone will loose those 3 versions.

I want 1.64 to be the really final and fully featured version for x86-64, that's why I'm starting with 1.60.
Post 14 Feb 2005, 15:51
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
Quote:
I want 1.64 to be the really final and fully featured version for x86-64, that's why I'm starting with 1.60.

imo that's good Smile like the sound of "fasm 1.64" ("fasm (point) 64" or "fasm 1 point 64").

This is as far as I've gotten btw:
Code:
[05:56:20]frekla@zeus elf64 $ ./fasm64 t.asm t ; file t /bin/true ; eu-readelf -h t; ./t
flat assembler  version 1.60 pre-alpha 5
2 passes, 132 bytes.
t:         ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), statically linked, corrupted section header size
/bin/true: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           AMD x86-64
  Version:                           1 (current)
  Entry point address:               0xbffff078
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             
  Size of this header:               64 (bytes)
  Size of program header entries:    56 (bytes)
  Number of program headers entries: 1
  Size of section header entries:    0 (bytes)
  Number of section headers entries: 0 ([0] not available)
  Section header string table index: 0
    

(I'm using /bin/true as a reference, the first bytes matches both files, then they differ (eg true is dynamically linked - "t" not, and I don't think I should make things harder by adding yet a header/section to be 'corrupted' Wink))
Post 14 Feb 2005, 17:43
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Please read the 16-bit value at offset 12h in header for me - it's the number that defines the machine (AMD x86-64 in this case).
Post 14 Feb 2005, 18:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
OK, I've implemented the 64-bit ELF executable output in 1.59.1 version. For those who want to test it, here's the source of 64-bit "hello" program (for Linux platform):
Code:
format ELF64 executable

section readable writeable

msg db 'Hello 64-bit world!',0xA
msg_size = $-msg

section readable executable

entry $

        mov     eax,4
        mov     ebx,1
        mov     rcx,msg
        mov     edx,msg_size
        int     0x80

        mov     eax,1
        xor     ebx,ebx
        int     0x80    
Post 16 Feb 2005, 13:02
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
With help of scientica I have tested that my predictions were true and fasm already generates the correct opcodes in those troublesome cases. So all the problems I've listed above are now solved.
Post 16 Feb 2005, 16:20
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Great! Now FASM have whole new world for expansion. Smile Too bad, I have no access to 64bit PC...

Regards.
Post 16 Feb 2005, 19:25
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
valy



Joined: 01 Aug 2003
Posts: 14
Location: France
valy
Hi Privalov

I coded 2 of your 3 problems above.
The result is into the source code.
This is the current development of my tiny "OS", long mode only, running on my Opteron and Athlon64 too.

(I coded with fasm a few months ago ; now I ported it to yasm because of the x86-64 instructions Confused If you recompile my code, know it is ALPHA and "OsDbg" crushes rcx, rsi, rdi... If you run the code, just press the key Esc to display next screen ; and start from DOS, not from a DOS box)

Regards


Description: AMDO64 by valy
Download
Filename: agner3.asm
Filesize: 44.06 KB
Downloaded: 267 Time(s)


_________________
Easier, faster
Post 01 Mar 2005, 11:37
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Have you tried compiling it with new fasm?
As I said above, the problems are already solved, and I believe fasm can be trusted to generate correctly-working code in all cases.
Post 01 Mar 2005, 14:22
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 Previous  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 GitHub, YouTube, Twitter.

Website powered by rwasa.