Go 64-bits

[jorgon]

I've been pretty silent for a while because I've been working on "Go" 64 - and here it is!
GoAsm, GoLink and GoRC are all now in new versions capable of producing 64-bit programs which can be run on X64 (x86-64) processors (such as the AMD64 or EM64T) running under Windows XP64. 
The same versions of these tools work for both 32-bit or 64-bit assembly.

All the 64-bit capable versions of these tools are currently beta versions and can be downloaded from here:-
GoAsm 32/64-bit assembler (version 0.54.01 beta with documentation 310K)
GoRC 32/64-bit resource compiler (version 0.90.0 beta 59K)
GoLink 32/64-bit linker (version 0.26.2 beta with documentation 57K)

Despite the differences between the 64-bit processors and their 32-bit counterparts, and between the x64 (Win64) operating system and Win32, using GoAsm to write 64-bit
Windows programs is just as easy as it was in Win32. 
In fact, you can readily use the same source code to create executables for both platforms if you use GoAsm's enhanced instructions ARG and INVOKE and FRAME...ENDF, and conditional assembly for data sizes and structures.  Then specify /x64 in the command line to make a 64-bit object file and /x86 to make a 32-bit one.  GoLink automatically senses the type of object file to make the correct executable.
See writing 64-bit programs for details.
You can still use these versions of the tools to make 32-bit executables using your existing source code, and there is no need to change anything.  I have tried to minimise
the switching to maintain speed.

All these tools are still under development and all bug reports would be appreciated.
The tools do not yet offer full support for 64-bit structured exception handling.  This is in progress but I would welcome any ideas for an appropriate syntax to use.  In 64-bit
assembly it will be much easier for the assembler to offer automatic exception handling procedures.  This is because exception handling is now table based (if an exception
occurs, the system looks in a table in the executable to see if the program has its own handler).  GoAsm might offer the ability to have a customised message delivered to the
user, and/or a call or jump to your own exception handler, or "safe place".
GoBug will be revised to enable it to debug 64-bit applications.

[bushpilot]

 :U :U :U :U :U :U

Wow - Thanks Jeremy!

Greg

[jorgon]

I've now updated these files, in particular:-

• There are some small changes to GoAsm to correct a couple of bugs and some small amendments to GoLink
• I've rewritten 64bits.htm which is accessible through the GoAsm help file
• I've added a new version of AdaptAsm to help convert existing 32-bit source code to 64-bit source code (which can also be used as switchable 32/64 bit source code).  This alters registers as appopriate and converts all PUSH/CALL combinations to APIs into ARG/INVOKE combinations instead whilst leaving alone CALLs not to APIs.  This uses a clever javascript file written by Leland M George which can take a Microsoft header file and produce from it a list of APIs and a parameter count for each API.

You can download the new versions using the links above or you can look at the 64-bit section of my website generally here.

[jorgon]

There was an error in GoAsm 0.54.02 beta and I had to withdraw it.  I've now replaced it with 0.54.03 beta.

If anyone downloaded 0.54.02 (only available in the last 24 hours), I'm sorry for the inconvenience.  Please download the latest version.
See the 64-bit part of the Go tools website.

[jorgon]

GoAsm is now at version 0.54.04 available from here.
I'm converting a large project of mine from 32-bit to 64-bit so GoAsm is getting a thorough shaking through.

[jorgon]

With a little more experience using GoAsm and x64 I can now report that:-

1. Although I was already aware that later evaluation versions of Win64 for the AMD64 processor were not sensitive to stack alignment, it has now come as a pleasant surprise to discover that alignment of pointers of structures and strings sent to APIs is not strictly necessary either I have now discovered that 8-byte alignment of pointers of structures and strings sent to many APIs is not strictly necessary.  However, some APIs remain sensitive to this.  Hence it is prudent in all cases to ensure this correct alignment.

2. I now advise that the 64-bit versions of the general purpose registers should be used for pointers even in code which will be used both for 32 and 64 bit assembly.  I explain the reasons for this in "Writing 64-bit programs". For this reason Adaptasm now also converts a general purpose register to its 64-bit counterpart when used with a pointer to an address.

GoAsm 32/64 is now at Version 0.54.06 beta available from here.

[jorgon]

A message to all those coders using GoAsm64:-

There is now a new version of GoAsm for 32/64 bits (now at version 54.09 available from here).

The main things this version corrects are as follows:-

• You may have had trouble using a code or data label in square brackets supplemented by an index register, for example MOV RAX,[MyData+RSI]. The reason for this was related to the type of relocation generated by GoAsm.  MOV RAX,[MyData] uses a RIP-relative address (relocation type 4).  I assumed from the AMD documentation (as did Microsoft in masm64) that MOV RAX,[MyData+RSI] would also use RIP-relative addressing.  In fact it uses absolute addressing.  This may seem odd, but it is related to the bits in the opcodes used to tell the processor to expect a relative address.  These bits are written over by the register information - see "Writing 64-bit programs".  This error in GoAsm has now been fixed.
  
• Initialisation of qword data declarations was sometimes being partially lost.

[bushpilot]

 :U Thanks Jeremy.

Greg

[jorgon]

I have now posted at www.GoDevTool.com a new version of GoAsm (version 0.55.02) for 32 and 64-bit assembly.
For 32-bit assembly there are no changes to the pre-publication version 0.55.

For 64-bit assembly there is an important change.
I found some important APIs which fail on improper stack alignment even with a later x64 build.
The x64 documentation refers to performance issues if the stack is not 16-byte aligned at the time of the call.
Because of the alignment requirement, the documentation says that you can't call an API outside a stack frame.  This is because it is assumed that only within a stack frame will there be correct alignment.  This means that you could not call a procedure, and then let that procedure call an API.

This requirement is very restrictive to assembler programmers, and causes compilers a big headache. My new solution to this problem is to insert special coding before and after each API call (when INVOKE is used) to ensure that the stack is always properly aligned at the time of the call. This liberates the assembler programmer, and means that:-

• Calls to APIs (using INVOKE) can be made anywhere in your code. They can be made from procedures called by other procedures without worrying about the stack pointer.
• PUSHes and POPs can be used in the usual way to save and restore registers, memory addresses and contents of memory without having to worry that this puts the stack out of alignment.
• You can use the same source code both for 32-bit and 64-bit versions of your application (there is no requirement for stack alignment in 32-bits).
  

The overhead for aligning the stack at the time of each API call is an additional nine bytes per API, which seems a small price to pay for the advantages gained. To keep down the size of the code as much as possible, I've taken a number of opportunities to optimise the code particularly when inserting the parameters.
The new version of GoAsm can be downloaded directly from here.