Upcoming GoAsm x86/x64 changes

[FlySky]

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!!

[wjr]

Version 0.62 BetaI now available here 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...

[wjr]

Version 0.62 BetaJ now available here 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

[avcaballero]

Hello, good to see that goasm is keeping on going

[FlySky]

Good to see you keep on going wjr.

Thanks for all efforts!

[avcaballero]

Hello, as I see in 64 bits programming

Code Select Expand


    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:

Code Select Expand


    xor      rax, rax
    mov      eax, D[mSenos+rbx]


32 and 64 bits examples attached made with GoAsm

[wjr]

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:

Code Select Expand


lea rax,mSenos
movsxd rax,[rax+rbx]


[avcaballero]

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.

[wjr]

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).

[avcaballero]

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:

Code Select Expand

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:

Code Select Expand


    movsxd   rax, dword ptr [mSenos+rbx]
    invoke   DrawCopperBar, rax, 0

- In GoAsm is not so easy:

Code Select Expand


    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

Code Select Expand


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

Code Select Expand


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

Code Select Expand


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:

Code Select Expand


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

[wjr]

Version 0.62 BetaK now available here 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:

Code Select Expand


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... 

[wjr]

Version 0.62 BetaL now available here 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.

[Donkey]

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.

[wjr]

Welcome back, it has been a while - on that note...

Version 0.62 BetaM now available here 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.

[FlySky]

Keep the updates comming wjr.
I for certain appreciate all the work you are putting into updating GoASM.