HJWasm 2.24 release

[aw27]

Hi,

Right the packages have been updated again on git/master and on the site.
Still 2.24 but it should address AW27's USES issue now.

Let me know how that works out for you! :)

Cheers
John

Not fixed yet, does not align the stack on entry.
proc1:
000000013FDD1051  sub         rsp,30h 
000000013FDD1055  movdqa      xmmword ptr [rsp],xmm6 
000000013FDD105A  mov         eax,40000000h 
000000013FDD105F  movd        xmm0,eax 
000000013FDD1063  shufps      xmm0,xmm0,0 
000000013FDD1067  movaps      xmmword ptr [rsp+20h],xmm0 
000000013FDD106C  movdqa      xmm6,xmmword ptr [rsp] 
000000013FDD1071  add         rsp,30h 
000000013FDD1075  ret 

[johnsa]

aw27, can you send me the source for that proc exactly ?
I've tried a bunch of similar ones and they all seem to be fine.

Thanks!

[aw27]

aw27, can you send me the source for that proc exactly ?
I've tried a bunch of similar ones and they all seem to be fine.

Thanks!

option casemap:none
option frame:auto
OPTION WIN64:15
OPTION STACKBASE:RSP

proc1 proc public FRAME uses xmm6 _rcx : qword, _rdx: qword, _r8: qword, _r9 : qword, other: qword
   LOCAL lvar1 : ptr
   LOCAL lvar2 : XMMWORD
   mov eax, 2.0
   movd xmm0, eax
   shufps xmm0, xmm0,0
   movaps XMMWORD ptr lvar2, xmm0
   
   ret
proc1 endp

end

[jj2007]

Minimally modified to make it build:

Code: [Select]

option casemap:none
option frame:auto
OPTION WIN64:15
OPTION STACKBASE:RSP
.code

proc1 proc public FRAME uses xmm6 _rcx : qword, _rdx: qword, _r8: qword, _r9 : qword, other: qword
   LOCAL lvar1 : ptr
   LOCAL lvar2 : XMMWORD
   mov eax, 2.0
   movd xmm0, eax
   shufps xmm0, xmm0,0
   movaps XMMWORD ptr lvar2, xmm0
   mov rax, other   
   ret
proc1 endp

start: int 3
invoke proc1, 1, 2, 3, 4, 5
end start
Under the hood:

Code: [Select]

0000000140001000 | 48 83 EC 30                   | sub rsp, 30                                   |
0000000140001004 | C5 F9 7F 34 24                | vmovdqa xmmword ptr ss:[rsp], xmm6            |
0000000140001009 | B8 00 00 00 40                | mov eax, 40000000                             |
000000014000100E | 66 0F 6E C0                   | movd xmm0, eax                                |
0000000140001012 | 0F C6 C0 00                   | shufps xmm0, xmm0, 0                          |
0000000140001016 | 0F 29 44 24 20                | movaps xmmword ptr ss:[rsp+20], xmm0          |
000000014000101B | 48 8B 44 24 58                | mov rax, qword ptr ss:[rsp+58]                | rax:BaseThreadInitThunk
0000000140001020 | C5 F9 6F 34 24                | vmovdqa xmm6, xmmword ptr ss:[rsp]            |
0000000140001025 | 48 83 C4 30                   | add rsp, 30                                   |
0000000140001029 | C3                            | ret                                           |
000000014000102A | CC                            | int3                                          |
000000014000102B | 48 C7 C1 01 00 00 00          | mov rcx, 1                                    |
0000000140001032 | 48 C7 C2 02 00 00 00          | mov rdx, 2                                    |
0000000140001039 | 49 C7 C0 03 00 00 00          | mov r8, 3                                     |
0000000140001040 | 49 C7 C1 04 00 00 00          | mov r9, 4                                     |
0000000140001047 | 48 C7 44 24 20 05 00 00 00    | mov qword ptr ss:[rsp+20], 5                  |
0000000140001050 | E8 AB FF FF FF                | call 140001000                                |
On entry into the proc, the stack is 12FF50h, so it is aligned. Commandline is HJWasm32 /c /Zp8 -win64
Btw is the mov qword ptr ss:[rsp+20], 5 legal? Does the OS already provide shadow memory?

[aw27]

On entry into the proc, the stack is 12FF50h, so it is aligned.

If it is aligned on entry is because it was misaligned at the time of the call, probably that is the real problem.

[johnsa]

