HJWasm

[habran]

Thanks Johnsa, :t
I'll check it 

[habran]

Hi Johnsa,
I have changed alignment to be able to align to 32 and it works, even though it complains:
warning A4130: Incompatible with segment alignment: 32
I tested it and it works properly on my laptop

please test this one

[johnsa]

Hi,

Yeah I know about the warning with align 32, but that's not the problem. The problem is that it's (incorrectly) assembling SIMD(128bit) instructions to their AVX(256bit) equivalents.
So:

vmovaps xmm1,pt

is becoming

vmovaps ymm1,pt (once assembled).

Possibly related to the opcode-prefix emit again in codegen ?

[habran]

Did you test this one, because it works as expected on my lap

[johnsa]

CORRECT:
   908:    vmovaps xmm7,xmmword ptr pt1
000000013F5846D8 C5 F8 28 3D 40 60 00 00 vmovaps     xmm7,xmmword ptr [pt1 (013F58A720h)] 

WRONG:
   909:    vmovaps xmm8,pt2
000000013F5846E0 C5 7C 28 05 48 60 00 00 vmovaps     ymm8,ymmword ptr [pt2 (013F58A730h)] 
   910:    vmovaps xmm9,pt3
000000013F5846E8 C5 7C 28 0D 50 60 00 00 vmovaps     ymm9,ymmword ptr [pt3 (013F58A740h)] 
   911:    vmovaps xmm10,pt4
000000013F5846F0 C5 7C 28 15 58 60 00 00 vmovaps     ymm10,ymmword ptr [pt4 (013F58A750h)] 

It works IF and only IF you type out XMMWORD PTR.
If you leave that out, it get's it wrong, and it should know from the register what the size is (like it does in 2.13 and before).

[habran]

How is it possible
Look this:
   513:  vmovaps ymm6,ymem
0000000000391508 C5 FC 28 74 24 30    vmovaps     ymm6,ymmword ptr [ymem] 
   514:  vmovaps xmm7,xmem   
000000000039150E C5 F8 28 7C 24 50    vmovaps     xmm7,xmmword ptr [xmem] 

[johnsa]

IF you declare the variable:

xmem XMMWORD 0,0,0,0

or

LOCAL xmem:XMMWORD

then it works too without the XMMWORD PTR on the instruction.

If the data is just in memory without the XMMWORD qualified type is when it doesn't work.

So in my case I use VirtualAlloc and point at that data, then it's wrong. I also use my own custom struct __mm128 which unions integer and float (like intrinsics).
If I point at that type it also doesn't work.
(This is working in 2.13 and before so it's some sort of regression in the latest version).

Try this:

  909:    vmovaps xmm7,[rsi] ;pt1
000000013FE046D8 C5 FC 28 3E          vmovaps     ymm7,ymmword ptr [rsi] 

[habran]

OK, now it doesn't compile properly
Thanks, I'll try to fix it ASAP
I have to go now, be back in 2 hours

[habran]

in .data? section

[habran]

Fixed

[johnsa]

My 3 big test projects all work 100% now including some really hairy avx stuff and macro layers doing OOP! So far it looks good to go! :) 
I'm still not able to link using the table+index style EA addressing.. and for some reason I cannot install VS2013 over my VS2012 Ultimate install I already have :( Although I don't see why VS2013 Link would behave any differently to 2012.

Good job!

[jj2007]

I get plenty of errors, so I assume this is the 64-bit version 8)

[habran]

JJ here is a 32 bit
test it please

Thanks Johnsa :t
AFAIK, if you want to link AVX2 you need VS13 linker
I am afraid that you will have to accept the reality
however VS15 Community will be soon availible
I have already installed   VS15 Community RC and it works pretty good

[jj2007]

JJ here is a 32 bit
test it please

Plenty of error messages for Windows.inc, line 12948:

Code: [Select]

MOUSEINPUT STRUCT
   _dx                    DWORD ?
   dy                     DWORD ?
Same for line 19062:

Code: [Select]

NMLVSCROLL STRUCT
   hdr                    NMHDR <>
   _dx                    DWORD ?
   dy                     DWORD ?
NMLVSCROLL ENDS
Using _dy instead of dy makes MB assemble without errors, but that could break existing Masm32 code.

The pair _dx / dy is certainly inconsistent, but it's a bit late in the process to change Windows.inc; perhaps you can find the culprit in HJWasm which declares "dy" a reserved word...

[johnsa]

Habran did mention earlier about making that change.

DO, DY and DZ are now reserverd data type defines (like DD,DW etc) for XMM,YMM and ZMM respectively.
I've changed the dy/dx in my windows.inc to _dy, _dx and so-far it has not caused any issue elsewhere.

Apart from that is it working ok?