MASM on x64

[kanggatl]

Hi, as some here may know Microsoft is in the process of getting Beta2 ready for VS2005, and part of that is MASM for x64.  In porting MASM for x64 there has been some functionality that is not currently included and we're trying to prioritize which work items to get done.

Of particular interest recently (I know hutch knows about some of this  :wink ) how important is "INVOKE" for x64 MASM?  Is this something that you need for your apps going to 64bit or is it a "nice to have"?  Would you rank INVOKE as more or less important than the high-level control flow directives such as .WHILE, .IF, etc...? 

I'm trying to get a good feel on this from the developer community at large.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

[drhowarddrfine]

Visual C++ Program Manager

We have arrived. :U

I hardly ever read an assembly routine that does not use "invoke".  It's like asking how important is it to call functions in C++ as void main(void);

<rant>I'm wondering if Microsoft only considers assembly programming as small routines embedded in C code and everything else is for small processor embedded code (microwaves, refrigerators, etc.).  </rant>

Many of us write whole programs with no C++ code at all but treat "invoke" as a higher level construct, a helper if you will, for calling subroutines. 

The other directives are, I think, controversial.  I never use them while others consider them crucial because they make their code more readable.  Others think if you use them you might as well code in C.

[Randall Hyde]

<rant>I'm wondering if Microsoft only considers assembly programming as small routines embedded in C code and everything else is for small processor embedded code (microwaves, refrigerators, etc.).  </rant>

I'm quite sure that Microsoft only considers the way they internally use MASM when making decisions like this one.

Many of us write whole programs with no C++ code at all but treat "invoke" as a higher level construct, a helper if you will, for calling subroutines. 

The other directives are, I think, controversial.  I never use them while others consider them crucial because they make their code more readable.  Others think if you use them you might as well code in C.

Hardly controversial. As best I can tell, the percentage of MASM/TASM programs that use INVOKE is roughly the same as the percentage of MASM/TASM programs that use .if, .while, etc. The *vast* majority of MASM32 projects I've ever seen certainly use both.

Dropping either one would create problems for the MASM32 community (at least, for those who intend to go on to 64-bit assembly).

Cheers,
Randy Hyde

[rea]

Is interesting to say who is "more important", being them related to structured programming.


1) if you say is a way to decide what to support first (aka all the functionallity will be there only wait more than the next beta)? or
2) if you are questioning about support invoke but not  the others constructions or viceversa (not all will be supported and we need know what you care more about)?



If you ask me for the first question, I think that there will be more easy convert a file that has used a lot of push/call than try to modify the code for get the .while and the others. Because what? because there are diferent ways that people do the structured programming, personally I use a block of comparations like a (if/else/if), others use a cicle and a jump table and others that I even know, some ones put the comparasion first, others at the end and jump there the first time. The point is that normally calling can be done in only one way and because there is only one instruction you can easely detect and pheraphs make a app that can turn a secuence of push/call to a invoke statement (pheraphs not easely done, dont know).

If you ask: would you like that we first make invoke or the others? the answer remain in would you like to convert your files to when the next realease of masm is available.



If you are questioning the second one, then you are questioning to what make your writting more easy, because we will only suppor a set of the most important and usefull. And I dont know the answer, the only that I can say is that is only one statement versus a set of them in structured programming.



I will suguest support them all, because they are related (structure in programms more clear), but they dont depend on the others, you can delete a set of them and the structure of the programms will remain if the progammer know it.




For allow fast or easy (pheraphs Im wrong) upgrade I supose that if,while and the others are of more use. But invoke still nice :).

[manhattan]

I'd say INVOKE, then .IF, .WHILE, etc. I use HLL directives to write debugging macros. It's very hard to write a printf macro without INVOKE. The .IF directive is very useful to write an ASSERT macro for example.

As I already said, INVOKE is more needed in ml64 than in ml because of the more complicated calling convention. Ideally, ml64 should be backward compatible with ml (when it makes sense) and fully support the new 64-bit calling convention.

[Eugen]

Hi

I am using MASM for writing fairly complex commercial applications (mainly shareware games) and i consider critical to be able to use both invoke and if/else HLL constructs.
[rant]
I can not help myself saying this: i suffered very much from current "invoke" limitations, that will not allow me to:
- call functions defined later in the code
- use as a parameter -a variable or a structure member  that are defined later in the code - this one hurts more, because for previous problem i can use PROTO;
[/rant]

Anyway, without HLL constructions (especially IF/ELSE/ELSEIF/ENDIF) i will surely not use MASM anymore, cause i can not accept to be forced to create 10000 labels .

Thanks,
Eugen

[hutch--]

Kang Su Gatlin,

Welcome on board and thanks for your input. I will try and answer some of the questions that would be of use to a development team based on both using and supporting MASM for many years now.

PUSH / CALL syntax is relatively simple on win 32 using STDCALL but from the specs I have read recently for Win 64 the version of FASTCALL is somewhat more complicated and while the more experienced guys could manually write this type of code, it becomes and impass for people who have not been at assembler for many years. It appears that C/C++ compilers will not support inline assembler because it would mess up the internal optimisation so it will mean that more C/C++ programmers will need to use MASM to handle any assembler code they need and it is here that a properly designed INVOKE style syntax becomes critical to this range of users.

