Notes about ML64 and h2incX includes and libraries

[HSE]

Hi Hutch!

About the only thing it inherited from ML.EXE was the ancient pre-processor which made it possible to civilise it enough to be able to write working code with.

ML64 is a tool maked for C/C++ people. Is very interesting that they see things from a totally opposite point of view: ML64 is exactly ML, except HLL flow control and invoke was removed.
We know that what was removed potentially can collide with compiler optimizations, there is no other reason.

Thanks for remind us your opinion, always consistent 

HSE

[Vortex]

Hi HSE,

We know that what was removed potentially can collide with compiler optimizations, there is no other reason.

I don't think that the main reason is the collisions with the compiler. Simply, M$ is trying to discourage people from using the assembly language. Their main product to sell is Visual Studio and not an assembler.

[TouEnMasm]

I don't think that the main reason is the collisions with the compiler. Simply, M$ is trying to discourage people from using the assembly language. Their main product to sell is Visual Studio and not an assembler.

I aggree with that

Is this a prototype ?

externdef __imp_SendMessageW:PPROC
SendMessageW equ <__imp_SendMessageW>
  IFDEF __UNICODE__
    SendMessage equ <__imp_SendMessageW>
  ENDIF

Just a call.

[hutch--]

The only real distinction between 32 bit ML and 64 bit ML64 is the target market. When ML was released in 1990, it was pointed at the consumer programming market. ML64 is necessary for assembler in 64 bit as CL does not support inline assembler. To do that it must be able to create object modules and with that capacity, it can produce executable code.

The capacities to emulate high level code is of no use to C/C++ programmers so it was never written into the 64 bit version, C/C++ code optimisation has nothing to do with the guts of an asm module and you can routinely write pure mnemonic code that will do the same thing as the emulated high level code. In needing to access an external asm module, there is nothing to collide, the asm code is self contained.

If you have used the 64 bit version for a long time, you will know that it is different from the 32 bit ML.

[hutch--]

> Just a call.

Yes, no need for something else that is useless, 64 bit MASM doed not use or need prototypes, you are confusing the 32 bit version and the Watcom derivatives.

[jj2007]

no need for something else that is useless, 64 bit MASM doed not use or need prototypes

And compilers that count and type check parameters are meant for idiots

MessageBox(FP4(1.0), "text", "title", MB_OK, "one more", "who cares", FP8(123.456))

[hutch--]

But no matter how hard you try, 64 bit MASM ignored prototypes. You can cobble together macros that ape prototypes but it makes the assembler really slow. Wishful thinking, a refusal to let go of the old stuff, incapacity to adapt, they are all part of the desire to attach something useless to an assembler that does not need them.

If you want strong prototypes and data types, use a C/C++ compiler and throw away all of the adevantages of a fast low level assembler. 

[jj2007]

You can cobble together macros that ape prototypes but it makes the assembler really slow.

Right, that could be a problem

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 timing your macros, not MASM. Without a cannon ball around its neck, MASM is fast. Not that it matters much, its the code speed that matters.

[TouEnMasm]

code speed is the same if there is no ..bug.
The one thing is that the code must exist.

This matches the linker libraries, pursuing 1990 prototypes is out of date junk with MASM in 64 bit

1990 calls and not protoypes are not enough to made code.
i have counted about 30000 prototypes in the SDK.Multiply your calls by 15 and you are on the good path.

[jj2007]

i have counted about 30000 prototypes in the SDK.

That's quite a lot. I arrive at about 21000, using the C:\TDM-GCC-64 SDK. Which one do you use? How do you deal with duplicates btw?

[TouEnMasm]

I only know the windows SDK 10.0.19041.0 + CRT.
Duplicate are in the onecore and it is possible that the real number is about 20000.
That is the Forum ML64  call multiply by 10.

[jj2007]

I made a quick test:

include \masm32\MasmBasic\MasmBasic.inc         ; download
  Init
  GetFiles \Masm32\include64\*.inc
  xor ecx, ecx
  For_ ct=0 To eax-1
        Print "+"
        add ecx, Count(FileRead$(Files$(ct)), "equ !<__imp_")
  Next
  Inkey Str$("\n%i imports found", ecx)
EndOfCode

Output: 69081 imports found 

Some look a bit odd (\Masm32\include64\mfc42u.inc):

Code: [Select]

externdef __imp_mfc42u_ordinal1000:PPROC
mfc42u_ordinal1000 equ <__imp_mfc42u_ordinal1000>

externdef __imp_mfc42u_ordinal1001:PPROC
mfc42u_ordinal1001 equ <__imp_mfc42u_ordinal1001>

externdef __imp_mfc42u_ordinal1002:PPROC
mfc42u_ordinal1002 equ <__imp_mfc42u_ordinal1002>

externdef __imp_mfc42u_ordinal1003:PPROC
mfc42u_ordinal1003 equ <__imp_mfc42u_ordinal1003>

externdef __imp_mfc42u_ordinal1004:PPROC
mfc42u_ordinal1004 equ <__imp_mfc42u_ordinal1004>

externdef __imp_mfc42u_ordinal1005:PPROC
mfc42u_ordinal1005 equ <__imp_mfc42u_ordinal1005>

externdef __imp_mfc42u_ordinal1006:PPROC
mfc42u_ordinal1006 equ <__imp_mfc42u_ordinal1006>

externdef __imp_mfc42u_ordinal1007:PPROC
mfc42u_ordinal1007 equ <__imp_mfc42u_ordinal1007>

I admit also that I don't quite understand the "no protos" thing:

Code: [Select]

extern __imp_MAPISendMail:PANYARGS
MAPISendMail TEXTEQU <__imp_MAPISendMail>
...
extern __imp_BMAPISendMail:PANYARGS
BMAPISendMail TEXTEQU <__imp_BMAPISendMail>

[hutch--]

> 1990 calls and not protoypes are not enough to made code.

Yves,

I think you have missed something here as I know you are not a native English speaker.

In 1990 Microsoft released MASM version 6.0 and with it, the technique for prototyping procedure calls. It did the job for folks who needed a high level layer for the then 16 bit assembler. Current 32 bit ML still uses prototypes IF you choose to use "invoke" with procedure calls. You can write lower level assembler with standard push/call notation in 32 bit with NO PROTOTYPES.

My comments on 1990 techniques has nothing to do with code generation, it has to do with an additional high level layer imposed on MASM to make it easier for high level programmers to understand it.

There are a number of other assemblers that don't use ML style prototypes, FASM, GAS among others. The Watcom derivatives aped 32 bit MASM starting from JWASM but Microsoft built the 64 bit version of MASM without the capacity to use prototypes.

[TouEnMasm]

Output: 69081 imports found         ....Wo says more ?

1990 must be a manual work.
With automatised procedures ,20000 can be done in a few minutes,perhaps less.