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:
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
I don't think this bug has been fixed yet.
Bug (http://masm32.com/board/index.php?topic=6103.msg64787#msg64787)
Quote from: aw27 on April 04, 2017, 08:45:49 PM
I don't think this bug has been fixed yet.
Bug (http://masm32.com/board/index.php?topic=6103.msg64787#msg64787)
Did you try with WIN64:15 ?
Link to hjwasm224_x86.zip on terraspace leads to old version 2.23.
Anyway,i just want to try new feature: "Added support for allocating wide strings in data with dw."
Simple code:
.data
buff01 db '12345678',0,0
buff02 dw '1','2','3','4','5','6','7','8',0,0
buff03 dw '12345678',0,0
I think 'buff02' is old ugly style of writing wide chars and 'buff03' is new friendly style. But as I figure out, 'buff02' not equal to 'buff03'.
Result:
mov eax,LENGTHOF buff01 ; mov eax,00000000A
mov eax,LENGTHOF buff02 ; mov eax,00000000A
mov eax,LENGTHOF buff03 ; mov eax,3
mov eax,sizeof buff01 ; mov eax,00000000A
mov eax,sizeof buff02 ; mov eax,000000014
mov eax,sizeof buff03 ; mov eax,6
mov eax,type buff01 ; mov eax,1
mov eax,type buff02 ; mov eax,2
mov eax,type buff03 ; mov eax,2
Only 'type' works. ::)
Quote from: johnsa on April 04, 2017, 09:09:18 PM
Quote from: aw27 on April 04, 2017, 08:45:49 PM
I don't think this bug has been fixed yet.
Bug (http://masm32.com/board/index.php?topic=6103.msg64787#msg64787)
Did you try with WIN64:15 ?
WIN64:15, now add uses xmm6 and retry:
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
And more tips that not works :
.686
.model flat,stdcall
TEST_evaluate macro REG
; if TYPE (®) and 00000001b
if OPATTR (®) and 00000001b
mov ecx, REG
else
movzx ecx, REG
endif
ENDM
.data
len dw 1
.code
start:
TEST_evaluate len
RET
end start
Quote from: powershadow on April 04, 2017, 10:06:15 PM
Link to hjwasm224_x86.zip on terraspace leads to old version 2.23.
Anyway,i just want to try new feature: "Added support for allocating wide strings in data with dw."
Simple code:
.data
buff01 db '12345678',0,0
buff02 dw '1','2','3','4','5','6','7','8',0,0
buff03 dw '12345678',0,0
I think 'buff02' is old ugly style of writing wide chars and 'buff03' is new friendly style. But as I figure out, 'buff02' not equal to 'buff03'.
Result:
mov eax,LENGTHOF buff01 ; mov eax,00000000A
mov eax,LENGTHOF buff02 ; mov eax,00000000A
mov eax,LENGTHOF buff03 ; mov eax,3
mov eax,sizeof buff01 ; mov eax,00000000A
mov eax,sizeof buff02 ; mov eax,000000014
mov eax,sizeof buff03 ; mov eax,6
mov eax,type buff01 ; mov eax,1
mov eax,type buff02 ; mov eax,2
mov eax,type buff03 ; mov eax,2
Only 'type' works. ::)
2.24 packages updated on the site, (link to 2.24 corrected as well), the sizeof, lengthof operators should be right now.
Quote from: Adamanteus on April 04, 2017, 10:45:53 PM
And more tips that not works :
.686
.model flat,stdcall
TEST_evaluate macro REG
; if TYPE (®) and 00000001b
if OPATTR (®) and 00000001b
mov ecx, REG
else
movzx ecx, REG
endif
ENDM
.data
len dw 1
.code
start:
TEST_evaluate len
RET
end start
macro.h
line 62 :
extern ret_code StoreAutoMacro(struct dsym *macro, int i, struct asm_tok tokenarray[], bool store_data, char *macCode[], int macLine, int macLen); /* store macro content 1st pass (builtin macros) */
data.c
line 1413 :
if (!foundSubType)
{
EmitErr(INVALID_DATA_INITIALIZER, sym->name);
return EMPTY;
}
macro.c
line 155 :
*start = PLACEHOLDER_CHAR;
start++;
line 397, 512, 725, 840 :
"mnames[mindex].label" replace on : mnames[mindex].label ? mnames[mindex].label : "NULL"));
parser.c
line 55 :
#include "lqueue.h"
simsegm.c
line 23 :
#include "equate.h"
This seems to work as expected and generates an asm error? Same outcome with original JWasm, what am I looking for here ? :)
It's expression in macro TEST_evaluate - that generating error, when argument (len) is not code label !
Try this:
if (OPATTR (®)) and 00000001b
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.
Yes, this way everything works - I even found this trick when begun add it to old code. But that I suppose stayed from JWasm, and that is to masm not need, so ...
Quote
2.24 packages updated on the site, (link to 2.24 corrected as well), the sizeof, lengthof operators should be right now.
:t . But, i can't find updated version on Github.
It's in the 2.24 branch if you really want it from there, I haven't committed it to master yet as I'm still fixing the USES bug that AW27 mentioned, once I'm happy with that I'll update through to master and the packages again.
2.24 (latest version of 20:45 & 20:47) works fine with my big sources :t
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
Quote from: johnsa on April 05, 2017, 04:54:59 AM
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
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!
Quote from: johnsa on April 05, 2017, 08:58:01 PM
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
Minimally modified to make it build: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: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?
Quote from: jj2007 on April 06, 2017, 12:54:39 AM
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.
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..
0000000140001000 | 48 83 EC 30 | sub rsp, 30 |
What's odd is this one works fine :
procc proc uses xmm6
mov eax,40000000h
movd xmm0,eax
shufps xmm0,xmm0,0
ret
procc endp
==
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
Ok.. It's fixed.. 2.25 is ready to roll.
be back shortly :)
Quote from: johnsa on April 05, 2017, 01:33:18 AM
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] :
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 :
LODCX macro REG:REQ
if TYPE (®) eq 4
MOV ECX, REG
else
if OPATTR (®) and 00000101b
MOV ECX, REG
else
MOVZX ECX, REG
endif
endif
ENDM
3. JA/JAE opcode also giving food for thinking
instruct.h
// line 57 :
jcc( A, 0x3, a )
jcc( AE, 0x7, ae )
Can you provide a code sample that I can build to test with ? and we'll have a look.
Thanks,
John
All is above, with what I fixed in sources of HJWasm - in p. 1 and p. 3 , in OPATTR - I'm not specialist 8)
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 :)
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.
LODCX macro REG:REQ
if TYPE (®) eq 4
MOV ECX, REG
else
if (OPATTR (®)) and 00000101b
MOV ECX, REG
else
MOVZX ECX, REG
endif
endif
ENDM
this works fine, you need the extra brackets.
1. LEA EDX, [ESP + TYPE EDX] is not LEA EDX, [ESP + 4] :
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.
For opcode, exists opposite descriptions :
1. (http://asm.inightmare.org/opcodelst/index.php?op=JA) Correct
JAE IF (CF==0) OR (ZF==0) - need 77 cb
2. (https://pdos.csail.mit.edu/6.828/2009/readings/i386/Jcc.htm) Incorrect
JAE IF (CF==0) - 73 cb
Quote from: johnsa on April 13, 2017, 01:24:21 AM
this works fine, you need the extra brackets.
- not useful ...
Straight from the Intel and AMD instruction manuals:
77 cb
JA rel8 D Valid Valid Jump short if above (CF=0 and ZF=0).
0F 87 cd
JA rel32 D Valid Valid Jump near if above (CF=0 and ZF=0).
73 cb
JAE rel8 D Valid Valid Jump short if above or equal (CF=0).
0F 83 cd
JAE rel32 D Valid Valid Jump near if above or equal (CF=0).
In all cases JAE needs to be 0x03 and JA needs to be 0x07, I have no idea where you're getting 77 cb for JAE from ?!?!?
Correct for programming is such :
77 cb
JAE rel8 D Valid Valid Jump short if above or equal (CF=0 and ZF=0).
0F 87 cd
JAE rel32 D Valid Valid Jump near if above or equal (CF=0 and ZF=0).
73 cb
JA rel8 D Valid Valid Jump short if above (CF=0).
0F 83 cd
JA rel32 D Valid Valid Jump near if above (CF=0).
deleted
Good catch, Nidud!
Thanks :t
I've put this in now, busy looking at an issue aw27 has found, once thats resolved I'll update the packages/git to 2.26 r2.
I still don't get what you're talking about with JA/JAE.. I've hand checked them, verified the results against the instruction manuals so I'm not sure.. anyone else care to way in on the issue ?
these fixes included and git / packages on the site updated.
Quote from: Adamanteus on April 13, 2017, 02:52:12 AM
Correct for programming is such :
77 cb
JAE rel8 D Valid Valid Jump short if above or equal (CF=0 and ZF=0).
0F 87 cd
JAE rel32 D Valid Valid Jump near if above or equal (CF=0 and ZF=0).
73 cb
JA rel8 D Valid Valid Jump short if above (CF=0).
0F 83 cd
JA rel32 D Valid Valid Jump near if above (CF=0).
This is from
Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2 (2A, 2B & 2C): Instruction Set ReferenceQuote77 cb JA rel8 D Valid Valid Jump short if above (CF=0 and ZF=0).
73 cb JAE rel8 D Valid Valid Jump short if above or equal (CF=0).
72 cb JB rel8 D Valid Valid Jump short if below (CF=1).
76 cb JBE rel8 D Valid Valid Jump short if below or equal (CF=1 or ZF=1).
72 cb JC rel8 D Valid Valid Jump short if carry (CF=1).
E3 cb JCXZ rel8 D N.E. Valid Jump short if CX register is 0.
E3 cb JECXZ rel8 D Valid Valid Jump short if ECX register is 0.
E3 cb JRCXZ rel8 D Valid N.E. Jump short if RCX register is 0.
74 cb JE rel8 D Valid Valid Jump short if equal (ZF=1).
7F cb JG rel8 D Valid Valid Jump short if greater (ZF=0 and SF=OF).
7D cb JGE rel8 D Valid Valid Jump short if greater or equal (SF=OF).
7C cb JL rel8 D Valid Valid Jump short if less (SF≠ OF).
7E cb JLE rel8 D Valid Valid Jump short if less or equal (ZF=1 or SF≠ OF).
76 cb JNA rel8 D Valid Valid Jump short if not above (CF=1 or ZF=1).
72 cb JNAE rel8 D Valid Valid Jump short if not above or equal (CF=1).
73 cb JNB rel8 D Valid Valid Jump short if not below (CF=0).
77 cb JNBE rel8 D Valid Valid Jump short if not below or equal (CF=0 and
Quote from: nidud on April 13, 2017, 03:07:03 AM
There may be brackets added here:
lea edx,[esp + type edx ]
lea edx,[esp + type(edx)]
But that's extensioning language, maby need maybe not, so better I'd make under condition :
#if defined SYN_TYPE_RB
if ( (i > 0 && tokenarray[i - 1].tokval == T_TYPE) ||
(i > 1 && tokenarray[i - 1].token == T_OP_BRACKET
&& tokenarray[i - 2].tokval == T_TYPE) )
; /* v2.24 [reg + type reg] | [reg + type(reg)] */
else if ( flags & EXPF_IN_SQBR ) {
#else
if( flags & EXPF_IN_SQBR && (i == 0 || tokenarray[i - 1].tokval != T_TYPE)) {
#endif
Quote from: habran on April 13, 2017, 08:09:59 AM
77 cb JA rel8 D Valid Valid Jump short if above (CF=0 and ZF=0).
73 cb JAE rel8 D Valid Valid Jump short if above or equal (CF=0).
72 cb JB rel8 D Valid Valid Jump short if below (CF=1).
- variosly, thay simple changed mnemomics, as to hardware it not too mach care
P.S. Sorry, with opcode I mistaken - simple JAE really checking more flags, not just CF (looks like SF also)
P.P.S So, the flags mentioned in Intel docs, for use Jxx after ADD, ADC, SUB, SBB commands.