HJWasm 2.23 Release

[aw27]

I've fixed this now.. but for option stackbase:rsp it means you need the value 15.

If you supply any value < 11, it becomes 11 (as this is the most sensible)... except if you specify 15 which it will accept as 15 = 11 + align16 bit set.
So you have 2 options with stackbase:rsp  ... 11 or 15 and that's it.

For stackbase rbp you can use any values between 0-7 as per normal.

This will be in 2.24 shortly along with some new presents :)

Looking forward to it.  :t

[johnsa]

The change I've made for 2.24 is to just take any local greater than a qword (in size) and align it's position up to 16. This happens in order, I don't want to shuffle the local order around in the assembler as it's not transparent to the user, which might in some case lead to undesirable outcomes, if for example someone writes code that assumes local B occurs after local A and they can be grabbed simultaneously..

Code: [Select]


MyProc PROC FRAME ....
  LOCAL a:XMMWORD            ; This is aligned 16 in all cases anyway..
  LOCAL b:QWORD
  LOCAL c:XMMWORD            ; This is now aligned to 16 with win64:15
  LOCAL d:DWORD
  LOCAL e:DWORD

  lea rax,e
  mov rax,[rax]              ; something like this where it might want to load in D and E at the same time... not that I'd recommend this.. but you never know!


So the alignment for win64:15 now will just insert the necessary padding in front of a local where it's required.

[aw27]

The change I've made for 2.24 is to just take any local greater than a qword (in size) and align it's position up to 16. This happens in order, I don't want to shuffle the local order around in the assembler as it's not transparent to the user, which might in some case lead to undesirable outcomes, if for example someone writes code that assumes local B occurs after local A and they can be grabbed simultaneously..

Code: [Select]


MyProc PROC FRAME ....
  LOCAL a:XMMWORD            ; This is aligned 16 in all cases anyway..
  LOCAL b:QWORD
  LOCAL c:XMMWORD            ; This is now aligned to 16 with win64:15
  LOCAL d:DWORD
  LOCAL e:DWORD

  lea rax,e
  mov rax,[rax]              ; something like this where it might want to load in D and E at the same time... not that I'd recommend this.. but you never know!


So the alignment for win64:15 now will just insert the necessary padding in front of a local where it's required.

It should work even for structure and union variables, independently of the alignment set for their fields.

[johnsa]

If the structure or union is >= 16 bytes it will, I can adjust this so that it applies it to ANY struct/union, but logically if the structure isn't at least 16 bytes in total size you wouldn't be using any aligned operations against it anyway ?

[aw27]

If the structure or union is >= 16 bytes it will, I can adjust this so that it applies it to ANY struct/union, but logically if the structure isn't at least 16 bytes in total size you wouldn't be using any aligned operations against it anyway ?

I don't think you should and users are expected to know that they should align the structure fields to 16 if the structure contains a XMMWORD, because the structure alignment on the stack to 16 bytes does not guarantee that some XMMWORD field inside the structure will be aligned to 16 bytes.

[johnsa]

Yep, well that's how it will be then in 2.24 as currently fixed, only the start address of the structure is guaranteed to be 16, not the fields inside it.

[powershadow]

Hi johnsa.
I am not familiar with asm x64. This is my first program, so I don’t know it’s my mistake or hjwasm bug or maybe it fixed in 2.23 version, because i test all in 2.22 version.

Simple source:

Code: [Select]

.686P

.x64

option casemap :none
option win64 : 11
option frame : auto
option stackbase : rsp

include WINDOWS.INC

includelib user32.lib
includelib Kernel32.Lib

.data
Text db '0123456789',0

.code

ShowMessage proc  FRAME
LOCAL TxtBuff[11]:byte
LOCAL Flag:BOOL

invoke ZeroMemory,addr TxtBuff,sizeof(TxtBuff)
invoke lstrcpy,addr TxtBuff,addr Text

invoke MessageBox,0,addr TxtBuff,"Info",MB_OK

; ---------------------------
; "Info" < Why double quote added to the text ???
; ---------------------------
; 0123456789 < Text is ok.
; ---------------------------
; OK   
; ---------------------------

mov Flag,TRUE

invoke MessageBox,0,addr TxtBuff,"Info",MB_OK

; ---------------------------
; "Info" < Why double quote added to the text ???
; ---------------------------
; 01234567 < "89" was rewritten by "mov Flag,TRUE"
; ---------------------------
; OK   
; ---------------------------

ret

ShowMessage endp


start proc FRAME

invoke ShowMessage
invoke ExitProcess,0

start endp

end start
Besides, could you explain when I need to add “FRAME” after the “proc”?  I can’t find any info about it.

[johnsa]

Amazingly.. I think you have found a bug, i'm working on it now !!!

So you can leave out .686P (you don't need that)

FRAME is now implied, so you don't have to specify it at all..
Basically under Win64 , procedures should have a pdata / xdata entry which allows for proper exception handling.. originally jwasm used frame:auto and FRAME on the PROC declaration to specify this behaviour, but along the lines it also got roped into how the prologue/epilogue is generated .. by inserting .PUSHREG and other exception frame related operations.. bottom line is, there is no reason not to have it, and to keep the code consistent we've forced it on for all procs.

So you can specify it, or not.. it doesn't matter anymore from 2.23

A PROC is a PROC is a PROC. :)

[aw27]

Amazingly.. I think you have found a bug, i'm working on it now !!!

The bug happens as well with option stackbase : rbp, unless you use option win64 : 2 which happens to fix the alignment issue.

[johnsa]

This is fixed now too for both rsp and rbp.

I'm just waiting for confirmation from Habran on some of his changes and as soon as he's ready we will put 2.24 up.

[johnsa]

I've put 2.24 up.

The fixes are:
stackbase:rsp overwriting locals in some cases. (powershadow's bug #1).
stackbase:rbp enforce stack allocations so setting bit 2 of win64 isn't required to get alignment working (aw27's bug).
invoke string literals no longer include the quotes " "s (powershadows bug #2).

stackbase:rsp with win64:15 supports LOCAL alignment to 32 now (if you want to use aligned YMMWORDS or great).
Any structure or union .. in fact any local that is >= 16 bytes in size will be aligned to 16 under both rsp and rbp.

SYSTEM V ABI calls are in now too (this is early days experimental, and too serve as a test-case for adding delphi calls next). It also helps move towards the goal of full OSX and Linux support, now that we have an OSX build of HJWASM too.
To use win64 flags still apply (will be aliased in future), stackbase:rbp must be used and then a proc is simply decorated with:

Code: [Select]


OPTION ARCH:SSE
nixproc PROC SYSTEMV USES rbx xmm0 arg1:qword, arg2:DWORD, arg3:REAL4
LOCAL mem:DWORD
LOCAL vec:XMMWORD
mov rbx,arg1
mov ecx,arg2
mov eax,10
mov mem,eax
mov ecx,mem
IF @Arch EQ 0
movss xmm10,arg3
movaps xmm0,vec
ELSE
vmovss xmm10,arg3
vmovaps xmm0,vec
ENDIF
ret
nixproc ENDP
OPTION ARCH:AVX