The MASM Forum

64 bit assembler => 64 Bit Assembler => Topic started by: shankle on July 31, 2012, 02:03:09 AM

Title: 64-bit Assemblers
Post by: shankle on July 31, 2012, 02:03:09 AM
What Assemblers besides GoAsm can handle 64-bit code?
Thanks for any help.
Title: Re: 64-bit Assemblers
Post by: dedndave on July 31, 2012, 02:08:50 AM
JwAsm
ML64 (microsoft)
Title: Re: 64-bit Assemblers
Post by: shankle on July 31, 2012, 02:21:50 AM
Hi Dave,
I thought JwAsm was in limbo.
GoAsm can't seem to handle the printer functions.
Title: Re: 64-bit Assemblers
Post by: Gunner on July 31, 2012, 07:00:32 AM
NASM and FASM both handle 64bit code.
Title: Re: 64-bit Assemblers
Post by: Gunther on July 31, 2012, 07:10:36 AM
What Assemblers besides GoAsm can handle 64-bit code?
Thanks for any help.

yasm is another alternative. It's nearly nasm compatible, but completely re-written.

Gunther
Title: Re: 64-bit Assemblers
Post by: satpro on July 31, 2012, 12:51:45 PM
GoAsm handles printer functions just fine.
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 13, 2012, 08:31:21 AM
I've coded nasm under dos decades ago. I'm not sure I like it that much. I don't know if I want to use Fasm, anyone have experience using fasm?

If I grab Fasm will I be able to get any help from this forum or do I need to go to fasm's own forums?
Title: Re: 64-bit Assemblers
Post by: sinsi on September 13, 2012, 12:40:15 PM
FASM is pretty good, does 16/32/64 bit (linux too).

>If I grab Fasm will I be able to get any help from this forum or do I need to go to fasm's own forums?
board.flatassembler.net
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 13, 2012, 02:01:58 PM
I downloaded fasm and compiled a hello world program. It went through several passes to lower the size of the executable. It went down to 1.5 kilobytes automatically. Thats cool  :eusa_dance:

Extremely nice and clean include files. No mess at all, even grouped. Btw which of the extra 64 bit registers are to be preserved in windows?

It supports all sse instruction sets to sse 4, including avx and also crc32 and rdrand. The last one is a random generator on the cpu that comes with the newest ivy bridge, I have an ivy bridge cpu here now and it supports this instruction. I have not tried RdRand yet, it's cool that we no longer need software random algorithms (or at least not when people upgrade to ivy bridge or later)
Title: Re: 64-bit Assemblers
Post by: japheth on September 13, 2012, 06:03:32 PM
I downloaded fasm and compiled a hello world program. It went through several passes to lower the size of the executable. It went down to 1.5 kilobytes automatically. Thats cool  :eusa_dance:

Well, Masm (including the 64-bit variant) assembles in ONE pass, so it hasn't to "lower" the size at all. Isn't that ultra-cool?

But I agree, FASM is by far the best assembler of the "NASM family" - because it has a powerful macro language and remembers the type of data items. Hence this snippet
Code: [Select]
m08 db 0
m16 dw 0

add [m08],1
add [m16],2

