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.52

Started by johnsa, April 03, 2021, 03:12:03 AM

Previous topic - Next topic

johnsa

Repo and binaries are up, give it a try.


Biterider

Hi johnsa
Seems to work fine here.  :thumbsup:

Biterider

LiaoMi

Quote from: johnsa on April 03, 2021, 03:12:03 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

Quote from: johnsa on April 03, 2021, 03:12:03 AM
Repo and binaries are up, give it a try.

OK for my major sources :thumbsup:

johnsa

Quote from: LiaoMi on April 03, 2021, 03:47:23 AM
Quote from: johnsa on April 03, 2021, 03:12:03 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:


LiaoMi

Quote from: johnsa on April 03, 2021, 07:08:36 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

#7
deleted

johnsa


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

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

#10
deleted

johnsa

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

Quote from: TouEnMasm 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
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

Quote from: tenkey on April 09, 2021, 12:17:05 AM
Quote from: TouEnMasm 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
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

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.
The uasmlib