HJWasm 2.31 release

[johnsa]

2.31 version is up, packages on the site!

Changes:

Fixed a 32bit MS FASTCALL issue

Fixed encoding bug with VMOVQ.

Fixed VMOVSS/VMOVSD allowing 2 register form, when 3 registers are required for all-register mode and added error message for it.

Updated VECTORCALL, FASTCALL x64 to support 3 register VMOVSS/VMOVSD form if archAVX on, when generating PROC or INVOKE.

Optimised and improved FASTCALL handlers and completely redeveloped SYSTEMV calling convention implementation.

Fixed a potential memory corruption bug in the symbol table.

Added support for Intel MPX extensions, bnd0-3 registers and new instructions.

Added custom USES to OO Library method definitions

Added MEMALLOC and MEMFREE macros, which are now also used internally by the Macro Library.
These two macros will use HeapAlloc on Windows and malloc/free via libc on Linux/OSX.. making them portable.

Created two new Linux samples, Lin64_2 and Lin64_3 showing off the SystemV calling support as well as the portability of the OO and macro library.

Update oo1 sample as well to show the customisable USES clause.

Cheers!
John

[aw27]

Fixed encoding bug with VMOVQ.
Fixed VMOVSS/VMOVSD allowing 2 register form, when 3 registers are required for all-register mode and added error message for it.

Why this instruction "vcvtps2pd ymm0,ymm1" compiles in JWASM but  "Error A2049: Invalid instruction operands" in HJWASM/new name ?

[johnsa]

It should be

Code: [Select]


vcvtps2pd ymm0,xmm1


it expands 4 floats from an XMM to 4 doubles in YMM.
So that shouldn't work as it was.

OR you can use 2x XMM registers and it'll convert 2 floats only.

[aw27]

It should be

Code: [Select]


vcvtps2pd ymm0,xmm1


it expands 4 floats from an XMM to 4 doubles in YMM.
So that shouldn't work as it was.

OR you can use 2x XMM registers and it'll convert 2 floats only.

JWASM encodes vcvtps2pd ymm0,ymm1 to vcvtps2pd ymm0,xmm1, this is the reason it does not produce error.

[nidud]

deleted

[johnsa]

It should be

Code: [Select]


vcvtps2pd ymm0,xmm1


it expands 4 floats from an XMM to 4 doubles in YMM.
So that shouldn't work as it was.

OR you can use 2x XMM registers and it'll convert 2 floats only.

JWASM encodes vcvtps2pd ymm0,ymm1 to vcvtps2pd ymm0,xmm1, this is the reason it does not produce error.

Yep, but I think it's better to report the invalid instruction rather, so at least you know and can correct it. This was linked to a lot of other simd/avx instructions which jwasm didn't really check very well, some of which could have had some unintended side-effects like automatically assumimg xmm0 etc.

[habran]

Hi nidud,

Code: [Select]

   289:     invoke foo,L"Unicode"
00007ff6a4a612d6 48 8D 0D 83 2D 00 00             lea rcx, ptr [rip+0x2d83]  ;00007FF6A4A64060h
00007ff6a4a612dd E8 0E FE FF FF                   call 0x7ff6a4a610f0 

0x00007FF6A4A64060  55 00 6e 00 69 00 63 00 6f 00 64  U.n.i.c.o.d
0x00007FF6A4A6406B  00 65 00 00 00 55 6e 69 63 6f 64  .e...Unicod
0x00007FF6A4A64076  65 00 00 00 00 00 00 00 00 00 00  e..........

built-in macro library is available to x64 only because there are plenty of macros for 32 bit

Code: [Select]

/* Process our built-in macro library to make it available to the rest of the source (x64 only) */
if (Parse_Pass == PASS_1 && Options.nomlib == FALSE && ModuleInfo.defOfssize == USE64) {
unsigned  alist = ModuleInfo.list;
ModuleInfo.list = 0;
InitAutoMacros();
ModuleInfo.list = alist;
}



[johnsa]

So after some discussion with JJ2007 it appears that supporting string literals in invoke may create some unforseen compatibility issues.

