Choice of 64-bit assemblers

[jorgon]

I just wanted to remind everybody that since September 2005 GoAsm has been working in 64-bits.  The same version of GoAsm works for 32-bits and 64-bits, you just specify /x64 in the command line.  GoLink also works in 64-bits, automatically sensing the 64-bit object file (which is in "PE+" format) and making the 64-bit executable from one or more object files and a resource file, if used.  GoRC has also been converted to enable it to produce a 64-bit object file if required.  All these tools are free.

The particular features of these tools which may be of interest to programmers who use assembler to make Windows programs are:-

• GoAsm is designed to enable you to use the same source code to create executables for both 32-bit and 64-bit platforms if you want. This has been achieved in the case of API calls by making INVOKE work differently on the two platforms.  In the case of window procedures and other callbacks, you would use FRAME...ENDF which which creates a stack frame (it is similar to PROC).  Again this works differently depending on the platform for which you want to make the exe.  GoAsm permits the use of the RAX,RBP,RBX,RCX,RDX,RDI,RSI, and RSP registers for 32-bit source if you specify /x86 in the command line.  Conditional assembly is needed for the other extended registers and for structures.
• GoAsm helps you as far as possible to port existing 32-bit source code to 64-bits.  This has been achieved partially by the above features, but also by the introduction of ARG.  This acts like PUSH in 32-bit coding, but in 64-bit coding it deals with the parameter correctly.  To use this feature you change your API PUSHes to ARGs and the CALL to INVOKE.  GoAsm includes a new version of Adaptasm.exe, which is capable of identifying which PUSHes are for APIs and only changing those to ARGs (leaving other PUSHes intact).  Adaptasm also carries out some (but not all) of the other changes to 32-bit source which are required to convert it to 64-bit source.
• When INVOKE is used, GoAsm automatically aligns the stack properly ready for the call.  This is a significant feature because it frees the assembler programmer from any concerns about stack alignment.  It means that you can call APIs from anywhere in your code without having to worry whether the call is from a "frame" or a "leaf" function.
• As when assembling for 32-bits, GoAsm takes opportunities to achieve savings in the final coding size. GoAsm's syntax is designed to ensure clear and obvious source, and there are a number of enhancements to make programming for Windows easier.  It has enhanced Unicode support.
• GoLink works without lib files.  You just pass the name of the DLL.  This is a useful feature, saving a lot of hassle, both under 32-bits and 64-bits.

The above, and a more general description of 64-bit programming,  has been written-up in my article "Writing 64-bit programs".
The tools are available from these links:-
GoAsm
GoLink
GoRC
Here is some sample code:-
Hello 64-World 1
Hello 64-World 2
Hello 64-World 3
The "Go" tools main website is here

[hutch--]

Jeremy,

Compliments, you have done some great work here.   :U

Sooner or later I will have to buy a 64 bit box but I am in no hurry as the hardware is changing too fast and there is not enough memory yet to take real advantage of the extra data in 64 bit.

[bushpilot]

I hope to get a 64 bit box by year-end.  I'm looking forward to using it.

Greg

[Ossa]

Well, I've had a 64-bit laptop for about a year and I'm still running 32-bit windows - but I'm planning to reformat and switch to XP 64 Pro in about a week, so I can finally start to see what the world is like with twice as many registers and twice as many bits. I'll definately be taking a look at GoAsm

Ossa

[stanhebben]

I have a 64-bit box and I'll certainly care about 64-bit windows some time.

The great thing about 64-bit is not really the 64-bit registers, but the presence of 16 registers, _and_ 16 xmm registers. A dream!

[EduardoS]

I have a 64bit BOX, a 64 bit windows but don't try 64bit assembly yet...
There are many reason for it, lazyness, few time, etc but the most important is no 64bit package like MASM (it helps a lot).

[MazeGen]