is no problem for FASM, while NASM and companions are helpless ( NASM's inability to remember the type was once introduced as a feature, and there were - and still are -- a few people who buy this "marketing gag" ).
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 13, 2012, 06:23:00 PM
My first fasm program:

Code: [Select]
format PE GUI 4.0
entry start

include 'win32a.inc'

section '.text' code readable executable

  start:
        invoke MessageBox,0,message,caption,MB_OK or MB_ICONINFORMATION
        invoke  ExitProcess,0

section '.data' data readable writeable

        caption db 'Hi',0
        message db 'This is a salute from Fasm to the Masm32 community...',0

section '.idata' import data readable writeable

        library kernel,'KERNEL32.DLL',\
                user,'USER32.DLL'

        import kernel,\
               ExitProcess,'ExitProcess'

        import user,\
               MessageBox,'MessageBoxA'
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 13, 2012, 06:28:47 PM
japhet, I don't know if this is possible with masm, but you can put resources directly in the source code and it will compile it for you.

Another thing I like is the easy way to export functions from a dll without a definition file. You just put it directly in the source code.
I have no idea if this is possible with masm as well, I normally use definition files.
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 14, 2012, 06:19:38 AM
Fasm seems to come without a general purpose library like the masm32 library. I know about FasmLib, but it is very limited and is 32 bit only, is slow in speed. I Wonder what hutch will say if I convert the masm32 library to fasm and call it Fasm32. Would he become mad?  :dazzled:
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 14, 2012, 12:26:14 PM
My second FASM program. Using a modal dialog created in ResEd.

Code: [Select]
format PE GUI 4.0
entry start

include "win32a.inc"

section '.text' code readable executable

  start:
        invoke GetModuleHandle,0
        mov [hInstance],eax
        invoke DialogBoxParam,eax,1000,0,DlgProc,0
        invoke  ExitProcess,0

proc DlgProc hwnd:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
     cmp [uMsg],WM_CLOSE
     je .close

     ; return false to give internal dialog handler the call to handle message
     xor eax, eax
     ret

.close:
     invoke EndDialog,[hwnd],0
     mov eax, TRUE
     ret

endp

section '.res' resource from '1.res' data readable

section '.data' data readable writeable
        hInstance dd 0

section '.idata' import data readable writeable

        library kernel,'KERNEL32.DLL',\
                user,'USER32.DLL'

        import kernel,\
               ExitProcess,'ExitProcess',\
               GetModuleHandle,'GetModuleHandleA'

        import user,\
               DialogBoxParam,'DialogBoxParamA',\
               EndDialog,'EndDialog'

(http://i.imgur.com/YZiNm.png)  :eusa_snooty:
Title: Re: 64-bit Assemblers
Post by: japheth on September 14, 2012, 05:40:52 PM
japhet, I don't know if this is possible with masm, but you can put resources directly in the source code and it will compile it for you.

Great! However, it's slightly exaggerated to call it "compile", because .RES files are already "compiled" resource files.

Quote
Another thing I like is the easy way to export functions from a dll without a definition file. You just put it directly in the source code. I have no idea if this is possible with masm as well, I normally use definition files.

There's the EXPORT attribute that you can use for PROC. But there are some restrictions...

Perhaps it's better to switch to FASM ... I guess you have opened my eyes ...

However, I'm afraid the discussion has become a bit off-topic now ... it once was about 64-bit assemblers.
Title: Re: 64-bit Assemblers
Post by: sinsi on September 14, 2012, 05:48:13 PM
japheth, you can use the macros to basically create a sort of .rc section, it doesn't have to be a precompiled .res file.
With the sort of things fasm's macro language can do, it's more of a macro assembler than masm is.

And it kills ml64  :biggrin:
Title: Re: 64-bit Assemblers
Post by: japheth on September 14, 2012, 06:03:01 PM
japheth, you can use the macros to basically create a sort of .rc section, it doesn't have to be a precompiled .res file.
With the sort of things fasm's macro language can do, it's more of a macro assembler than masm is.

Ok, but isn't this also possible with Masm? Masm won't create a PE binary, but writing data into a .rsrc section should be no problem.
Title: Re: 64-bit Assemblers
Post by: sinsi on September 14, 2012, 06:15:35 PM
Ok, but isn't this also possible with Masm? Masm won't create a PE binary, but writing data into a .rsrc section should be no problem.
Not sure. Does masm or the linker associate a .rsrc section with the resource entry in the PE header?
Title: Re: 64-bit Assemblers
Post by: farrier on September 14, 2012, 07:17:32 PM
The fasm can take one source file--see attached Windows dialog example from fasm package, with .exe--assembles the asm source creates the resource section and builds the executable with no need for a linker.  Can also create a Version section and Manifest section.  With any of the fasm packages: Windows IDE; Windows command line; DOS with extender; Linux and variants; you can create .exe, .dll, .obj, .bin, .so? .bin for Windows, DOS, Linux & with the version--fasmarm--maintained by revolution, for ARM chips.

The only time I've needed a linker was to combine my fasm .obj file with a MASM .obj file.

I started with MASM but use the fasm exclusively now.  Just starting in the 64 bit world now.

hth,

farrier
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 14, 2012, 10:46:50 PM
In fasm you normally write your libraries in plain source files and then include them. Or use dll's. You can build object files too but you need an external linker. When building your source library you can use conditional assembly like this:

Code: [Select]
if used myvar1
   myvar1 db 100000 dup 0
end if

If you don't refer to the data, it will not be included in the final executable.


 
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 15, 2012, 11:31:44 AM
The times directive is cool, here is an example how to create a rot13 lookup table, 256 items in the array using the times directive in fasm:

Code: [Select]
        times 65 db %-1
        times 26 db (((%-1)+13) MOD 26) + 65
        times 6 db %+90
        times 26 db (((%-1)+13) MOD 26) + 97
        times 133 db %+122

and here is the equivalent in masm. I may have been doing things too complex in masm, but this is what i've got:

Code: [Select]
Rot13Buf4                 DB 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
DB 27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50
DB 51,52,53,54,55,56,57,58,59,60,61,62,63,64
DB "NOPQRSTUVWXYZABCDEFGHIJKLM"
DB 91,92,93,94,95,96
DB "nopqrstuvwxyzabcdefghijklm"
DB 123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142
DB 143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162
DB 163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182
DB 183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202
DB 203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222
DB 223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242
DB 243,244,245,246,247,248,249,250,251,252,253,254,255

Both of these do the exact same thing.  :eusa_snooty:
Title: Re: 64-bit Assemblers
Post by: MichaelW on September 15, 2012, 03:23:01 PM
Using MASM I can’t see any way to define the table as compactly as FASM can, but I can see a simpler way to define it.
Code: [Select]
;===================================================================================
include \masm32\include\masm32rt.inc
;===================================================================================
.data

Rot13Buf4 LABEL BYTE
DB 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
DB 27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50
DB 51,52,53,54,55,56,57,58,59,60,61,62,63,64
DB "NOPQRSTUVWXYZABCDEFGHIJKLM"
DB 91,92,93,94,95,96
DB "nopqrstuvwxyzabcdefghijklm"
DB 123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142
DB 143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162
DB 163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182
DB 183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202
DB 203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222
DB 223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242
DB 243,244,245,246,247,248,249,250,251,252,253,254,255

ROT13BUF LABEL BYTE
N=0
REPEAT 65
    DB N
    N=N+1
ENDM
DB "NOPQRSTUVWXYZABCDEFGHIJKLM",91,92,93,94,95,96,"nopqrstuvwxyzabcdefghijklm"
N=123
REPEAT 133
    DB N
    N=N+1
ENDM

.code
;===================================================================================
start:
;===================================================================================

    mov esi, OFFSET Rot13Buf4
    mov edi, OFFSET ROT13BUF
    xor ebx, ebx
    REPEAT 256
        movzx edx, BYTE PTR [esi+ebx]
        printf("%d\t%d\t",ebx,edx)
        movzx edx, BYTE PTR [edi+ebx]
        printf("%d\n",edx)
        inc ebx
    ENDM

    inkey
    exit
;===================================================================================
end start

Title: Re: 64-bit Assemblers
Post by: CodeDog on September 15, 2012, 04:27:40 PM
I had a suspicion it could be simplified a bit.

The file directive is also cool if you need to load data directly into the executable from a file

Code: [Select]
Buf    file '1.asm':100,200
       file '1.asm':350,800
This loads 200 bytes from offset 100 and 800 bytes from offset 350 in 1.asm directly into the executable. Nice for creating standalone patchers.  :eusa_boohoo:
Title: Re: 64-bit Assemblers
Post by: jj2007 on September 15, 2012, 04:33:02 PM
DB 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
DB 27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50
DB 51,52,53,54,55,56,57,58,59,60,61,62,63,64


To do that in Masm, either use the REPEAT directive with CATSTR etc, or (saving executable size) use a combo of lodsb/xchg eax, ecx/lodsb/stosb instructions.
Title: Re: 64-bit Assemblers
Post by: japheth on September 15, 2012, 04:48:11 PM
The times directive is cool

The times directive is just a short form of the repeat directive. It may spare you some key presses, that's all.

The automatic loop counter is elegant, but IMO this concept isn't really assembly-like. The counter incrementation happens "under the hood", which I don't like that much.

Masm already has a preprocessor directive with a "loop variable", it's the FOR directive. It could be very easily extended to format:

Code: [Select]
     for i=0, i < 10, i = i+1
     endm

which is superior to FASM's ability, because a) everything is transparent and b) if the loops are nested, you have full access to all loop variables "on higher levels".

   
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 16, 2012, 02:12:15 AM
Fasm is influenced by pascal syntax maybe that is why. The reason I like fasm is because that guy who wrote it share the same background as myself. He came from Turbo Assembler and Turbo Pascal, and I understand his design philosophies because I had the same view as him. A simplistic approach. I understand him perfectly well that is why I kind of like Fasm so far. But Masm has its place for sure. Even IF I will move to using Fasm, I would not want Masm to disappear.

When I read the fasm docs, I just understand it immediately. Normally if you are trying to learn something new, you go like "Damnit, I just have to take this one step at the time". But with the fasm docs, I'm already adapted to it and understand it, because I agree with it as I read it.

A good designer doesn't try to communicate a complex protocol to random people, a good designer will appeal to his audience and they already understand his protocol.

Abraham Lincoln - 2012
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 19, 2012, 10:10:33 PM
japhet, this does more or less the same as your for loop. And you do have access to the loop variable on "higher level". I just weren't aware of it when you wrote it. You can define as many variables you want in your code, put it anywhere you like and access them, redefine them in the loop, do whatever you want with them.

Code: [Select]
i=0
while i<10
    i=i+1
end while

Here is an example of nested loop:

Code: [Select]
y=0
while y<480
  repeat 640
    stdcall PlotPixel,%-1,y,0FFh
  end repeat
  y=y+1
end while

example using two repeats:

Code: [Select]
y=0
x=0
repeat 480
  repeat 640
    stdcall PlotPixel,x,y,0FFh
    x=x+1
  end repeat
  x=0
  y=y+1
end repeat

I used variables in both repeat just for demonstration purposes. x and y can not only be accessed inside the repeats but also anywhere else in your program. You can define x and y anywhere in your program, then redefine them and put different values into them later. You can even restore it to a previous value, like this:

Code: [Select]
x = 10
mov eax, x
x = 20
mov ecx, x
restore x  <- this restores x back to 10 again

Break when half screen is plotted:

Code: [Select]
y=0
x=0
repeat 480
  repeat 640
    stdcall PlotPixel,x,y,0FFh
    x=x+1
  end repeat
  x=0
  y=y+1
  if y>(480/2)-1
    break
  end if
end repeat

If you want to you can also create your own conditional directives like IF THEN or even a FOR loop. It can be done very easily if you absolutely want the for loop you can design it in a macro.  :P
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 20, 2012, 02:07:39 AM
Another thing I like is the virtual directive. It can be used for many things but one of the things I can think of is producing buffers of opcodes in a buffer that you can put into another process later if you need to

 
Code: [Select]
       virtual at 0
            nop
            nop
            nop
            n2=$
            repeat n2
                   load k% from %-1
            end repeat
        end virtual

        Buf rb 0
        times n2 db k%
        BufSize dd n2
Title: Re: 64-bit Assemblers
Post by: japheth on September 20, 2012, 02:30:35 AM
japhet, this does more or less the same as your for loop. And you do have access to the loop variable on "higher level". I just weren't aware of [snip]

You misunderstood my posting ( or didn't read carefully ); I was talking about the automatically generated loop variable which is named %.
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 20, 2012, 03:14:26 AM
japhet, this does more or less the same as your for loop. And you do have access to the loop variable on "higher level". I just weren't aware of [snip]

You misunderstood my posting ( or didn't read carefully ); I was talking about the automatically generated loop variable which is named %.

That automatically generated variable is just a bonus to the flexible constant system fasm offer. There is no rule that says you should use % primarily.  ;)
Constants in fasm offer unlimited flexibility, beyond that of masm. The only thing that piss me off with fasm is that the compiler does not allow floating point calculation during compile-time.  :( If it only supports fpu calculations during compile-time I could create very flexible graphics macros.

Btw, check my previous post, virtual is useful for generating opcodes and later copying it to other parts of your code or into another process. What do you think of it?  :P The virtual directive creates a list of virtually constructed instructions (magical instructions that wont be part of the output) and then load it into constants, then finally put the opcodes into a real buffer defined in the data section. Later you can copy the opcodes to another process.

You can do the same thing in masm too, but normally you would do it by copying opcodes directly from the code section, but in fasm you copy virtual instructions that don't exist in the code section.
Title: Re: 64-bit Assemblers
Post by: japheth on September 20, 2012, 05:33:47 AM
Quote
That automatically generated variable is just a bonus to the flexible constant system fasm offer. There is no rule that says you should use % primarily.  ;)

Nou schitt.

Quote
Constants in fasm offer unlimited flexibility...

This is a marketing speech bubble. FASM has deserved better.  :icon13:

Quote
What do you think ...?

Well, you asked so don't complain!  :P : You've gathered a good deal of half-knowledge about FASM already. Continue with your efforts and eventually you' ll be able to code a working program in that language! And then, try again to  teach FASM here! Currently you can't play this role persuasively.
 
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 20, 2012, 05:40:24 AM
Well, you used the word "superior", it was not a light word to use considering that you were absolutely wrong. It is like a guy with a russian lada claiming to be able to drive faster than a ferrari enzo. You have to admit that it was my right to make the obvious, OBVIOUS. Whatever reason you chose to believe that % was the main and only thing you could use remains to be known.  ;)

the i variable in your for loop is just like my x,y variables. Perhaps you need to reconsider your own perception of reality  :lol: why do you want to compare a fish with a bicycle. % is in this case a bicycle (just a tool) and the fact that % is constant is not a weakness, it makes your code strong and reliable because you have a source of input that stays constant which can't be changed by accident and in addition you have constants that you CAN change. I would say that is flexibility combined with safety. Oh now I sound like marketing man again, it is not on purpose honestly.  :bgrin:

And "superior" do sound a little bit more like marketing skills than "flexible" does  :redface:
Title: Re: 64-bit Assemblers
Post by: japheth on September 22, 2012, 07:02:21 PM
Not sure. Does masm or the linker associate a .rsrc section with the resource entry in the PE header?

I tried. Masm has no problems, but the MS linker crashes as soon as it finds a .rsrc section in the COFF object module.
Title: Re: 64-bit Assemblers
Post by: Vortex on September 22, 2012, 07:06:45 PM
Not sure. Does masm or the linker associate a .rsrc section with the resource entry in the PE header?

I tried. Masm has no problems, but the MS linker crashes as soon as it finds a .rsrc section in the COFF object module.

Hi japheth,

What's the result with Polink?
Title: Re: 64-bit Assemblers
Post by: japheth on September 22, 2012, 08:19:54 PM
What's the result with Polink?

Hi Vortex,

polink works pretty good - but it's no cigar. The link step finishes without error, and polink did even set the resource directory values in the PE header automatically. However, it has problems with section-relative fixups ( created by Masm operator SECTIONREL ) if there's an addend. Here's an excerpt:

Code: [Select]
;--- root level: enum the resource types
      IMAGE_RESOURCE_DIRECTORY <0,0,0,0,0,2>
      IMAGE_RESOURCE_DIRECTORY_ENTRY < RT_BITMAP, SECTIONREL bms   + 80000000h >
      IMAGE_RESOURCE_DIRECTORY_ENTRY < RT_MENU,   SECTIONREL menus + 80000000h >

;--- second level: enum the IDs of resource type X
bms   IMAGE_RESOURCE_DIRECTORY <0,0,0,0,0,1>
      IMAGE_RESOURCE_DIRECTORY_ENTRY < IDR_BITMAP1, SECTIONREL bm1   + 80000000h >
menus IMAGE_RESOURCE_DIRECTORY <0,0,0,0,0,1>
      IMAGE_RESOURCE_DIRECTORY_ENTRY < IDR_MENU1,   SECTIONREL menu1 + 80000000h >

polink ignores the "+ 80000000h" addend and hence bit 31 isn't set in the field. However, if I set the bit manually with a hex editor after polink is done, the binary works just as expected.

Now, as far as the sample is concerned, one can probably make it work without using SECTIONREL at all, but as soon as more than one object module with a .rsrc section is involved, you'll get into problems.

I attached source and binary of my test case.
Title: Re: 64-bit Assemblers
Post by: Vortex on September 23, 2012, 04:35:31 AM
Hi japheth,

Thanks for the info and example. I was able to build the project with JWasm and Polink.
Title: Re: 64-bit Assemblers
Post by: japheth on September 23, 2012, 07:00:50 PM
Thanks for the info and example. I was able to build the project with JWasm and Polink.

Yes it works with the current polink version 7. In my attempts yesterday I used an outdated version of this tool.
Title: Re: 64-bit Assemblers
Post by: CodeDog on September 25, 2012, 07:59:06 AM
This is not exclusive to fasm but its useful

Code: [Select]
.label:
    irps reg, eax ecx ebx esi edi
    { xor reg,reg }

BYTECOUNT = $-.label

IF BYTECOUNT<128
  DISPLAY 'More unrolling needed...',13,10
ELSE
  DISPLAY 'No more unrolling needed',13,10
END IF

(http://i.imgur.com/R0U6v.png)

You could also extend it to show only when DEBUG is defined, like this:

Code: [Select]
.label:
    irps reg, eax ecx ebx esi edi
    { xor reg,reg }

IF DEFINED DEBUG
  BYTECOUNT = $-.label

  IF BYTECOUNT<128
    DISPLAY 'More unrolling needed...',13,10
  ELSE
    DISPLAY 'No more unrolling needed',13,10
  END IF
END IF

 :P