It does (from what I've seen).. but that said I wouldn't count on it..

I Always make the entrypoint a FRAME PROC like

WinMainCRTStartup PROC FRAME

  invoke main
 invoke ExitProcess,0

WinMainCRTStartup

end WinMainCRTStartup

that way you get the guarantee of starting off right.

the problem in this example is the first line in the prologue:
given that the return address is pushed, whatever is subtracted from rsp must include an extra 8 to bring it back into alignment.. I'm looking into it now..

Code: [Select]

0000000140001000 | 48 83 EC 30                   | sub rsp, 30                                   |

What's odd is this one works fine :

Code: [Select]

procc proc uses xmm6

mov         eax,40000000h 
movd        xmm0,eax 
shufps      xmm0,xmm0,0 

ret
procc endp

==

Code: [Select]

48 83 EC 18          sub         rsp,18h 
C5 F9 7F 34 24       vmovdqa     xmmword ptr [rsp],xmm6 
B8 00 00 00 40       mov         eax,40000000h 
66 0F 6E C0          movd        xmm0,eax 
0F C6 C0 00          shufps      xmm0,xmm0,0 
C5 F9 6F 34 24       vmovdqa     xmm6,xmmword ptr [rsp] 
48 83 C4 18          add         rsp,18h 
C3                   ret


[johnsa]

Ok.. It's fixed.. 2.25 is ready to roll.

be back shortly :)

[Adamanteus]

The expression evaluator seems to need that to force evaluation of opattr first.

This seems to have carried over from jwasm originally as it responds the same.

And till present version failing :

1. LEA   EDX, [ESP + TYPE EDX] is not LEA   EDX, [ESP + 4] :

Code: (c) [Select]

expreval.c

// line 499 : type for not indirect addresing

          if( flags & EXPF_IN_SQBR && (i == 0 || tokenarray[i - 1].tokval != T_TYPE)) {
            /* a valid index register? */
            if ( GetSflagsSp( j ) & SFR_IREG ) {
tokenize.c

// line 518 :

    buf->tokval = 0;
    switch( symbol ) {

2. OPATTR fixed for example above, but such macro anyway not works :

Code: (asm) [Select]

LODCX  macro REG:REQ
  if TYPE (&REG) eq 4
  MOV ECX, REG
  else
   if OPATTR (&REG) and 00000101b
MOV ECX, REG
   else
MOVZX ECX, REG
   endif
  endif
ENDM
3. JA/JAE opcode also giving food for thinking

Code: [Select]

instruct.h

// line 57 :

jcc( A,   0x3,   a )
jcc( AE,  0x7,  ae )


[johnsa]

Can you provide a code sample that I can build to test with ? and we'll have a look.

Thanks,
John

[Adamanteus]

 All is above, with what I fixed in sources of HJWasm - in p. 1 and p. 3 , in OPATTR - I'm not specialist  8)

[johnsa]

I meant an asm test source if you have one, so that it can sit in the pack of regression tests and so I can see the errors you're talking about :)

[johnsa]

ja/jae are fine , not sure what you're trying to change there??

   jae lbl1   
73 00                jae         proc1+19Eh (013F5F15A3h) 
   lbl1:
   ja lbl2
77 00                ja          proc1+1A0h (013F5F15A5h) 
   lbl2:


AE needs to be 3 and A 7 as they're added to the base JCC opcode byte.

[johnsa]

Code: [Select]

LODCX  macro REG:REQ
  if TYPE (&REG) eq 4
  MOV ECX, REG
  else
   if (OPATTR (&REG)) and 00000101b
MOV ECX, REG
   else
MOVZX ECX, REG
   endif
  endif
ENDM

this works fine, you need the extra brackets.

[johnsa]

1. LEA   EDX, [ESP + TYPE EDX] is not LEA   EDX, [ESP + 4] :

Code: [Select]

expreval.c

// line 499 : type for not indirect addresing

          if( flags & EXPF_IN_SQBR && (i == 0 || tokenarray[i - 1].tokval != T_TYPE)) {
            /* a valid index register? */
            if ( GetSflagsSp( j ) & SFR_IREG ) {
tokenize.c

// line 518 :

    buf->tokval = 0;
    switch( symbol ) {

I don't see any harm in these changes, I've tested it and it allows lea rdx,[rsp+type rdx] to work with the desired displacement.

[Adamanteus]

For opcode, exists opposite descriptions :
 1. Correct
 JAE IF (CF==0) OR (ZF==0) - need 77  cb
 2. Incorrect
 JAE IF (CF==0) - 73  cb

this works fine, you need the extra brackets.

- not useful ...