Particularly for C/C++ programmers who are used to prototyping and the reliability of size and parameter count checking, bare mnemonics are very unpalatable to them.

If you have the time to have a potter around the forum, you will see that many members are writing complete small working applications using 32 bit MASM and with the capacity in the 32 bit versions, they are able to treat MASM as a language in its own right rather than just as an appendage to other languages. The offshoot of this is an environment where very good library design is possible and there is a support / knowledge base to assist with critical performance issues.

This allows MASM to produce larger more coherant code blocks in library format that are directly useful with a VC program without having to chop back and forth to get the capacity.

The INVOKE syntax combined with the existing MACRO capacity were you can use the EXITM <value> is particularly useful as it allows very reliable code and the conenience of high level style notation.

Please feel free to ask whatever you need in here as there are many people who use MASM on a daily basis who are very interested in it being maintained as a very powerful tool.

[Tedd]

In an attempt to be objective (strangely out of character :lol), rough guesses on what I personally use, though I dare say others are similar..

invoke - LOTS
proc/endproc - lots
.IF/.ELSEIF/.ELSE - very often
LOCAL (allocation of local stack variables) - very often
.WHILE/.BREAK - sometimes

[WinCC]

I would really like to have INVOKE and .IF .WHILE etc. in ml64 as this would make the jump to 64 bit coding easier, I really hope that a big corporation like Microsoft can put some effort in this.

Regards WinCC

[pro3carp3]

I use invoke a lot.  I do not use the flow constructs at the moment but do see where I will have a need for them on future projects.  Removing these features would have a negative impact on my productivity.

[doomsday]

To side-step the issue slightly, if MASM-64 has sufficiently strong macro facilities then neither INVOKE nor high-level flow control directives are a necessity.  It's only if they're the only reasonable way to reliably achieve the desired effect that they become essential.

regards,
-Brent

[Randall Hyde]

To side-step the issue slightly, if MASM-64 has sufficiently strong macro facilities then neither INVOKE nor high-level flow control directives are a necessity.  It's only if they're the only reasonable way to reliably achieve the desired effect that they become essential.

regards,
-Brent

Be very careful what you wish for here :-)
The HLL control structures are more than simple macros. MASM actually does some minimal optimization that you wouldn't be able to achieve with a macro implementation. Also, parsing the types of boolean expressions that MASM allows, e.g.,

.if eax == ecx && ebx < edx || esi > edi
...
.endif

would be quite difficult.  Possible if they *really* improved their macro capabilities (say, to the point where HLA is at today), but still quite difficult.  And programs that used a *lot* of these macros would assemble quite slowly (we're talking about a set of *huge* macros here, with each macro invocation expanding to hundreds, or even thousands, of statements).
Cheers,
Randy Hyde

[Porkster]

Microsoft dev team has already stated they will most likely be leaving highlevel flow control constructs, like '.WHILE', due to popular demand.

The 'PROTO' may go if 'INVOKE' goes.

'INVOKE' is in question due to difficulties to cater for different states the OS will be in during operation.         

The problem is, when a coder makes a program they will have to make sure the INVOKE is using the current API calling convention, now this maybe a bag of problems.   Hopefully a program will announce to the OS a calling convention and stick to it, somehow.

It appears that C/C++ compilers will not support inline assembler because it would mess up the internal optimisation so it will mean that more C/C++ programmers will need to use MASM to handle any assembler code they need and it is here that a properly designed INVOKE style syntax becomes critical to this range of users.

Yep they are planning on no in-line raw code, but they are saying you can add raw coded routines or programs.

This is the times when I hate computing.  When you think everything is a linear learning curve, you find out it's exponential when new technology comes a crop.

There seems to be alot of round about ways to get 64bit CPU's going in Windows.  CPU's are becoming bogged down with too many features so as to retain compatibility.  They should have just killed off old 16bit mode and made a work around for booting machines.

.

[Bieb]

The two must haves for me are INVOKE and some sort of .IF.  I don't need full featured flow control structures, as I can usually deal with CMPs and conditional jumps, but there has to be a better way to deal with Windows messages and other very large logical structures, because at that point it just gets too complicated for just plain mnemonics.

I personally use MASM exclusively now for development, having recently converted from Visual Basic (pretty big jump, eh?)

[GregL]

Kang Su,

First of all, thanks for coming to this forum and asking, it is appreciated.

hutch-- pretty much said it the way I see it:

It appears that C/C++ compilers will not support inline assembler because it would mess up the internal optimisation so it will mean that more C/C++ programmers will need to use MASM to handle any assembler code they need and it is here that a properly designed INVOKE style syntax becomes critical to this range of users.

For performance-sensitive programs, writing code with MASM becomes more necessary than ever. I would think making it as easy to use as possible would be very important to Microsoft. PROTO and INVOKE are required for easily prototyping and calling procedures. Otherwise, it really gets to be a mess in my opinion.

Maybe there should be two different versions of MASM, one for 32-bit that is pretty much the way it is now and a version for 64-bit only.

PROTO / INVOKE are very important to me, as well as .IF. .WHILE and .LOOP would be next in importance. The others I don't use as often, but they are nice to have available.

Greg Lyon