for example:

Code: [Select]

invoke myFunc, "a"

traditionally would pass 'a' as a byte to the proc, same applies for "ab", "abcd" .. which are now being picked up as string literals.

What we do have still is support for using dw in the .data sections to create wide character string data and we have @CSTR, @WSTR built-in macros (in 64bit).

Option a) rollback the support for literal strings (keep the dw support and rely on using the macros).. for 32bit the classic CStr/WStr macros can be used which rely on the dw support too.
Option b) change the handling to only convert the quoted argument to a string literal if the procedure parameter's type is PTR.. however this might not play well with any existing function that doesn't use PTR but simply qword or dword as the argument type.

I'm inclined to go with option a but I'd like everyone's thoughts first.

EDIT: another option might be to introduce some new delimiter for the literals, will probably require tokenizer update but might be a better option ?
something like:

invoke myFunc, "a", {literal text}, 10      ; unicode
invoke myFunc, "b", <literal text>, 10     ; ascii

[nidud]

deleted

[jj2007]

Option a) rollback the support for literal strings (keep the dw support and rely on using the macros).. for 32bit the classic CStr/WStr macros can be used which rely on the dw support too.

While testing the new HJWasm release, I got an unexpected build error. Only by accident did I find this problem: I rarely use the explicit form je short label; and only because I used the "short", the assembler choked. With ten years of assembler experience, it took me several hours to find out what exactly had happened. The trick was in the end to copy the whole code section from Olly's disassembly, and to compare both versions in a kind of blink comparator. Then I finally saw that AsmC and ML pushed 55h while HJWasm pushed an offset, with a longer encoding that made the short jump exceed its limit.

This is not a minor incompatibility. This is a major recipe for disaster, for the introduction of bugs that are extremely difficult to chase. My bug, for example, did not cause any damage so far but only by sheer accident... and it might have created big problems at any moment in time.

P.S.: Please stick to HJWasm - not because of my name, I am just an active user, but both Japheth and John have invested a lot of effort; they deserve a little "J" ;)

Code: [Select]

invoke strchr,edi,"c"

Maybe an option or a switch?

Or a little extra?

Code: [Select]

invoke strchr, edi, $"This is a string"

But then, invoke strchr, edi, chr$("This is a string") has always been part of Masm32. Simple and unambiguous... same for Chr$(), of course.

[johnsa]

Code: [Select]


string   db 13,10,"hello, world.",13,10
wstring  dw "A wide string",0

    .code

main proc c

local dwWritten:dword
local hConsole:dword

invoke  GetStdHandle, STD_OUTPUT_HANDLE
mov     hConsole, eax

invoke  WriteConsoleA, hConsole, <ASCII\n\n>, 5, addr dwWritten, 0
invoke  WriteConsoleW, hConsole, {Unicode}, 7, addr dwWritten, 0
invoke WriteConsoleW, hConsole, addr wstring, 13, addr dwWritten, 0
invoke  WriteConsoleA, hConsole, addr string, sizeof string, addr dwWritten, 0


I have this working as an option ? Can't think offhand of anything this would interfere with historically? as the <> and {} are limited in scope to the context of the INVOKE parameters

[johnsa]

However that causes issues now when fed via a macro to invoke as the <> and {} are stripped out... hmm

[jj2007]

Really, there is no lack of options that do work without breaking existing code...

Code: [Select]

include \masm32\MasmBasic\MasmBasic.inc
.code
main proc c

local dwWritten:dword
local hConsole:dword

invoke  GetStdHandle, STD_OUTPUT_HANDLE
mov     hConsole, eax
invoke  WriteConsoleA, hConsole, cfm$("ASCII\n\n"), 9, addr dwWritten, 0
invoke  WriteConsoleW, hConsole, wChr$("Unicode "), 8, addr dwWritten, 0
lea ecx, dwWritten
invoke  WriteConsoleW, hConsole, uChr$("текст"), 5, ecx, 0
ret
main endp
  Init
  call main
EndOfCode

[nidud]

deleted

[nidud]

deleted