Notes about ML64 and h2incX includes and libraries

[jj2007]

There are a number of other assemblers that don't use ML style prototypes, FASM, GAS among others.

Fascinating:

Code: [Select]

extern __imp_MAPISendMail:PANYARGS
You can just pass any args to SendMail! And it works, most of the time! No PROTOs! Why oh why do the so-called "professional" C/C++ coders waste their precious time with studying their stupid compilers' type error and/or arg count messages?

[hutch--]

> Why oh why do the so-called "professional" C/C++

Easy, they are writing C/C++.

Now here is a question, why oh why do you time your macros and blame it on MASM. Why oh why don't you impose the same macros on the Watcom derivatives.

Why oh why are you so desperately trying to find  the characteristics of a visual garbage generator when you could easily find something that could generate a 1 gig Hello World /

[jj2007]

Now here is a question, why oh why do you time your macros and blame it on MASM. Why oh why don't you impose the same macros on the Watcom derivatives.

I do.

Have you timed it with one of your "serious" 64-bit sources? I am curious. Unfortunately, I am still stuck with my 32-bit sources, for example, the 22+ kLines of the RichMasm editor:

Code: [Select]

ML 10.0 build all took 2185 ms
UAsm64 build all took 1688 ms
AsmC build all took 1259 ms

[hutch--]

 

So you are saying you use your version of invoke, not the native Watcom derivative invoke ?

[jj2007]

In 64-bit code, yes. But the timings above are obviously for 32-bit code.

[LiaoMi]

Hi LioMi!

  

Code: [Select]

Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: mcalc.asm
Microsoft (R) Incremental Linker Version 14.00.24213.1
Copyright (C) Microsoft Corporation.  All rights reserved.

 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 1000-D537

 Directorio de C:\masm32\examples64\mcalc

28/04/2021  08:55            27.265 mcalc.asm
28/04/2021  09:24                16 mcalc.bin
29/04/2021  12:59            32.768 mcalc.exe
11/10/2018  22:19               978 mcalc.inc
29/04/2021  12:59            24.267 mcalc.obj
               5 archivos         85.294 bytes
               0 dirs  374.203.731.968 bytes libres
Presione una tecla para continuar . . .
This is about ML64 and Biterider's includes (they are in ObjAsm SDK), not about UASM logic. Anyway I don't see problems using modified includes with UASM, just that NMHDR.code is very used in ObjAsm examples (but is because I changed the name in the structure).


I don't remember a problem with SHORT, perhaps is other translation.

In Hutch2.zip there is a macros64.asm. I think is Hutch original, but with 4 forced expansions of reparg. You can make a diff with your macros64.asm

If you have time, perhaps you can test the modifications to macros64.asm that are under study.

Hi HSE,

what has been said is true of course, but previously there was a question of compatibility. My trials did not always go smoothly, and I often had syntax problems. It would be nice to test on both versions at once, that's what I wanted to do, and where I ran into a lot of inconsistencies 

I will try new macros, there are two whole versions, your modification and an update from Hutch 

[hutch--]

Funny part is the calculator was an exercise in interface design, the arithmetic was simple SSE2, the rest was trying to make it look presentable. It came out OK but I have no doubt it could be done a lot better.

[HSE]

and where I ran into a lot of inconsistencies 

Others than those enumerated before?

I will try new macros, there are two whole versions, your modification and an update from Hutch 

Fantastic