Jeremy, what I miss in GoAsm is x64 exception handling support. Please correct me if I'm wrong.
64-bit MASM seems to have the exception handling fully supported with a couple of new directives.

As for Win64, I don't like it much. First thing is very rigid license - you can buy it only with a new computer, but I already own 64-bit one. I was trying to buy it separately here and also in abroad about a month, but nobody wants to sell it. Finally, I have found one dealer in Slovak Republic disposed for sale.
Next thing is lacking drivers. You can't use 32-bit ones. Even quality and expensive hardware still have no drivers for Win64.

[jorgon]

Jeremy, what I miss in GoAsm is x64 exception handling support. Please correct me if I'm wrong.
64-bit MASM seems to have the exception handling fully supported with a couple of new directives.

You're quite right, GoAsm 64-bit exception handling support is still in the pipeline.

[James Ladd]

Is there anything Jeremy can't do ?    :U

[daydreamer]

I have a 64-bit box and I'll certainly care about 64-bit windows some time.

The great thing about 64-bit is not really the 64-bit registers, but the presence of 16 registers, _and_ 16 xmm registers. A dream!

I have equates for emulate those extra regs in 32bit, so you can write 32bit code and design for future 64bit enviroment with minimum effort recompile code that uses the extra regs

so instead of replacing a memory location with XMM8-XMM15, you already have used those names and no need to rewrite code if you use equates when still only have access to 32bit asm and easy switch to 64bit without lot of work to rework your code
same with other regs

[Mr Wizard]

Thanks for the status report on GoAsm!  I have a copy I DL'd earlier this year but really didn't even try it out because a lot of the free/cheap low-level programming tools (assemblers, linkers, C/C++ compilers, source code libraries, etc.) I find are just not functional or well supported enough to be used for "serious" purposes, namely my hobby/obsession for writing code used for computational number theory.  I figured I'd wait awhile and see if my frustration with the bloated mess known as Visual Studio and the obstacles to writing tight, fast .NET code (oxymoron alert!) would somehow magically disappear.

If I had my druthers, x64 CPUs would provide good support for arbitrary precision arithmetic (APA) in hardware. Part of the instruction set would consist of the sections of the innermost loops one must now code to perform arbitrary precision integer and floating point operations.

That sort of code was just plain ugly when one tried to accurately manipulate the binary representations of decimal numbers thousands of digits long without losing the desired precision for x86 platforms.  With the flat address space of the x64 architecture, the corresponding APA code becomes much simpler, but the development tools available from Microsoft are designed to discourage programming down to the bare metal, with their contrary purpose of generating MSIL code (about as useful to me as Pascal-like pseudocode!).  In fact, most of the difficulties I seem to face when writing x64 code now seem to stem from the fact that I'm targeting Winblows platforms and the stuff I want to do works just fine without a GUI -- MS somehow manages to complexify/obfuscate the process of writing console apps in Visual Studio, IMHO.

I'll make sure I am using the latest and greatest version of GoAsm before I give it a real try over the next few weeks.

[fol67]

Does this assembler support ASM 286?

[TomRiddle]

Yes, it does

[jorgon]

I'll make sure I am using the latest and greatest version of GoAsm before I give it a real try over the next few weeks.

The very latest version of GoAsm 0.56 beta is now available from here.

This version:-

• Corrects various things.
• Allows multi-line macros to be declared using MACRO...ENDM (instead of using the continuation character which was unpopular).
• Introduces #localdef (or LOCALEQU if you prefer), which permits you to have a definition (#define, macro or equate) which is limited in scope to its own stack frame.
• Shows an error if you try to jump into or out of stack frames.
• And of importance for those using GoAsm for 64-bit programming, it now (a) automatically aligns structures on the correct boundary in data at the beginning of the structure (b) automatically aligns each structure member to suit its natural boundary and (c) pads the structure at the end so that it ends on its natural boundary.

Since there was some delving into GoAsm's depths involved in the above changes, I thought it prudent to make this a beta for the moment.