Index
> Windows > win64 64 bit source samples, executablesGoto page 1, 2, 3, 4, 5, 6, 7 Next |
| Author |
|
|
Feryno 06 May 2005, 06:12
Few amd64 asm64 sources, executables, stupid m$ assembler, include *.lib files: kernel32.lib, user32.lib
Maybe useful for FASM developers by developing win64 PE format for FASM, you can compile exe. This is not FASM, but stupid m$ assembler. download here: http://feryno.host.sk asm_amd64_win64.zip 860574 bytes because include everything for compile |
|||
06 May 2005, 06:12 |
|
|
Feryno 11 May 2005, 04:43
Method for debugging win64 asm exe:
download debugger: http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.4.7.2.exe http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx Place db 0CCh (int 03) at begin of code under WinDbg.exe go to File -> Open Executable (CTRL+E) Debug -> Go (F5) now you are at int 03 and you can use F10 F11 for step use View -> Command, Registers, Memory to see everything Don't run exe with int 03 outside debugger - cause application error. You must remove int 03 after developing and releasing exe to use.
|
|||||||||||
|
11 May 2005, 04:43 |
|
|
revolution 11 May 2005, 05:21
Quote:
From my reading of the docs I thought that all 32 bit writes to the registers will also clear the top 32 bits. (one exception being xchg eax,eax) |
|||
|
11 May 2005, 05:21 |
|
|
Madis731 11 May 2005, 09:17
Oh my God - what code should be introduced to make it retain the previous values. Why would anyone do such a horrible thing.
mov al,5 mov ah,50 mov ax,500 never touched other parts of the registers!  I think I don't like 64bit anymore. |
|||
|
11 May 2005, 09:17 |
|
|
MCD 11 May 2005, 09:31
Madis731 wrote:
The same is true for me since a long time. sad but true. |
|||
|
11 May 2005, 09:31 |
|
|
Tomasz Grysztar 11 May 2005, 10:18
Anyway "lea edi" is still wrong, since you should not assume that your data is placed in the low 4 GB of memory.
|
|||
|
11 May 2005, 10:18 |
|
|
Tomasz Grysztar 13 May 2005, 15:14
fasm 1.61.3 now supports the COFF format for x86-64. Here's the sample source:
Code: format MS64 COFF extrn MessageBoxA extrn ExitProcess section '.text' code readable executable public main main: mov r9d,0 lea r8,[_caption] lea rdx,[_message] mov rcx,0 call MessageBoxA mov ecx,eax call ExitProcess section '.data' data readable writeable _caption db 'Win64 assembly',0 _message db 'Coffee time!',0 Can someone test it for me? |
|||
|
13 May 2005, 15:14 |
|
|
Madis731 13 May 2005, 16:59
Not that I would program 64 just yet, but I think that r09d, r08 would look nicer i.e.:
Code: mov r13,rcx add rdi,r09 sub r01d,r04d ;<=- I can't find solution to this Did I see rWx somewhere like you can use up to 16th letter instead of the W? Then the name would remain the same length even with d, w, b postfixes: eax,ebx,ecx,edx,eex,efx,egx,...,epx al,ch,gx,pl,ph,... of course now there are lot of fun names reserved and this leaves less room for meaningless names like these above... ...oh well I think the AMD/Intel guys where smart enough to think them over already |
|||
|
13 May 2005, 16:59 |
|
|
Feryno 18 May 2005, 06:28
Thanx, Privalov, this is GREAT. I can forget to stupid m$ assmebler, yeah !
There is another bug in my a01.asm example. Passing 5th arg to syscall, but a01.exe still work... See new sources, contain correct method for pass more than 4 args to syscall. Contain skeleton for make window exe, not only console apps. There is difference in WNDProc between win64 and old win 32 - parameters retrieve not on stack, but on registers... See a03.asm Debugging... see included stuff in asm_amd64_win64_debug_2.zip
|
|||||||||||
|
18 May 2005, 06:28 |
|
|
revolution 18 May 2005, 07:10
Madis731:
Make your own register names if you want to. Code:
r08 equ r8
r09 equ r9
r01d equ eax
r08d equ r8d
r09d equ r9d
eex equ esi
etc..
EDIT: fix changed to equ Last edited by revolution on 19 May 2005, 08:58; edited 1 time in total |
|||
|
18 May 2005, 07:10 |
|
|
Tomasz Grysztar 18 May 2005, 09:23
Feryno: read this (and also this) for more details about Win64 calling convention.
The idea is that you allocate the stack space once and then reuse it for many calls (and when the argument is, for example, of byte size, you need to store only one byte in appropriate place). Here's my version of your a02 example, with detailed comments: Code: format MS64 COFF extrn CreateFileA extrn WriteFile extrn CloseHandle extrn ExitProcess section '.data' data readable writeable phy1ename db 'Rambo.txt', 0 stryng db 'Rambo - First Blood, Part II :', 0Dh,0Ah db 'For our country love us, as much as we love it!' stryng_syze = $ - stryng BytezWrytten dq ? section '.text' code readable executable public main main: sub rsp,7*8 ; reserve stack space for up to 7 arguments ; (you may expand this allocation if you need ; to call procedures that take more than 7 arguments) ; and restore the stack frame only at the end of your routine. mov qword [rsp+6*8],0 ; store 7th argument mov dword [rsp+5*8],80h ; store 6th argument mov dword [rsp+4*8],2 ; store 5th argument xor r9,r9 ; the first four argument are passed in registers, xor r8d,r8d ; but stack space is still reserved for them, mov edx,40000000h ; the called routine may want to spill them there lea rcx,[phy1ename] call CreateFileA xchg rbx,rax ; store result in the register that is preserved by calls mov qword [rsp+4*8],0 ; store 5th argument lea r9,[BytezWrytten] mov r8d,stryng_syze lea rdx,[stryng] mov rcx,rbx call WriteFile mov rcx,rbx ; not that this call does not need any arguments on stack, call CloseHandle ; but the stack space should be reserved for the arguments passed ; in registers to be fully compliant with calling convention xor rcx,rcx ; restoring stack frame is not needed at all in this case, if call ExitProcess ; this was the end of procedure, you would have to do it before returning. BTW: are you able to test the fasm-generated files on x86-64 machine for me? I don't have access to any Win64 machine, nor the AMD64 processor. revolution: even EQU would be enough for such purpose. |
|||
|
18 May 2005, 09:23 |
|
|
Feryno 18 May 2005, 11:00
Thanx, Privalov, right, better way allocate stack once and use'm.
Today i go home to my beloved AMD64 comp - after finishing my work here in job - and try to test FASM64, your sample source above. You finded very good AMD64 stuff. I have about 1 hour dissasembling and debugging why find method how to pass 5th arg to syscall, and about a half of day to find how to make windows skeleton and WNDProc (a03.asm)... playing with 64 bit notepad.exe using WinDbg and IDA... Faster way is find good stuff on inet. But i like disassemblers and debuggers so much! Good luck in FASM64 ! Feryno, Slovak Republic (you know now why so bad english i use) |
|||
|
18 May 2005, 11:00 |
|
|
Feryno 19 May 2005, 04:53
FASM generate perfect *.obj ms64 coff object file. You need linker to generate exe.
Here some working samples as well on my homepage http://feryno.host.sk (big 0,75 MB file, include new linker and *.lib files from april 2005 DDK release) Great work, Privalov, thanx ! edit from 2007-01-31: deleted attachment, lack of space to put newer things (5 MB quota) Last edited by Feryno on 31 Jan 2007, 09:19; edited 2 times in total |
|||
|
19 May 2005, 04:53 |
|
|
Tomasz Grysztar 19 May 2005, 09:34
Small note about your problem with PUSH 80000000h - fasm being very strict in terms of realizing the instruction you specify, doesn't allow it, since in long mode PUSH instruction opcode contains the signed 32-bit immediate operand, which is sign-extended to 64 bits that are then stored on stack. So 80000000h immediate gets extended to 0FFFFFFFF80000000h and this is the true value that gets pushed. So fasm will accept if you write PUSH 0FFFFFFFF80000000h or PUSH -80000000h (they're both the same 64-bit value, and fasm's expression calculator works on 64 bits internally), but it forbids PUSH 80000000h, because there is no way to push 64-bit immediate 80000000h on the stack. The REX prefix you tried has no effect in this case - the immediate in PUSH opcode is always signed 32 bits (and that's why fasm won't also accept PUSH QWORD 80000000h instruction - it's just impossible to encode it).
This is another reason why it's better to allocate stack first, and then fill it with appropriate values with MOV instructions - when you need to store only double word somewhere in stack, you use just 32-bit MOV, etc. And some more things specific to fasm, which I thought would be good to note after reading your RIP.ASM sample (not yet converted to fasm): first, fasm allows RIP-relative addressing written like INC BYTE [RIP+1], second, the direct addressing in long mode is automatically converted to RIP-based (since only this can work with full 64-bit addresses), but that doesn't mean the absolute direct addressing isn't possible at all. DEC BYTE [0] won't work, but DEC BYTE [DWORD 0] will, and will use direct absolute 32-bit addressing. The x86-64 support in fasm was very carefully designed after a months of "meditating" over the AMD64 manuals - I did my best to make fasm always generate the correct opcodes for you, while allowing as much freedom as possible. PS. Direct PE+ executable output for Win64 coming soon.  |
|||
|
19 May 2005, 09:34 |
|
|
Feryno 19 May 2005, 10:59
I'm too fascinated by small asm code and that's why i use push. E.g. push 0 use 2 bytes, mov qword [rip+...],0 use to much bytes of opcodes for me style of coding.
But i see, my method of producing smallest code is too problematic, so i must convert to method that produce bigger code. Bigger and safer. I think, i't too hard to develope without possibility of testing if it work. Is a developer here that need help with this "Sysiphos work"? I'm not able to send hardware, but i'm with other... to "lend" that i self have "cost free". |
|||
|
19 May 2005, 10:59 |
|
|
Tomasz Grysztar 19 May 2005, 11:04
Quote: I think, i't too hard to develope without possibility of testing if it work. I think that with my latest fasm releases I have proven that this is not really such a big problem. Someone (like you) that tests it remotely for me is just enough. |
|||
|
19 May 2005, 11:04 |
|
|
Feryno 20 May 2005, 05:07
Privalov wrote:
Quote: Someone (like you) that tests it remotely for me is just enough. Every time i'm able to testing asm code on Win64 as well Linux 64 bit. You develop only from documentation, without testing... I see, you are realy good coder. I'm poor self-educater and i must test everything too much times before make code working. But 8 years of hobby asm coding make my code better and better. |
|||
|
20 May 2005, 05:07 |
|
|
Feryno 03 Jun 2005, 05:13
I tried to add resource section - with success, required some filez from m$ $DK.
I got a trubble why API destroy 4 quadwords on stack. I know that win64 api can use first 4 quadwords of stack to save regs, but i have see this first time. E.g. DefWindowProcA don't destroy'em, FindResourceA destroy, hence i must preserve this. How crazy can be region window - see *.jpg file if you haven't win64 to run exe. For people with slow connection - sorry for it size 150kB. Sample include everything for compile, because > 800 kB must be split to 2 parts. 1st contrain relevant part, 2nd m$ DLL's required for compile. Sample is skeleton only, contain nothing for run. To close you need press ALT+F4 because ws_popup window style. See ya in win64 asm! edit from 2007-01-31: deleted attachment, lack of space to put newer things (5 MB quota) Last edited by Feryno on 31 Jan 2007, 09:20; edited 2 times in total |
|||
|
03 Jun 2005, 05:13 |
|
|
jorgon 30 Jun 2005, 21:50
Congratulations TG for taking the lead with FASM for 64-bit assembly using the x86-64 processors, and thank you Feryno for the excellent samples. I started my move in this direction with GoLink.
Since for the time being FASM 64 is limited to producing object files, GoLink may be a useful tool in the interim. It takes one or more 64-bit object files and a res file (if used) and makes a 64-bit executable which can be run on x86-64 processors. No lib files are needed since GoLink looks inside the DLLs themselves to see which APIs they export. Even when FASM is able to produce 64-bit executables GoLink may remain useful to combine more than one object file, permitting source code to be divided into modules. Whilst working with FASM produced object files, I came across an incompatibility between these files and GoLink even under Win32, of which I was not aware. I have now fixed this so that GoLink can be used as a linker for FASM Win32 object files. This works if "format MS COFF" is specified in the source text. GoLink is at Version 0.26.0 beta and can be downloaded from here. This link will also work for updates until the version is officially published. Its early days yet so all bug reports would be appreciated. _________________ Author of "Go" tools |
|||
|
30 Jun 2005, 21:50 |
|
| Goto page 1, 2, 3, 4, 5, 6, 7 Next < Last Thread | Next Thread > |
Forum Rules:
|