Addressing the AMD64 Architecture and Unicode

[Tapejara]

I see that the Go tools are moving toward 64-bits and Unicode.  How would you compare it with the MASM32 project in this regard?  I am programming to the AMD64 architecture (including SSE) and am building a Phenom II X4 system with Windows 7 to run my target code on.  But my development host will continue to be Win32 on XP for quite some time. 

Thanks

[ecube]

GoASM has supported intel/amd 64bit for awhile now, aswell as unicode. First off it's built in unicode support is incredible, absolutely nothing like MASM, you can switch back and forth really easy, various ways and it has builtin inline support, so you can use the strings directly.

http://www.jorgon.freeserve.co.uk/ scroll down the section that says "Summary of Unicode support in the "Go" tools"
and checkout http://www.jorgon.freeserve.co.uk/GoasmHelp/GoAsm.htm#unicode

it's 64bit support has been a lot of fun too, i typically write hybrid sources where it has a 32bit function and a 64bit, invoke is supported fine. To see some examples check out http://www.masm32.com/board/index.php?topic=11180.0

[donkey]

Hi Tapajara,

I don't do much in the way of 64 bit development except a few little ditties I wrote for my own purposes but the support for it in GoAsm is great. Almost all of my apps for the last while have been Unicode, its just easier to use Unicode as I tend towards COM related applications, the Unicode support is without equal in assemblers. If you plan on writing code that will assemble as 32 or 64 bit you might consider using the data types in the header project as they dynamically resize based on the WIN64 switch, for example the data type HANDLE is 32 bits under Win32 and 64 bits under Win64 with no editing of your source necessary. I don't believe that MASM32 has the flexibility of dynamically switching the width of data types based on target OS. Scoping in GoAsm beats MASM hands down, something that cannot be mimicked in any macro, just the ability to fully isolate a label within a structure is missing from MASM (try to use TVITEM.mask to see what I mean). The lack of dependance on lib files for imports and the extended power of the invoke statement are a huge selling point for me, for example to use an ordinal function you have only to use invoke somedll.dll:2, param.

That said some features can be mimicked through macros in MASM however, when you're talking about support you have to consider that to get a feature added to MASM you can write Microsoft and have it ignored, write a macro that implements it but makes versioning and distribution a nightmare, or just learn to live without it. With GoAsm you have only to post a feature request in this forum and it will be debated and genuinely considered. Most feature requests that have come along over the years I have been using GoAsm have been implemented or in some way resolved. In the end the accessibility of Jeremy, GoAsm's author is the single best feature of the assembler over MASM.

Edgar

[Tapejara]

It is really nice to have direct access to the one's doing the planning and implementation.  Thanks for the helpful info.