HJWasm

[habran]

rrr314159 did you try to build it with HJWasm32 with the 80 levels?

[rrr314159]

Sorry Habran, the HJWasm.exe from HJWasm32.zip (a few posts ago, Reply #4), also gives error A2100 with 41 nesting levels

[habran]

Nasm has got 40 levels as well, for now I will leave it like that, perhaps later when I have more time I will try to improve that

[rrr314159]

H/JWasm is equal to MASM in this regard, and better in at least one circumstance, the recursion test, where MASM only does 20 levels. But the original problem was that MASM handled (some number of) levels while JWasm didn't. So obviously there's more to the story, it's not just about the 40 levels of nesting.

[HSE]

Hi!

I download MinGW-Gcc and succesfully compile JWasm13.

Changing the messages found that was MacroLevel what throw the error. I don't have a clue of what it means but I change MAX_MACRO_NESTING to 80, and erase all the objects previously compiled. The new compilation work perfectly. The first rrr test support 79 levels now and the second test reach SumMacro77  :t.

(Of course that don't explain the differences between compilers, the question remains)   

Thanks. HSE   

[habran]

Hi HSE
Glad it works for you :t
As I said before I'll look at it bit later when I get some more time

[habran]

I have uploaded new version at the top of the trad with 4 new instructions:
VGATHERDPD, VGATHERQPD, VGATHERDPS, VGATHERQPS
now there are available 8 new instructions:

Code Select Expand


VGATHERDPD xmm1, [rdi+xmm7*2], xmm2
VGATHERDPD ymm1, [rdi+xmm7*2], ymm2
VGATHERQPD xmm1, [rdi+xmm7*2], xmm2
VGATHERQPD ymm1, [rdi+ymm7*2], ymm2

VGATHERDPS xmm1, [rdi+xmm7*2], xmm2
VGATHERDPS ymm1, [rdi+ymm7*2], ymm2
VGATHERQPS xmm1, [rdi+xmm7*2], xmm2
VGATHERQPS xmm1, [rdi+ymm7*2], xmm2

VPGATHERDD xmm1, [rdi+xmm7*2], xmm2
VPGATHERDD ymm1, [rdi+ymm7*2], ymm2
VPGATHERQD xmm1, [rdi+xmm7*2], xmm2
VPGATHERQD xmm1, [rdi+ymm7*2], xmm2

VPGATHERDQ xmm1, [rdi+xmm7*2], xmm2
VPGATHERDQ ymm1, [rdi+xmm7*2], ymm2
VPGATHERQQ xmm1, [rdi+xmm7*2], xmm2
VPGATHERQQ ymm1, [rdi+ymm7*2], ymm2

HJWasm logo will now display 32bit or 64bit on HSE riquest

[habran]

Here is fixed version for rip instruction     somedata[rip+reg*8]

EDIT:
Sorry, it was buggy, I had to remove it till I fix it

[rrr314159]

habran, yes it's buggy, didn't seem to recognize include files

[habran]

Thanks rrr314159,
I'll Be Back 8)

[habran]

Fixed

Because I have introduced 3 new data definition directive 'DO' data for XMMWORD, 'DY' data for YMMWORD and 'DZ' for ZMMWORD you have to fix headers where you have do, dy, dz  by replacing them with do_, dy_, dz_
There is also in ocidl.inc:
line 2720 STDMETHOD Do, :ptr IOleUndoManager replace with STDMETHOD Do_, :ptr IOleUndoManager
line 2789 STDMETHOD Do, :ptr IOleUndoManager replace with STDMETHOD Do_, :ptr IOleUndoManager

[rrr314159]

The problem I have appears unrelated to do, dy, dz. 64-bit simply isn't recognizing include files. For instance first error I get is "Symbol not defined: INFINITE", which is used by thread routine from an include. If I define it in the .asm, get "Symbol not defined: TRUE", the next one in the include. etc.

OTOH 32-bit (without -win64 option) found two dy's in windows.inc to fix, then ran, but the prog didn't work right. I could track down what went wrong if you want, but at least include files are recognized correctly.

Don't sweat it on my account, I'm fine using the older version

[habran]

It is running flawlessly on my laptop
I am using windowsinc and I tested it on my other project

Do you use VS13 and if yes, did you install HJWasm targets?

I am curios if Johnsa has the same problem
 

[habran]

Hi Johnsa,
thanks for finding the bug with REP MOVS
It was easy to fix ones when we know what is the bug and what is causing it
it was in codegen.c:

if( CodeInfo->prefix.ins != EMPTY && (CodeInfo->token < T_VPGATHERDD && CodeInfo->token > T_VGATHERQPS))
tmp = InstrTable[ IndexFromToken( CodeInfo->prefix.ins )].allowed_prefix;

and was supposed to be:

if( CodeInfo->prefix.ins != EMPTY && (CodeInfo->token < T_VPGATHERDD || CodeInfo->token > T_VGATHERQPS))
tmp = InstrTable[ IndexFromToken( CodeInfo->prefix.ins )].allowed_prefix;

here it is:

[johnsa]

New problem now :( :(

   918:    
   919:    vmovaps xmm7,pt1
000000013F9D47C8 C5 FC 28 3D 50 5F 00 00 vmovaps     ymm7,ymmword ptr [pt1 (013F9DA720h)] 
   920:    vmovaps xmm8,pt2
000000013F9D47D0 C5 7C 28 05 58 5F 00 00 vmovaps     ymm8,ymmword ptr [pt2 (013F9DA730h)] 
   921:    vmovaps xmm9,pt3
000000013F9D47D8 C5 7C 28 0D 60 5F 00 00 vmovaps     ymm9,ymmword ptr [pt3 (013F9DA740h)] 
   922:    vmovaps xmm10,pt4
000000013F9D47E0 C5 7C 28 15 68 5F 00 00 vmovaps     ymm10,ymmword ptr [pt4 (013F9DA750h)] 
   923:

xmm stuff seems to be assembling as ymm and i'm getting funny crash from it:
Unhandled exception at 0x000000013F5A47D0 in test.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
I assume because the ymm's are only 16byte aligned and not 32 (so the ymm read would be unaligned).