terraspace / uasm

UASM - Macro Assembler

---

---

Authors

• Branislav Habus
• John Hankinson

---

On the Web

(http://www.terraspace.co.uk/uasm.html)

License

• This file contains Original Code and/or Modifications of Original
• Code as defined in and that are subject to the Sybase Open Watcom
• Public License version 1.0 (the 'License'). You may not use this file
• except in compliance with the License. BY USING THIS FILE YOU AGREE TO
• ALL TERMS AND CONDITIONS OF THE LICENSE. A copy of the License is
• provided with the Original Code and Modifications, and is also
• available at www.sybase.com/developer/opensource.
• The Original Code and all software distributed under the License are
• distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
• EXPRESS OR IMPLIED, AND SYBASE AND ALL CONTRIBUTORS HEREBY DISCLAIM
• ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF
• MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR
• NON-INFRINGEMENT. Please see the License for the specific language
• governing rights and limitations under the License.

uasm's Issues

Regression Fix #1

In .386 mode

0000000F 6C0000 ins [vb],dx
00000012 6D0000 ins [vw],dx
00000015 666D0000 ins [vd],dx
00000019 6C0000 ins es:[vb],dx

These should be:
0000000F 6C ins [vb],dx
00000010 6D ins [vw],dx
00000011 666D ins [vd],dx
00000013 6C ins es:[vb],dx

Hjwasm –c –bin –Sg –Fl inout.asm

Regression Fix #2

These should generate: Error A2049: Invalid instruction operands
vblendvpd xmm0, xmm1, xmm2
vblendvpd xmm0, xmm1, m128
vblendvpd ymm0, ymm1, ymm2
vblendvpd ymm0, ymm1, m256
but dont (there should be 4 operands).

These should generate: Error A2209: Syntax error: , xmm1
vmaskmovps m128, xmm0
vmaskmovps m256, ymm0
vmaskmovpd xmm0, xmm1

Breakpoints on SSE/AVX instructions

Add additional / corrected debug information to object output to allow breakpoints to be set on source code lines which are SSE/AVX instructions from inside Visual Studio (or other debugger).

AVX512 misassembly

vpsllvd	zmm15, zmm13, zmm7

assembles as

vpsllvd	zmm15, zmm13, zmm15

MAN GITIGNORE

Guys, you are missing the basics of git.

How can we port your changes to JWasm if 99% of your's changes is updating of compiler generated object files.

Add a gitter chat room

Create a gitter.im room and display gitter badge on readme.md - useful for discussions and it integrates with github and you can reference issues and commits directly in chat which shows as links back to repo for the issue/commit/pull request/comments

x64dbg uses one, https://github.com/x64dbg/x64dbg

Here is x64dbg's gitter page: x64dbg gitter

Users can use a gitter desktop client (windows: http://update.gitter.im/win/latest - mac/linux also available) or web or mobile (iphone/android)

https://gitter.im/

ELF Dwarf debugging output

JMP over a RET with a custom epilogue is incorrect

;Strangely, forward JMP is correct but backward is not.

.386
.MODEL FLAT
.CODE

Proc1 PROC NEAR
test eax,eax; 85 C0
JNZ @@over ; 75 06 -ok
test eax,eax; 85 C0
JNZ @@ret ; 75 00 -ok
@@ret:
CLC ; F8
RET ; C3

@@over:
test eax,eax ; 85 C0
JNZ @@ret; 75 FA -ok
test eax,eax ; 85 C0
JNZ @@ret; 75 F6 -ok
Proc1 ENDP

TestEpilogue MACRO procname, flag, parmbytes, localbytes, reglist, userparms
CLC
RET
ENDM

OPTION EPILOGUE:TestEpilogue

Proc2 PROC NEAR
test eax,eax ; 85 C0
JZ @@over; 74 06 - ok
test eax,eax ; 85 C0
JNZ @@ret; 75 00 - ok

@@ret: RET; F8 C3; epilogue ok

@@over:
test eax,eax ; 85 C0
JNZ @@ret ; 75 FE - wrong - makes infinite loop
test eax,eax ; 85 C0
JNZ @@ret; 75 FE - wrong
Proc2 ENDP
END

Open Watcom build warnings

Warning! W1027: file assume.obj(K:\HJWASM\SRC\assume.c): redefinition of _broadflags ignored
Warning! W1027: file assume.obj(K:\HJWASM\SRC\assume.c): redefinition of _decoflags ignored

A2168 error

Running hjwasm 2.28 on a 64-bit linux system (32-bit Windows version still crashes rather than displaying error messages), I get a rather unhelpful error message:

Error A2168: General Failure

Command line:
./hjwasm -archAVX -DX86_64 -DWINDOWS64 -DARCH=FMA3 yr4dwpn.asm

Source code:
https://www.dropbox.com/s/b5mptuq6hxs3es6/hjbug.tgz?dl=0

The Windows 32-bit debug version you built for me was not helpful in tracking down the Windows crash bug. MSVC 2005 won't attach to the crashed executable. I do not have a newer MSVC version.

Add Mach-O output type

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html

https://www.objc.io/issues/6-build-tools/mach-o-executables/

Add .SWITCH .CASE HLL directives

HIGHWORD bug

mov eax,HIGHWORD 80000000h appears to be leaving the top half of eax signed with 0xffff... this is wrong.

No Debug Register Support

invalid instruction operands when using dr0 - dr7

.while hll not producing a label for .endw in symbols

.while !(eax || edx) && ecx
nop
.endw

Add support for VECTORCALL calling convention

Available from VS2013 onwards,
supports passing of XMMWORD, YMMWORD, ZMMWORD types through registers like fastcall.

Minor AVX512 issue

vmovdqa zmm1, ZMMWORD PTR abc

does not assemble, but

vmovdqa zmm1, YMMWORD PTR abc

does

Support for Delphi Register caling convention

In 32-bit the Borland/Delphi Register calling convention (this is the default calling convention in Delphi) passes the firsts 3 parameters in registers EAX, EDX and ECX, in this order. Remaining parameters follow the stdcall convention.
I believe this is not a complicated addition and will add significant value and differentiation to HJWASM.

Fix MACRO opattr for strings

oa = opattr arg
tmp$ CATSTR <TheArg=>, , < with opattr=>, %oa
% echo tmp$
; TheArg="a string" with opattr=36 ; HJWasm64
; TheArg="a string" with opattr=36 ; ML 10.0
ENDM

.code
start:
opax "a string" ; <<<<<<<<< 0 with ML, 36 with HJWasm
opax DWORD PTR [ebx]
opax -DWORD PTR [ebx] ; <<<< assembles fine with MASM
print "ok"
exit

end start

Another AVX2 assembly issue

Sorry to be a pain....

First the bugs:

vpsllq ymm11, ymm11, xmm0
vpsllq zmm11, zmm11, xmm0

is not assembling. The Intel manual and ML64 say this is OK.

ML64:
vpmuludq ymm8, ymm6, ymmword ptr [r11+520H] ; 392F _ C4 41 4D: F4. 83, 00000520
vpsrlq ymm9, ymm7, xmmword ptr [r11+2C0H] ; 3A13 _ C4 41 45: D3. 8B, 000002C0
HJWASM:
; Note: Prefix bit or byte has no meaning in this context
vpmuludq ymm8, ymm6, ymmword ptr [rbx+520H] ; 3930 _ C4 61 CD: F4. 83, 00000520
; Note: Prefix bit or byte has no meaning in this context
vpsrlq ymm9, ymm7, xmmword ptr [rbx+2C0H] ; 3A14 _ C4 61 C5: D3. 8B, 000002C0
Note that 'r11' turned into 'rbx'

ML64:
vptest ymm8, ymm6 ; 3FC2 _ C4 62 7D: 17. C6
HJWASM:
vptest ymm8, ymm14 ; 3FC7 _ C4 42 7D: 17. C6

Now some oddities:

ML64:
vpsrlq ymm9, ymm7, 3 ; 38B8 _ C5 B5: 73. D7, 03
HJWASM:
; Note: Prefix bit or byte has no meaning in this context
vpsrlq ymm9, ymm7, 3 ; 38B8 _ C4 E1 B5: 73. D7, 03
ML64 assembled this into one fewer byte.

System V AMD64 ABI Support

It would be awesome if Jwasm would support the calling convention used on 64-bit Linux and MacOSX:
System V AMD64 ABI convention: http://www.x86-64.org/documentation.html
My primary reason to use Jwasm is source code portability. So far I'm using Jwasm for Win32, Win64, Linux32 and OSX32, but the calling convention for Linux64/OSX64 is so different from any of the supported calling conventions that implementing it via an invoke-macro is rather quirky.
Kind regards,
Terry

Add .ZMM directive

.zmm directive will allow the use of avx512 instructions and registers zmm(0) or xmm > 15

VPBROADCASTB not encoding correctly

vpbroadcastb xmm1, xmm2

Linux X 64 Shared Objects

I am attempting to compile Agner Fog's asmlib files with jwasm for usage in 64bit Linux.
I am having problems with the 64bit ELF format regarding the relocation section names.
When I compile my gnu asm and run readelf -a on the files, I see that I have Relocation section '.rela.text' and '.rela.data', but when using jwasm, I only get '.rel.text' and '.rel.data'.
When I attempt to link the object code to my other objects, I have relocation problems on the linkage. I feel like there need to be some patches to the elf.c code?
Can anybody help me with this, or tell me how I might go about fixing it without becoming an expert on the ELF format?
I also run into a bunch of R_X86_64_PC32 relocation errors stating that I need to recompile the code with -fPIC for some of the assembly files. I haven't figured out how to get around this one either. Typically, I code in straight GNU ASM and use %RIP relative offsets for functions/labels/vars, but this seems to be a little bit different in the MASM world. - any help would be appreciated.

Link
JROC
JROC
2010-10-30
I also wanted to mention that I think this assembler is pretty awesome.
AND.. I found that when compiled as a 64bit executable, it is broken.
On RedHat 5.5 x86_64, I had to modify the gcc unix make file to have -m32 for all the cflags to build jwasm such that it would produce usable results. I'm not quite sure what in the sources didn't work under the 64bit compilation. I didn't take the time to figure it out since I'm mainly focused on getting Agner Fog's library compiled under 64bit and working correctly.

Link
japheth
japheth
2010-10-31
When I attempt to link the object code to my other objects, I have relocation problems on the linkage. I feel like there need to be some patches to the elf.c code?
I'll need at least a test case to see those "relocation problems" myself

Link
JROC
JROC
2010-11-01
Ok, I've sent a tarball to what I am guessing is your source forge email address. Please let me if you receive it.
It's a test case of attempting to build a shared object file under x86_64 linux.
Thanks,
Eric

Link
japheth
japheth
2010-11-02
I received it.

Link
JROC
JROC
2010-11-02
great… - thanks.

Link
japheth
japheth
2010-11-03
I took a look.
There are 64-bit offsets in the assembly source, which make JWasm generate R_X86_64_64 relocations in .rel.data. This isn't compatible with PIC.
Generally, JWasm still lacks ELF-specific operators ( something like IMAGEREL/SECTIONREL for coff ) to support relocations which are to go into .rel.dyn and/or rel.plt. I guess, without such operators PIC code will be difficult to write with JWasm.
The small bug concerning forward references (memcpy64.asm.fails_with_jwasm) has been fixed.

Link
JROC
JROC
2010-11-03
thanks for taking a look and getting that other bug fixed.
am I correct to assume that 64bit PIC support will be well off into the future at this point?
For what it's worth, the nasm source code has what appears to be a fairly robust elf64.c file that might support the 64 bit PIC operations. That might be a good source for comparison.

Link
japheth
japheth
2010-11-03

am I correct to assume that 64bit PIC support will be well off into the future at this point?
this topic made me think about the priorities. Support for shared object should clearly have a higher priority than support for the dwarf debugging format.
That doesn't mean it will be implemented in 2 weeks. IMO the big problem with this issue is that currently there exists no convincing implementation of shared object support in current intel-based assemblers (NASM/YASM/FASM). It's all very low-level and error-prone - who has ever used this stuff?

Link
JROC
JROC
2010-11-03
Obviously, the intricacies of the object file formats are a bit over my head at the moment, but after this latest attempt to compile and link Agner's fast memcopy/memset routines they are starting to gain my attention.
The sad thing is, I never even heard of dwarf before until I started seeing it my compiled assembly dumps. I have been stripping all of the dwarf related stuff out of my assembly code, so as far as I know (naively speaking) I have no need for dwarf info at the moment.
I'll keep watching the forum to see how the progress is going. In the meantime, I'm hand converting the memcpy64.asm over to GAS format. I hope I can figure it out. I just started doing assembly hard core a month ago.

Link
JROC
JROC
2010-11-04
I ported the memcpy64.asm over to GAS assembly as PIC code (%rip relative) and it seems to be working fine.
If you are interested in having a copy of it to use in debugging of these problems, let me know and I will email it to you.

Link
drizz
drizz
2010-11-05
+1 for this feature and for lin64-abi-"invoke"
the way i understand it, it is impossible to call external functions with -elf64?
as a workaround you can compile to "-win64" and convert with objconv (Agner Fog)
jwasm -q -c -win64 -zcw -Fo $object $file
wine objconv.exe -felf64 -wd2005 -nu $object $object
// $object $file are code::blocks macros

Use OPTION EVEX to improve assembly times

More worrisome items

Using Nov 20th version.

1.  vpsraq	ymm15, ymm6, 63		; Create mask for each negative count
   

is reported as this by gdb disassembly:

vpsrad $0x3f,%ymm6,%ymm15

Note the "d" instead of "q"

2.  vpsraq	ymm15, ymm8, 63
   

is reported by gdb as "(bad)"

3.  vpandn	ymm14, ymm15, ymm14
   

is reported by gdb as "(bad)"

I'm using a fairly old binutils, so I've no idea where the problem lies. Program executes OK.

pextrw r32,mmxreg,imm8 is not recognized

.686
.XMM
.MODEL FLAT
.CODE
pinsrw mm0, eax, 0 ; 0F C4 C0 00; ok
pextrw eax, mm0, 0 ; Error A2049: Invalid instruction operands
; - should be 0F C5 C0 00

pextrw eax, xmm0, 0 ; 66 0F C5 C0 00; ok
pinsrw xmm0, eax, 0 ; 66 0F C4 C0 00; ok

Improper AVX512 code generation

This code:

vpand zmm2, zmm2, zmm0
vpmovmskb rcx, zmm2
sub rdx, rdx

Produces this in objconv disassembly:

?_236:; vpandd zmm2, zmm2, zmm0 ; 4CB3 _ 62 F1 6D 48: DB. D0
db 62H, 0F1H, 6DH, 48H, 0DBH, 0D0H
; Error: This instruction is not allowed in 64 bit mode
; Error: VEX.mmmm bits out of range
; Note: Prefix bit or byte has no meaning in this context
; Note: VEX prefix bits not allowed here
; Warning: MVEX prefix not allowed for this instruction
; Warning: MVEX prefix option bits not allowed here
; dec r8d ; 4CB9 _ 62 C4 F1 FD: 48
db 62H, 0C4H, 0F1H, 0FDH, 48H
; xlatb ; 4CBE _ D7
db 0D7H
; retf 11080 ; 4CBF _ CA, 2B48
db 0CAH, 48H, 2BH

Crash bug

Latest HJWAsm32 crashes. Download the zip file below. Run crash.bat. Sorry the zip file is so big, trimming it down to minimum size would be a bit tedious.

https://www.dropbox.com/s/08kf4qyssvq48yy/hjwasm_crash.zip?dl=0

Incorrect AVX2 assembly

I'm converting a large project from ML64 to HJWASM 2.15 dated Sept 14. Using objconv to disassemble the resulting object files produces numerous differences:

ML64 disassembled:
?_204: vpsrlq ymm3, ymm1, 3 ; 3878 _ C5 E5: 73. D1, 03
vpand ymm0, ymm3, ymm15 ; 387D _ C4 C1 65: DB. C7

HJWASM disassembled (registers reversed, scary error message):
?_204: vpsrlq ymm1, ymm3, 3 ; 3878 _ C5 F5: 73. D3, 03
; Note: Prefix bit or byte has no meaning in this context
vpand ymm0, ymm3, ymm15 ; 387D _ C4 C1 E5: DB. C7

ML64:
vpsrlq ymm9, ymm7, 3 ; 3899 _ C5 B5: 73. D7, 03

HJWASM (wrong register & scary message):
; Note: Prefix bit or byte has no meaning in this context
vpsrlq ymm9, ymm15, 3 ; 3899 _ C4 C1 B5: 73. D7, 03

vpaddq, vpmuludq instructions also generate scary error message

ML64:
vpxor ymm2, ymm2, ymm2 ; 3973 _ C5 ED: EF. D2
vpcmpeqq ymm3, ymm3, ymm2 ; 3977 _ C4 E2 65: 29. DA

HJWASM:
vpxor ymm2, ymm2, ymm2 ; 3974 _ C5 ED: EF. D2
; Note: Prefix bit or byte has no meaning in this context
; Note: Unknown opcode reserved for future extensions
; Note: VEX prefix bits not allowed here
UNDEFINED UNKNOWN REGISTER TYPE 3, ; 3978 _ C4 E3 E5: 1F. DA, 00

more examples of objconv error messages where ml64 output is complaint-free:
; Note: Prefix bit or byte has no meaning in this context
vmovsd xmm0, qword ptr [r11+0B0H] ; 0000000E _ C4 C1 FB: 10. 83, 000000B0
; Note: Prefix bit or byte has no meaning in this context
vmovapd ymm14, ymmword ptr [r11+780H] ; 00000040 _ C4 41 FD: 28. B3, 00000780
; Note: Prefix bit or byte has no meaning in this context
vaddpd ymm0, ymm8, ymm14 ; 000005E5 _ C4 C1 BD: 58. C6
; Note: Prefix bit or byte has no meaning in this context
vsubpd ymm4, ymm4, ymmword ptr [r11+500H] ; 00000218 _ C4 C1 DD: 5C. A3, 00000500

Request for gcc compatible output

One example is the instruction vaddpd ymm10, ymm10, ymm11. Output from objconv:

' vaddpd ymm10, ymm10, ymm11 ; 6ECC _ C4 41 Ad: 58. D3 ; Note: Prefix bit or byte has no meaning in this context`

Output from https://defuse.ca/online-x86-assembler.htm#disassembly2

0: c4 41 ad 58 (bad)
4: d3 .byte 0xd3

Knights Landing will execute this code correctly. However, debugging is a bit hard in gdb as disassembly is not possible.

One of my users is getting crashes on Piledriver. I don't have access to an AMD cpu so I do not know if the crash is due to encodings like the above or a bug in my code.

AVX-512 Broadcast troubles

vbroadcastsd zmm16, QWORD PTR ZMM_FMA_RND_CONST3

will not assemble.

Believe it or not, I do have working AVX-512 code so we are getting close to working out all the kinks that affect me.

Regarding the AMD trouble I was having, I eyeballed the code and found an AVX2 instruction in my FMA code path (Piledriver crash) and an SSE4 instruction in my SSE2 code path (K10 crash). Consequently, I believe the assembly that is not gcc compatible is not high priority. GDB users will want full compatibility for correct disassembly and ease of placing breakpoints.

Allow direct literal strings and floating point immediates in invoke

"" and L"" and 2.3f, 2.3 etc in invoke.

movq [mem],mmxreg emits incorrect opcode

movq mm0,[eax]; 0F 6F 00 ; ok
movq [eax],mm0; 0F 7E 00 ; wrong (it's movd, not movq), should be 0F 7F 00
movd mm0,[eax]; 0F 6E 00 ; ok
movd [eax],mm0; 0F 7E 00 ; ok
movd xmm0,[eax]; 66 0F 6E 00; ok
movd [eax],xmm0; 66 0F 7E 00; ok
movq xmm0,[eax]; F3 0F 7E 00; ok
movq [eax],mm0; 66 0F D6 00; ok

VEXTRACTF128 encoding

vextractf128 is swapping src and dest register numbers:

vextractf128 xmm10,ymm0,1
encodes as:
C4 63 7D 19 D0 01 vextractf128 xmm0,ymm10,1

Oodles of "Error A2014: invalid combination of opcode and operands" using 2.16

If I assemble mult.asm with these command line arguments (/c -Fl -Sf -Sa -Sg -coff), I get no errors. See file mult.no_errors.lst.

If I assemble mult.asm with these command line arguments (/c -Fl -coff), I get 3 errors. See mult.errors.lst.

mov ecx, [esp+4] ; Address of data struct to return info
Error A2014: invalid combination of opcode and operands
mov eax, OFFSET xjmptable ; SSE2 mersenne mod FFTs
Error A2014: invalid combination of opcode and operands
ret
Error A2014: invalid combination of opcode and operands

As always, MASM has no problems. The next source file to assemble (mult1.asm) has even more problems. Here is a link to the entire MASM code base: https://www.dropbox.com/s/rpkstsv1m1kj4bc/gwnum.zip?dl=0

C.bat starts the assembly process using a makefile called "compile". C64.bat does the same thing for 64-bit assembly. Enjoy, it will be a good test case!

GCC Debug Mode Warnings

GCC debug mode fixups:

reswords.c: In function ‘DumpResWords’:
reswords.c:1304:3: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
printf("\nitems in InstrTable[]: %u\n", sizeof(InstrTable) / sizeof(InstrTable[0]));
^
reswords.c:1306:5: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
sizeof(optable_idx) / sizeof(optable_idx[0]), INS_FIRST_1 + 1, sizeof(ResWordTable) / sizeof(ResWordTable[0]) - 1);
^
reswords.c:1306:5: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/safeseh.o safeseh.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/segment.o segment.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/simsegm.o simsegm.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/string.o string.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/symbols.o symbols.c
symbols.c: In function ‘DumpSymbol’:
symbols.c:807:5: warning: format ‘%p’ expects argument of type ‘void *’, but argument 5 has type ‘union ’ [-Wformat=]
printf( "%-12s %16" I64_SPEC "X %02X %8p %c %8p %s\n", type, value, sym->mem_type, dir->e, sym->ispublic ? 'X' : ' ', sym->name, sym->name );
^

Optimise INCBIN performance

Currently incbin of a 137kb file increases assembly time by about 5 seconds. This becomes exponentially worse as the file size increases.

opattr = 0 for immediate values with switch -Zne

AVX-512 assembly issue

This line is crashing on Knight's Landing (output is from objconv):

korw k5, k1, k2 ; 79A4 _ C5 F0: 45. EA

I wrote this gcc program:

int main () {
__asm__ volatile (\
"korw %k5, %k1, %k2\n\t");
}

and it works. Under gdb, the kor instruction compiled as:

c5 f4 45 d5

Would SSH access to a Linux Knight's Landing machine be of any use?

Windows 10 General Failure after creating obj file

Prefix bit or byte warnings

HJWASM produces different output than ml64, causing objconv to output messages like below (I can email the full objconv output if all examples are needed):

; Note: Prefix bit or byte has no meaning in this context
vpmuludq ymm10, ymm9, ymmword ptr [r11+560H] ; 3A73 _ C4 41 B5: F4. 93, 00000560

John says this should not be a problem, but....

I'm getting EXC_BAD_INSTRUCTION crashes on Mac OS X. Now, this could be caused by an incompatibility with objconv. My build process is to use HJWASM 32-bit on Windows. Then the object file is fed into objconv to create a Mach-O object file and finally linked on the Mac.

I have confirmed that the ML64 object file works in my build process and the HJWASM object file does not. I have not yet tried the HJWASM object file linked into a Windows executable.

Vex Encoding Issues

[code]
vpsllq xmm0, xmm1, xmm2
[/code]
This one is a BUG, the src/dst registers are being encoded the wrong way around.

[code]
C4E2FD190500000000 vbroadcastsd ymm0, m64
[/code]
The W bit of the 3 byte vex encoding SHOULD be 0 yielding 7D not FD as the 3rd byte... bug

VZEROALL incorrectly encoding as VZEROUPPER

0000000000402004 C5 FC 77 vzeroall
0000000000402007 C5 F8 77 vzeroupper

This is what the encoding should be.. so this is a BUG.
HJWASM is encoding vzeroall as vzeroupper

Option ZEROLOCALS

Possible feature: with the presence of this option LOCAL values decared in a PROC are automatically initialised to zero?

Statement assembles rather than raises error

Using the Nov. 18 version:

vpaddq	ymm1, YMM_INIT_SV23	

assembles, but should raise an error as only 2 arguments are supplied

HJWASM FOR DOS

Negative DWORD Ptr

Example:

include \masm32\include\masm32rt.inc

opax macro arg
Local oa, tmp$
oa = opattr arg
tmp$ CATSTR <TheArg=>, , < with opattr=>, %oa
% echo tmp$
ENDM

.code
start:
opax DWORD PTR [ebx]
opax -DWORD PTR [ebx] ; <<<< assembles fine with MASM
print "ok"
exit

end start

Back to AVX512 development

vmovdqu zmm14, ZMMWORD PTR [r14][rdx]

assembles as
vmovdqu32 (%rdx,%r14,1),%zmm14
according to gcc ... that looks right to me.

But,
vmovdqa ZMMWORD PTR [rdi][rdx], zmm14
assembles as:
vmovdqa32 %xmm14,(%rdx,%r15,1)
according to gcc.

Also, this
vpandn ymm14, ymm15, ymm14
assembles as:
(bad)
according to gcc. But it does execute properly.

Another AVX-512 issue

vfnmadd231pd zmm27, zmm24, zmm23

assembles as

    ` 62 02 BD 40: BC. DF`

which disssembles to:

    `vfnmadd231pd zmm27, zmm24, zmm31 `