News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

HJWasm

Started by habran, July 07, 2015, 04:38:55 PM

Previous topic - Next topic

habran

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

rrr314159

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

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
Cod-Father

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.
I am NaN ;)

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   
Equations in Assembly: SmplMath

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
Cod-Father

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:

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
Cod-Father

habran

#22
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
Cod-Father

rrr314159

habran, yes it's buggy, didn't seem to recognize include files
I am NaN ;)

habran

Thanks rrr314159,
I'll Be Back 8)
Cod-Father

habran

Fixed :bgrin:

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
Cod-Father

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
I am NaN ;)

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
 
Cod-Father

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:
Cod-Father

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