While progress is being made on a GoLink update (done, see version 1.0), I have started more planning for GoAsm. For x64 exception handling, FRAME should be providing pdata RUNTIME_FUNCTION info and xdata UNWIND_INFO on the function's prolog stack usage (work in progress). Version 0.58 started with some FRAME and USEDATA adjustments required for this, and a few more are on the way for your info:
x86/x64 LOCALFREE (done, see version 0.59)
Since this stack re-allocation will usually alter that which was recorded in the prolog UNWIND_INFO, LOCALFREE would be changed to not be allowed for x86 and x64 modes (only allowed for regular 32-bit code).
x64 ARGD ARGQ INVOKE (done, see version 0.62)
Since GoAsm does not do type checking, ARGD and ARGQ need to be used with INVOKE in order to identify whether an argument is a 32-bit single-precision (ARGD) or a 64-bit double-precision (ARGQ) floating-point value. These variations of ARG will use the appropriate XMM0-3 register. A similar extension for arguments passed on the same line after INVOKE has also been included with the format D or Q followed by a space character and then the argument.
ARGD xmm0
ARGD [FP_DD]
ARGD eax
ARGD 4.32 ;uses r11
INVOKE Procedure
INVOKE Procedure, D 4.32, D eax, D [FP_DD], D xmm0
ARGQ xmm0
ARGQ [FP_DQ]
ARGQ rax
ARGQ 8.65 ;uses r11
INVOKE Procedure
INVOKE Procedure, Q 8.65, Q rax, Q [FP_DQ], Q xmm0
x64 SHADOW (done, see version 0.62)
Saving regular registers to the shadow space is done automatically with FRAME. Since GoAsm does not do type checking, SHADOW needs to be used with FRAME in order to identify a floating-point parameter passed in an XMM0-3 register. This can also be used to omit saving one or more of these registers, typically in a smaller procedure that will use the register directly, before a possible function call that would overwrite them (use of parameter name will then not have the proper value since it does not get saved to the Shadow space).
SHADOW xmm0, xmm1, r8, r9 ;a mixed register example
SHADOW ;no registers specified, no registers saved
x64 USES (done, see version 0.62)
The xmm registers should be allowed with USES within FRAME...ENDF. However, since the xmm registers would be dealt with differently by allocating stack space (properly aligned for x64) and using movaps (movups for x86), it is clearer (when comparing to the list file output) to use a separate USES line placed after the regular register USES line (if used). Note that because of the stack allocation adjusting LOCAL, if USES has an xmm register listed, the USES line(s) will need to be placed before any LOCAL line(s).
A function based on the less common USES...ENDU remains available for 32-bit, but for /x86 and /x64 this will now need to be changed (since it is not a leaf function) to a USES statement within FRAME...ENDF for upcoming exception handling.
x86/x64 USEDATA
Currently there is a default SHIELDSIZE (100h bytes for 32-bit, 200h bytes for 64-bit, also with a minimum of 20h) which allows for possible stack usage in the FRAME beyond that which was done in the prolog since GoAsm does not track this. There is a several step adjustment to RSP which is a fixed amount relative to RBP, but the amount relative to RSP is not known by GoAsm at assembly-time, and this is required for assembly-time UNWIND_INFO.
The change here would be to alter default the SHIELDSIZE to 4h bytes for x86 and 8h bytes for x64 (unchanged for regular 32-bit code). These would also be the new minimum values which take into account just the return value on the stack for the call in INVOKE. The USEDATA prolog would be simplified, and the epilog change would have RSP restored using the LEA valid format for SEH. Note that this may require adjusting current x86/x64 code by specifying a different SHIELDSIZE value for the amount of stack space actually used (ex. for manually supplying arguments to a USEDATA procedure, along with the return value for the call). See also the following...
x64 INVOKE
The current x64 approach is somewhat similar to 32-bit code which pushes function arguments on the stack, except for the first 4 which are passed through registers (a stack allocation for these 4 are still always made for each INVOKE, and removed after the call). Due to stricter x64 stack 16-byte alignment for a call, there is also extra code added with each x64 INVOKE.
This is where the above USEDATA change can get a bit tricky. Depending upon the USES and LOCAL lists, there may be an extra 8-bytes for stack alignment, and if so they need to be included in the SHIELDSIZE.
Because of this USEDATA related issue and also for better optimised and easier to follow code for x64 INVOKE, there is another approach. This involves creating enough stack space in advance for the arguments (properly 16-byte aligned) and reuse these for each INVOKE using mov for the non-register arguments (for ARG [Label] this 'memory to memory' mov would most likely go through the R11 register). However, in order to use this, you would need to ensure that when you use x64 INVOKE the stack has not changed from where it was after the prolog, which still may require adjusting current x86/x64 code.
x64 FRAME / USEDATA / LOCAL
The above would only be available on a per x64 FRAME (or USEDATA) basis by specifying the maximum number of ARGs (or more if you want to waste stack space, or not be bothered with error messages) that will be used by INVOKE within the FRAME (or USEDATA). GoAsm is a single pass assembler and does not look that far in advance, but would give an error message with the ARG count if INVOKE exceeds the maximum.
The syntax to achieve this would be added to LOCAL with the keyword ARGS and a required [N], placed at the end of the LOCAL list, where N is the maximum number of arguments allowed for any INVOKE within the FRAME or USEDATA procedure (the minimum N would be 4 for the required shadow space). For example:
LOCAL Loc1, Loc2, ARGS[4] ;placed at end on same line
;also
LOCAL Loc1, Loc2
LOCAL ARGS[8] ;placed at end on a separate line
The use of ARGS would not alter x86 mode stack allocation or INVOKE.
That is it for now...
Shifting main focus back to GoAsm...
Other progress didn't make it into version 0.59. Back to regularly scheduled programming...
Hi Wayne,
I was wondering if there is a chance we may see improved (enhanced) source listings for GoAsm. As it is now, listings are cropped at 80-columns, which is quite limiting, especially if comments are taken into consideration. More times than not, a source listing is all one needs for de-bugging, and I frequently use listings in place of GoBug for the simpler things (and also really like to see the translation into binary). Also, as it is now, listings at the assembler stage are only partially helpful for viewing the binary, so would a linker stage listing be better in this respect?
GoAsm is really a great assembler and I work with it literally every day, but am wondering about this one topic and if there is anything planned for the future and what would be involved in tackling it. If not, is there a workaround I might implement on my own?
Thank you.
The listing file will have plenty of [00000000] since the address relocations are done at a later stage with linking. Having those values filled in would be more accurate along with instruction and label addresses showing, but having the linker do this would most likely involve GoAsm passing line number information (COFF line number info has been deprecated). No easy work around to implement on your own that I can think of.
The intent may have been to limit for printer friendlier output, but more characters can be fit in per line going with a smaller font and landscape orientation.
The current typical listing line format is 26 characters for opcodes plus 74 characters from the source file (that is 100 characters; perhaps your text editor is cropping this further to 80 characters for printing).
I made some small changes already to the listing file in an earlier version for display of code that GoAsm inserts, and have considered an adjustment which would extend the opcode section to at least 32 characters (also displaying a bit more in the data section, ex. strings). I took a quick look, and it should be very easy to extend the portion copied from the source file. Going with around 98 characters (an extra 24) seems reasonable to fit a total of 130 characters at font size 9 with landscape orientation and narrower margins.
As for the opcode adjustment, instead of left justified, I was considering some spacing and lining up so that it would be easier to identify portions of the instruction encoding (various Prefixes, Opcode(s), ModRM, SIB, Displacement, and Immediate values).
Thanks for the response. Actually, I did later notice it was cropped at 100 columns, not 80, and my confusion was from using two different vertical edge settings (one in the editor for writing source, and the other in Notepad2 for opening up .asm files quickly :icon_redface: ). My source, including comments, does extend to 130 columns. One can live with using printouts from source text in landscape mode and de-bugging with the .lst file.
Anything you feel might help with GoAsm listings will certainly be appreciated here.
Thanks again,
Bert
The next update will have some changes to the list file and also include support for SSE3 and SSSE3 instructions. Relatively soon, depending on how far I can go with the list file changes...
Great news wjr.
keep it up, GoASM is getting better and better!
wjr,
Maybe you can explain the following.
I am building a x64 bit dialogbox.
What I am wondering is the following on other x64 bit processes all system dll's are loaded into the 7ffc'........ range being 64 bit addresses.
on my x64 bit program only ntdll is inside 64 bit range range all other system dll's are below that.
Could you explain why that is?
I tested Jeremy's HelloWorld2 program and on that program all system dll's are in 64 bit range.
Use the GoLink /LARGEADDRESSAWARE command line switch.
This assumes that you have made any necessary 64-bit pointer changes in your program. For example, instructions accessing memory using a base register and/or index register with a label address (ex. [rdx*4+MyTable]) do not use RIP-relative addressing, so this would need to be adjusted to handle a larger Image Base (ex. [rax+rdx*4] with rax as ADDR of MyTable).
SSE4 looks fairly straight forward to add as well...
It has been a while. I added to the above to-do list with ARGD, ARGQ, and SHADOW, but have already done these in a Beta version available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip). Although GoAsm version 0.62 will mainly update x64 floating-point issues, still good if a few others can test things out in advance since it has touched upon INVOKE processing.
BetaG also includes an encoding fix for MOVQ r64,xmm and MOVQ xmm/m64,xmm as well as improved List file output for ARGs, INVOKE, and repeat instructions and data declarations. I still have some work to do on INVOKE error for register already used (mixed case of regular and XMM), and shorter coding for an immediate floating-point value of 0.0.
Not mentioned above, ARGD and ARGQ memory arguments typically do not need a type indicator, so an additional feature with one specified is that the memory assumed as an integer gets converted to a floating point value (CVTSI2SS or CVTSI2SD) in register XMM0-3 (or for arguments 5 and above in XMM5 then with MOVD or MOVQ and use of R11 pushed onto the stack).
So, this ARGD/Q feature can only be used in x64 code? What about floating point parameters in x86 mode?
In x86 mode, ARGD is similar to ARG and does the usual push, but ARGQ enhancements are under consideration...
Version 0.62 BetaH now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip) which provides support for USES with XMM registers within FRAME...ENDF (for now, currently ignored within USEDATA...ENDU and USES...ENDU). I adjusted the initial post description, but a single USES statement can also be used with a mix of regular and XMM registers (still dealt with separately though).
As before, I still have some work to do on INVOKE error for register already used (mixed case of regular and XMM), shorter coding for an immediate floating-point value of 0.0, along with x86 ARGQ enhancements under consideration...
wjr,
Good to see you're still updating GoASM.
I will give it a test and report back any issues if they occur.
Keep it up!!
Version 0.62 BetaI now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip) which has shorter coding for an immediate floating-point value of 0.0.
This also has a fix for 64-bit and extended 32-bit register encoding for MOV r32/64, ADDR Local/Arg.
This also has a fix for use of SECTION ALIGN value, where the processing missed a few bytes at the end of the source file.
As for the INVOKE x64 error for register overwritten, this checking has now been removed (both regular and added XMM cases, didn't get around to mixed case scenarios). Although not common, some cases of register usage were still valid. This is also somewhat similar to no type checking, in that the function with a wrong value would typically not work, and this should be noticed at the testing stage. Something else currently under consideration now that that side of things is a bit more simple...
As before, I still have some work to do on USES with XMM registers within USEDATA...ENDU and USES...ENDU, along with x86 ARGQ enhancements under consideration...
Version 0.62 BetaJ now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip) with added support for 32-bit INVOKE ARGQ floating-point memory and immediate parameters (done with two push instructions, ex. OpenGL has several 32-bit functions taking double parameters). Shorter push encoding now used if possible for these immediate values. Fixed a problem with multiple floating-point with E+..., or E-..., in immediate INVOKE parameters or data declarations.
Getting there, still some work to do on USES with XMM registers within USEDATA...ENDU and USES...ENDU
Hello, good to see that goasm is keeping on going :thumbsup:
Good to see you keep on going wjr.
Thanks for all efforts!
Hello, as I see in 64 bits programming
movsxd rax, D[mSenos+rbx] ; Esto no funciona, asà que hay que hacer lo de abajo
So, I have to change it by the next lines:
xor rax, rax
mov eax, D[mSenos+rbx]
32 and 64 bits examples attached made with GoAsm
The first one will assemble fine without the D[...] memory type indicator (not needed since the instruction only takes r64, r/m32 as operands; also not needed in the second case due to 32-bit eax register).
However, both of those cases do not use RIP-addressing, so for 64-bit with GoLink option /largeaddressaware (or /base with a large address) you would need to use something like:
lea rax,mSenos
movsxd rax,[rax+rbx]
mSenos is an array of dwords, so I need explicitly indicate that I want recuperate dwords, not qwords even if I am in a 64 bits environment. If I collected qwords from this array, the consequences would be unpredictable.
I shall see if I can adjust to avoid that error message, but the movsxd instruction doesn't explicitly require the D type indicator (the 'd' in the instruction also indicates a 32-bit source, so no chance of qwords being used).
Thank you, it would be nice. To see some samples in 64 bits, being mSenos an array of dwords
- In fasm, we can do the next:
stdcall DrawCopperBar, dword [mSenos+ebx], 0
I didn't see the debugger, I imagine that the precompiler does the work with "movsxd rax, dword [mSenos+ebx]" before using it.
- In PoAsm is not so easy and I have to do it by myself:
movsxd rax, dword ptr [mSenos+rbx]
invoke DrawCopperBar, rax, 0
- In GoAsm is not so easy:
xor rax, rax
mov eax, D[mSenos+rbx]
invoke DrawCopperBar, rax, 0
Other behaviours that I have seen are the next regarding the paramethers in an invoke
- Fasm
myProc proc par1, par2
mov [par1], rcx ; One have to do it explicitelly or just use rcx, rdx, r8, r9
mov [par2], rdx
endp
- PoAsm
myProc proc Tpar1, Tpar2
local par1:QWORD, par2:QWORD ; using uppercase is mandatory
mov [par1], rcx ; Not possible to move the values to Tpar1, Tpar2, better use locals variables
mov [par2], rdx
endp
- GoAsm
myProc proc Tpar1, Tpar2
; No need to do anything, precompiler always do the assignation
endp
Regarding the use of formulae in constants, GoAsm is very restrictive, and sometimes is needed to use parenthesis, otherwise don't use "*" before "+", for example.
One example:
cdMAXCOLOR = 192
cdPalSize = cdMAXCOLOR
stPaleta struc
Rojo db ?
Verde db ?
Azul db ?
Alfa db ?
stPaleta ends
; miPaleta stPaleta 5*cdPalSize dup <> ; This line produces a failure in the code
; miPaleta stPaleta (5*cdPalSize) dup <> ; This line produces a failure in the code
miPaleta stPaleta 960 dup <> ; 5*cdPalSize = 960
Regards
Version 0.62 BetaK now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip) with an adjustment for MOVSXD giving instead a warning for type indicator not needed. Also...
There are several other common instructions that have a 64-bit destination that can sign extend a 32-bit immediate (and even 8-bit immediate). The MOV instruction continues to do this, but unlike other instructions, MOV does allow a 64-bit immediate value, and GoAsm does encode it as such if there are bits set in the high DWORD. However, in order to distinguish a 32-bit signed value from one intended to be a 64-bit value, GoAsm now in this case recognizes the C style hex and decimal LL suffix notation (already allowed L, but doesn't enforce 32-bit) to encode the imm64 version of this instruction:
48 C7 C1 FF FF FF FF mov rcx,0xFFFFFFFF ;sign extended to 0xFFFFFFFFFFFFFFFF
48 B9 FF FF FF FF 00 00 00 00 mov rcx,0xFFFFFFFFLL ;uses an imm64 0x00000000FFFFFFFF
Yes, the Arithmetic section does document some limitations, with brackets evaluated first if needed, otherwise with strict left-to-right evaluation order. As for DUP, so far it looks like a bit more documentation required along with a possible error condition... with regular data declarations the duplicate amount needs to start with a number, arithmetic allowed. Unfortunately things get more complicated with a structure... here the duplicate amount needs to be a number, or just a symbol that equates to an arithmetic expression that evaluates to a number. Still looking into this, but with that limitation in place, there should have been an error for use of arithmetic in your last example...
Version 0.62 BetaL now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip). Finally nearing completion on this release having found USES with XMM registers within FRAME...ENDF to be sufficient (so not available within USES...ENDU or USEDATA...ENDU).
Note that the less common USES...ENDU remains available for 32-bit, but for /x86 and /x64 this will now need to be changed (since it is not a leaf function) to a USES statement within FRAME...ENDF for upcoming exception handling.
Good to see that GoAsm is still being updated, it's been a while as I've been coding in high level languages for the last few years but have recently taken on a project well suited to assembly (with the inclusion of SQL lite). It's at best a year long personal project but it'll be nice to get back to assembly programming.
Welcome back, it has been a while - on that note...
Version 0.62 BetaM now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip). I have changed to more appropriate instruction usage so that if applicable, ARGD may use MOVSS, ARGQ may use MOVSD, and the same with the INVOKE variations of these.
Busy spell, hopefully I can start picking up the pace on the other items once done the documentation changes for the final v0.62.
Keep the updates comming wjr.
I for certain appreciate all the work you are putting into updating GoASM.
Version 0.62 BetaO now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip).
This has some adjustments for SHADOW error messages, also detecting some less likely syntax errors, with several error messages now showing more specific source text for the error in syntax. Similar error message adjustments were made for FRAME USES and LOCAL. Note that FRAME USES LOCAL and SHADOW should be on seperate lines.
This also has a fix (was in BetaN up earlier) for a problem with some non-standard constant section names in a static LIB file.
Making progress on the documentation update, but in the meantime, version 0.62 BetaP now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip) with the following changes:
- fixed problem in a few cases with operand AH,BH,CH,DH not giving an error with use of REX override
- fixed MOV instruction with control register R8 not getting the proper REX byte
- fixed problem with use of a symbol defined as a memory operand with a type override
- fixed an encoding issue with EXTRQ instruction with 3 operands
- added 64-bit variant of MOVNTI instruction
- added instruction CMPXCHG16B
- within FRAME...ENDF a RET 0 now doesn't do stack clean-up of parameters (32-bit cdecl-like, but caller should still do this)
Quote from: wjr on March 13, 2021, 01:39:42 PM
Making progress on the documentation update, but in the meantime, version 0.62 BetaP now available here http://www.godevtool.com/GoasmBeta.zip (http://www.godevtool.com/GoasmBeta.zip) with the following changes:
- fixed problem in a few cases with operand AH,BH,CH,DH not giving an error with use of REX override
- fixed MOV instruction with control register R8 not getting the proper REX byte
- fixed problem with use of a symbol defined as a memory operand with a type override
- fixed an encoding issue with EXTRQ instruction with 3 operands
- added 64-bit variant of MOVNTI instruction
- added instruction CMPXCHG16B
- within FRAME...ENDF a RET 0 now doesn't do stack clean-up of parameters (32-bit cdecl-like, but caller should still do this)
Any idea when the beta changes will be merged with the release version?
Still in a busy spell, but I would like to finish things up with v0.62 before the end of this month.