Author Topic: UASM 2.52  (Read 283 times)

johnsa

  • Member
  • ****
  • Posts: 838
    • Uasm
UASM 2.52
« on: April 03, 2021, 03:12:03 AM »
Repo and binaries are up, give it a try.


Biterider

  • Member
  • ****
  • Posts: 670
  • ObjAsm Developer
    • ObjAsm
Re: UASM 2.52
« Reply #1 on: April 03, 2021, 03:38:54 AM »
Hi johnsa
Seems to work fine here.  :thumbsup:

Biterider

LiaoMi

  • Member
  • ****
  • Posts: 797
Re: UASM 2.52
« Reply #2 on: April 03, 2021, 03:47:23 AM »
Repo and binaries are up, give it a try.

Hi John,

the archive with uasm252_x86 contains the old 2.51 version  :tongue:

jj2007

  • Member
  • *****
  • Posts: 11317
  • Assembler is fun ;-)
    • MasmBasic
Re: UASM 2.52
« Reply #3 on: April 03, 2021, 06:11:04 AM »
Repo and binaries are up, give it a try.

OK for my major sources :thumbsup:

johnsa

  • Member
  • ****
  • Posts: 838
    • Uasm
Re: UASM 2.52
« Reply #4 on: April 03, 2021, 07:06:30 AM »
Repo and binaries are up, give it a try.

Hi John,

the archive with uasm252_x86 contains the old 2.51 version  :tongue:

story of my life.. will update now.  :nie:

johnsa

  • Member
  • ****
  • Posts: 838
    • Uasm
Re: UASM 2.52
« Reply #5 on: April 03, 2021, 07:08:36 AM »
Should be sorted.

LiaoMi

  • Member
  • ****
  • Posts: 797
Re: UASM 2.52
« Reply #6 on: April 03, 2021, 08:02:04 AM »
Should be sorted.

The release 2.52 works flawlessly  :eusa_dance: :thup: :thup: :thup: :thup: Thanks for the work you've done!

P.S. UASM 2.51 1618 Views  :dazzled:

nidud

  • Member
  • *****
  • Posts: 2118
    • https://github.com/nidud/asmc
Re: UASM 2.52
« Reply #7 on: April 08, 2021, 04:51:30 PM »
Critical and important CV8 update here.

johnsa

  • Member
  • ****
  • Posts: 838
    • Uasm
Re: UASM 2.52
« Reply #8 on: April 08, 2021, 06:50:15 PM »

Nidud, thanks a million :)

I've been investigating another strange issue, proc parameters. The symbol offsets in RBP/RSP based frames is spot on and the debugger picks them up perfectly .. except when you have a leaf proc with no locals/invokes and thus no SUB RSP,x
Even though the RSP+ofs values are correct and present on the sym->offset VS seems to have them all shifted out by 8. It appears as if the VS debugger expects RSP to always be aligned 16, which in the case of the leaf proc I don't bother.

I'm debating whether the sub rsp,8 should always be mandatory to keep align-16 even when nothing in the proc would require it.

TouEnMasm

  • Member
  • *****
  • Posts: 1615
    • EditMasm
Re: UASM 2.52
« Reply #9 on: April 08, 2021, 07:16:42 PM »
Ok for me
Compiling the source code (vs2019),I get
Quote
Erreur   C2065   'LANG_REGCALL' : identificateur non déclaré   uasm   I:\UASM-master\x86macros.c   317   
The LANG_REGCALL refer to
Quote
enum lang_type {
    LANG_NONE       = 0,
    LANG_C          = 1,
    LANG_SYSCALL    = 2,
    LANG_STDCALL    = 3,
    LANG_PASCAL     = 4,
    LANG_FORTRAN    = 5,
    LANG_BASIC      = 6,
    LANG_FASTCALL   = 7,
    LANG_VECTORCALL = 8,
   LANG_SYSVCALL   = 9,
   LANG_DELPHICALL = 10
};
Fa is a musical note to play with CL

nidud

  • Member
  • *****
  • Posts: 2118
    • https://github.com/nidud/asmc
Re: UASM 2.52
« Reply #10 on: April 08, 2021, 07:38:13 PM »
Yes, it literally changes everything.

I'm debating whether the sub rsp,8 should always be mandatory to keep align-16 even when nothing in the proc would require it.

Maybe targeting the /Zi switch, adding some debug mode changes base on that.

I've added defines based on switches for header files, so maybe also define [_]DEBUG or something similar.

Architecture (_X86_, _AMD64_, _IA64_) and Machine Architectures (_M_IX86, _M_AMD64, _M_IA64) should probably also be defined by the assembler.

Currently Asmc defines _WIN64 but that should probably be defined in a header based on the above.

johnsa

  • Member
  • ****
  • Posts: 838
    • Uasm
Re: UASM 2.52
« Reply #11 on: April 08, 2021, 10:01:30 PM »
Agreed that's where my head was at.. if the user builds with /ZiN then we always keep the RSP aligned, don't optimize out the sub rsp.. I think that is the best solution.

tenkey

  • Regular Member
  • *
  • Posts: 30
Re: UASM 2.52
« Reply #12 on: April 09, 2021, 12:17:05 AM »
Ok for me
Compiling the source code (vs2019),I get
Quote
Erreur   C2065   'LANG_REGCALL' : identificateur non déclaré   uasm   I:\UASM-master\x86macros.c   317   
The LANG_REGCALL refer to
The archived VS2019 project files are not synchronized with the archived source files. You'll need to change the project information via VS2019.

I don't know the French for "Exclude from project", but you need to exclude x86macros.c and x86macros.h.

You can also exclude trmem.c and trmem.h, as TRMEM is not enabled by the archived project files. It needs to be updated to handle 64-bit pointers.

You also need to add pseudoFilter.c and pseudoFilter.h.

johnsa

  • Member
  • ****
  • Posts: 838
    • Uasm
Re: UASM 2.52
« Reply #13 on: April 09, 2021, 02:14:35 AM »
Ok for me
Compiling the source code (vs2019),I get
Quote
Erreur   C2065   'LANG_REGCALL' : identificateur non déclaré   uasm   I:\UASM-master\x86macros.c   317   
The LANG_REGCALL refer to
The archived VS2019 project files are not synchronized with the archived source files. You'll need to change the project information via VS2019.

I don't know the French for "Exclude from project", but you need to exclude x86macros.c and x86macros.h.

You can also exclude trmem.c and trmem.h, as TRMEM is not enabled by the archived project files. It needs to be updated to handle 64-bit pointers.

You also need to add pseudoFilter.c and pseudoFilter.h.

Are you talking about UASM or the derivative work? These files don't exist in UASM... hence my previous concern over confusion having different people building and release under the same name.

KradMoonRa

  • Member
  • **
  • Posts: 79
Re: UASM 2.52
« Reply #14 on: April 09, 2021, 07:56:31 AM »
x86macros better to remove, I have adopted remove all macros to .inc files to get better control off platform and arch environments definitions as also calling conventions.

I'm coming with a proposal for merge to an 2.53 with the x64 x32 platform conventions fix and the addition of regcall convention as also thiscall and experimental 32 bits vectorcall, and linux64 syscall.
And more tho add after test this is working.