64 bit assembler > UASM Assembler Development

UASM 2.56

(1/4) > >>


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)


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

Hi John
Thanks for all your work.  :thumbsup:


Hi John,


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

fvalue = 4 bytes


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

double_value = 8 bytes


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 )


    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.


[0] Message Index

[#] Next page

Go to full version