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
Thanks, John. Let us know when we can test it :thumbsup:
Hi John
Thanks for all your work. :thumbsup:
Biterider
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
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.
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 <>
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.
Thanks :thup:
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.
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
Ok not to worry, I will focus on the other label: ret issue that caused the jmp to be off.
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
It was an improvement to address this:
https://github.com/Terraspace/UASM/issues/173
Hi John
Thanks for addressing this issue :thumbsup:
Biterider
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.
Quote from: johnsa on October 22, 2022, 06:07:36 AMI'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
Please, John, don't waste your precious time on this one. I know about the bug, and have a workaround. It's fine :thup:
Agreed, will keep it on the radar until we can find a good repro.