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 |
|
MazeGen 11 Feb 2005, 20:45
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? |
|||
11 Feb 2005, 20:45 |
|
Tomasz Grysztar 11 Feb 2005, 21:05
I don't know enough about the 64-bit Windows yet.
|
|||
11 Feb 2005, 21:05 |
|
MazeGen 11 Feb 2005, 21:28
Yea, we have to learn something new...
Privalov wrote: ...So instructions like: 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!" |
|||
11 Feb 2005, 21:28 |
|
gumletis 11 Feb 2005, 21:47
Im happy with 16-bit and 32-bit windows gui programming
|
|||
11 Feb 2005, 21:47 |
|
Tomasz Grysztar 11 Feb 2005, 22:16
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". |
|||
11 Feb 2005, 22:16 |
|
scientica 11 Feb 2005, 22:58
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? |
|||
11 Feb 2005, 22:58 |
|
Tomasz Grysztar 14 Feb 2005, 11:16
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. |
|||
14 Feb 2005, 11:16 |
|
Tomasz Grysztar 14 Feb 2005, 12:44
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. |
|||
14 Feb 2005, 12:44 |
|
scientica 14 Feb 2005, 15:28
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. |
|||
14 Feb 2005, 15:28 |
|
vid 14 Feb 2005, 15:33
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.
|
|||
14 Feb 2005, 15:33 |
|
Tomasz Grysztar 14 Feb 2005, 15:47
This is the one I've got: http://devresource.hp.com/drc/STK/docs/refs/elf-64-hp.pdf
|
|||
14 Feb 2005, 15:47 |
|
Tomasz Grysztar 14 Feb 2005, 15:51
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. |
|||
14 Feb 2005, 15:51 |
|
scientica 14 Feb 2005, 17:43
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 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' )) |
|||
14 Feb 2005, 17:43 |
|
Tomasz Grysztar 14 Feb 2005, 18:47
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).
|
|||
14 Feb 2005, 18:47 |
|
Tomasz Grysztar 16 Feb 2005, 13:02
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 |
|||
16 Feb 2005, 13:02 |
|
Tomasz Grysztar 16 Feb 2005, 16:20
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.
|
|||
16 Feb 2005, 16:20 |
|
JohnFound 16 Feb 2005, 19:25
Great! Now FASM have whole new world for expansion. Too bad, I have no access to 64bit PC...
Regards. |
|||
16 Feb 2005, 19:25 |
|
valy 01 Mar 2005, 11:37
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 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
_________________ Easier, faster |
|||||||||||
01 Mar 2005, 11:37 |
|
Tomasz Grysztar 01 Mar 2005, 14:22
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. |
|||
01 Mar 2005, 14:22 |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.