News:

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

Main Menu

UASM 2.56

Started by johnsa, October 04, 2022, 07:53:32 PM

Previous topic - Next topic

johnsa

Hey,

I'm busy working on the 2.56 release.. here is the list of changes for the upcoming version and status:

1. Replace ELFOSABI type from Linux to None (done)
2. Fix CodeView V8 (-Zi8) line numbers - this landed up requiring addition COFF fixups to be added to correctly get multiple files and their source lines to relocate properly and take into account section offsets. (done)
3. Update listing generation - this now includes generate prologue/epilogue code and fixes corruptions seen in the listing output for both win64 and elf64 (done)
4. Handling of constants that don't fit in 32bits - improved the detection/handling of these cases (done)
5. Made a change to Mach-O object output to include symbols that are public and marked as unused, in case they get used at link time - was causing a symbol table overrun error (done).
6. Add VNNI and Galois AVX512 instructions (done)
7. Fix a bug where a comment on a ret line can cause an offset issue (in progress - looks like it may be related to jmping to the RET from inside a switch stmt)
8. Remove redundant COFF relocations (done)
9. Fix some psuedo-instructions which don't correctly handle line comments like CLMUL.. (done)
10. Added warnings/errors for improper use of SHRX,SHLX,SARX (done)
11. Fix an issue with SYSTEMV ABI calls to Vararg functions via INVOKE, leading to an extra sub/add rsp pair and stack misalignment (done)
12. Prevent codegen from allowing VPBROADCASTb/w/d/q with a GPR register source, but add the new AVX512 special forms for D and Q that support R32 and R64 register sources. (done)
13. Fix RELA encoding in ELF64 (done)
14. Fix encoding issues for vpslld,vpsrld,vpsrad, etc when using register numbers > 7 (done)
15. Fix support for 16bit addressing with address size override when used in 32bit code (done)

John

jj2007

Thanks, John. Let us know when we can test it :thumbsup:

Biterider

Hi John
Thanks for all your work.  :thumbsup:

Biterider

LiaoMi

Hi John,

1.

HLL.c
atofloat(&opndx.fvalue, opndx.float_tok->string_ptr, opndx.mem_type == MT_REAL8 ? 8 : 4, opndx.negative, opndx.float_tok->floattype);

fvalue = 4 bytes

atofloat.c

84 .... *(double *)out = double_value; <= write 8 bytes

double_value = 8 bytes

2.

equate.c
myatoi128( tokenarray.string_ptr, &opnd.llvalue, tokenarray.numbase, tokenarray.itemlen );
&opnd.llvalue = u_int64

void myatoi128( const char *src, uint_64 dst[], int base, int size )

expreval.c

    dst[0] = 0;
    dst[1] = 0; <= write 16 bytes

johnsa

Yes, it's not the tidiest, but the additional space is there in the structure to support that oversized operations, so it's not "broken" or wrong as such, just not very logical.

jj2007

Quote from: johnsa on October 05, 2022, 07:13:14 PM
Yes, it's not the tidiest, but the additional space is there in the structure to support that oversized operations, so it's not "broken" or wrong as such, just not very logical.

Hi John,

Can you explain to us mere mortals what "oversized operations" are? Does it mean that UAsm inserts blank data after a structure?

MyRC1 RECT <>
... is there are extra bytes in between, I might have trouble sometimes ...
MyRC2 RECT <>

johnsa

No,

It's internal structures inside UASM (from JWASM unchanged) during the expression parser evaluation.

The structure has a float field, but the code writes a double there (etc). The structure has additional members after the float which are unused in the case that the expression struct is used in that way, so there is "space". It's just not great coding style to be writing doubles etc to float fields.

jj2007


johnsa

JJ, were you ever able to re-produce a test-case for the ret/jmp problem? I've not been able to recreate one to test it.

jj2007

Unfortunately not, John. Below a testbed that should trigger the problem, but it works just fine...

include \masm32\include\masm32rt.inc
MbEpilog MACRO procname, flags, argbytes, localbytes, reglist, userparms
  MbProUsed=0
  ifnb <reglist>
for reg, reglist ; uses
pop reg
endm
  endif
  if localbytes or argbytes
leave ; Set ESP to EBP, then pop EBP
  endif
  if flags and 10h
retn 0 ; C
  elseif argbytes
retn argbytes
  else
retn
  endif
ENDM
OPTION EPILOGUE:MbEpilog
.code
sometest proc arg1, arg2
Local l1, l2
  cmp arg1, 100
  je @F
  print "no jump", 13, 10
@@: ret
sometest endp

start:
  print chr$(13, 10, 10, 10, 10, 10, 10)
  invoke sometest, 111, 222
  invoke sometest, 100, 222
  exit

end start

johnsa

Ok not to worry, I will focus on the other label: ret issue that caused the jmp to be off.

Biterider

Hi John
Can you explain to us what you mean by
Quote4. Handling of constants that don't fit in 32bits - improved the detection/handling of these cases (done)

Are only the constants treated differently, or is the internal arithmetic improved as well?

Biterider

johnsa

It was an improvement to address this:

https://github.com/Terraspace/UASM/issues/173


Biterider

Hi John
Thanks for addressing this issue  :thumbsup:

Biterider

johnsa

AVX512 Galois field and VNNI instructions are in, also AVX forms AVX-VNNI and AVX-GF.

I've tried everything I can to recreate the 3byte jmp offset bug with a simple test-case, so-far no luck, tried in .if, .while, .switches, in proc, outside of proc, various locals, parms, nesting code lengths.. so far all work. May have to delay that one for another release when we can recreate it.

One more fix to go for RELA and 2.56 will be ready for final testing and release.