Ignore MASM and it will go away

[dsouza123]

Voted.  

Wouldn't have known about it if it wasn't posted in the Workshop.
Only later found the other thread in Soapbox, very rarely visit that forum.

I realized C/C++ was going to managed code compiling to IL Assembly code/binary
which then is translated by the runtime to native, but didn't know MASM was being
compromised/gutted.

How would device drivers and other performance critical code get written without a
fully functioning 64 bit MASM ?  
Also how would Windows 64 bit x86 programmers write code ?

Thank for making the community of MASM programmers aware of it !

[pro3carp3]

Voted 5

[Randall Hyde]

Voted.  

I realized C/C++ was going to managed code compiling to IL Assembly code/binary
which then is translated by the runtime to native, but didn't know MASM was being
compromised/gutted.

Well, not supporting INVOKE is hardly *gutting* MASM.  After all, you can still write macros that do much of what INVOKE does for you. True, it's a bit less convenient not to have INVOKE, but "gutted" is a bit strong here.  :bg

How would device drivers and other performance critical code get written without a
fully functioning 64 bit MASM ?  

Most device drivers are written completely in C, without a single line of assembly code. Those that do use assembly generally don't use the HLL control structures. And if you're writing performance-critical code, it's generally a good idea to skip the use of the HLL-like control structures, anyway. They tend to obscure code sequences that could be written in a faster manner. INVOKE, for example, obscures the fact that it wipes out the EAX register in certain cases.

Also how would Windows 64 bit x86 programmers write code ?

The lack of INVOKE/PROTO wouldn't stop them. A lot of 32-bit programmers might complain about the absence of these two facilities, but it's not the end of the world.  People would adapt, even if it meant a few people actually switched back to C/C++.

Thank for making the community of MASM programmers aware of it !

Yes. Although eliminating INVOKE/PROTO wouldn't be the end of the world, the truth is that Microsoft needs to *extend* MASM's feature set, not shrink it. Sure, a lot of redundancy could be cleaned up (e.g., why not drop "db", "dw", "dd", etc., and just go with "byte", "word", "dword", etc., when moving to 64 bits?), but by and large they shouldn't *remove* functionality that doesn't have an immediate replacement.

Some things they ought to consider adding:

1. classes and objects.
2. Name mangling for VC++ compatibility.
3. Better compile-time language string handling facilities
4. The ability to nest macros in a context-free fashion (like HLA, NASM, and FASM support).

Cheers,
Randy Hyde

[dsouza123]

Gutted is quite appropriate.
At first it was going to be the control flow directives .WHILE etc and INVOKE, PROTO
That would remove most of the high level features of MASM,
you may not mind because you wrote HLA to replace MASM,
HLA only uses MASM among other assemblers as a back end,
if use of MASM is dropped as a back end there are fewer assemblers to deal with.
You should remove the equivalent items from HLA to see how usefull it is,
and to make the learning curve steeper.

Taking the high level features out of MASM would make it worse than the other assemblers.
It currently is a feature rich, stable programming tool.
Removing features goes down the slippery slope until there is nothing left and it is discontiued.

Removing INVOKE makes it far easier to write buggy code.
It is like removing type checking from high level languages.

The programmers that will miss the features in the language the most
are the new and intermediate ones, if it is made hard enough only a few
experts will be able to use it.

Device drivers used to be written in assembly.

Using INVOKE would be used early on and later could be replaced by more optimized code.
Code doesn't start optimized on the first writing, it gradually gets there.

"People would adapt, even if it meant a few people actually switched back to C/C++."
If the solution is to quit programming in Windows Assembly for 64 bit x86, then that isn't a solution.

If they decided to remove control flow and prototypes and type checking from C/C++ there would be a rebellion.
Taking away features that make it easier to write readable, less buggy code is foolish.

It is good to see most of the people in this thread value MASM with a strong feature set,
and not a cut down version that would make it far more difficult to write Windows Assembly.

[rea]

INVOKE, for example, obscures the fact that it wipes out the EAX register in certain cases

In the way that is a macro, but the idea still nice, for example with goasm is that it hide the way that pass trought a substraction....


And I have considered such things for add, altought I really dont like to miss HLL language with structured programing I consider them a very diferent topic...

specially with the starters they even that have the while and functions hardly can write structured programming without know structure ;)....



The point in think that a HLL make you write structured programming is a way to force you to do it.... (hoping that you some day get the idea ;))






Like a extra thing Im thinking now that learn a HLL is a way of force your logic, because you normally learn the sintaxis and hope that you get the idea of the meaning of while/for/do/case/switch/foreach/..., but not the concepts that the HLL is bases or the tools that are used like the structured programming ie also included "packing" of instructions ala functions/files/functionality...

I have som friends that dosent get the idea of structure in the execution of instructions and the structure of the data... :), for example dosnt know for what they will use a "for" for traverse a array of structures.... they only use it if they have look ... and say is working, I hope some day things will be more clear :).

[Jimg]

Some things they ought to consider adding:

1. classes and objects.
2. Name mangling for VC++ compatibility.
3. Better compile-time language string handling facilities
4. The ability to nest macros in a context-free fashion (like HLA, NASM, and FASM support).

and multipass so forward references wouldn't require an otherwise worthless proto.

[Vortex]

After all, you can still write macros that do much of what INVOKE does for you.

That's right:

Code Select Expand


_invoke MACRO funcname:REQ,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20
local pos

    FOR arg,<p20,p19,p18,p17,p16,p15,p14,p13,p12,p11,p10,p9,p8,p7,p6,p5,p4,p3,p2,p1>

        IFNB <arg>
             pos=@InStr(1,arg,<ADDR>) OR @InStr(1,arg,<addr>) OR @InStr(1,arg,<Addr>)

             IF pos

                IF (OPATTR(@SubStr(arg,%pos+5))) EQ 98
                        lea eax,@SubStr(<arg>,%pos+5)
                        push eax
                ELSE
                        push OFFSET @SubStr(<arg>,%pos+5)
                ENDIF

             ELSE
                        push arg
             ENDIF
        ENDIF
    ENDM
call funcname
ENDM


[Porkster]

I think users here are misunderstanding the ramification of removing INVOKE.

I'm no expert as I have only briefly looked into the subject, but if I'm correct to say, it would be a nightmare trying to determine which mode win64 is in if the MASM compiler can't do that for you when building the final code.   Especially if the code works or is compatible with the different bit-plane/addressing modes of win64.

The result of taking out INVOKE would lead to MASM being used for small inline style code rather than large assembly program creation.  Users could try to remain retro but that would be the death of the community.  Coders that wanted to create large programs would be required to implement management code to work with win64 modes, which could be messy.

Microsoft needs to change MASM so that it can phrase the attributes of the INVOKE to suit the mode win64 is would/currently  be in.  The issue is, will they want to when they are promoting a intermediate language using world.  Do they have a need to cater for whole assembler type programming.

Just an opinion, and I maybe wrong.

.

[Randall Hyde]

Gutted is quite appropriate.

Because INVOKE and PROTO aren't supported? Come on now...  Even if MS removed *all* of the HLL control structures, I'd still claim it's not "gutted". After all, it can still do everything most of the other x86 assemblers can do (TASM and HLA excepted).

At first it was going to be the control flow directives .WHILE etc and INVOKE, PROTO

My remarks were strictly geared towards the absense of the INVOKE/PROTO, after the
announcement that the HLL control structures would be kept.

Even so, the assembler would hardly be "gutted", even if they were all removed.
Though assembly, and especially MASM, is enjoying a bit of a renaissance right now, especially because of the HLL features in MASM (and TASM/HLA), the bottom line is that the *vast* majority of serious assembly users program in a HLL like C and call assembly routines for critical code. Such serious users rarely take advantage of the HLL-like control structures; they could stick with C if they wanted to use those and their presence in their MASM code masks the reason for using assembly (high-performance code).

Granted, removing these features would discourage some people from writing complete apps in assembly, but that's such a *tiny* piece of the entire programming marketplace, that I doubt MS would serious care. They *do*, however, need to continue supporting MASM. Their own drivers and other code uses some MASM code (and some new code will continue to be written in assembly). Remember, HLL control structures were added to MASM when it was a commercial product. This was done for the benefit of assembly programmers who purchased the product (who at the time, btw, almost universally rejected those statements). Today, MASM isn't a commercial product and it is supported mainly for legacy and internal purposes at Microsoft.  I can easily understand why they'd not want to bother supporting the HLL control structures -- they don't use them and it's an expense they don't particularly care about (supporting those statements, that is).

That would remove most of the high level features of MASM,
you may not mind because you wrote HLA to replace MASM,
HLA only uses MASM among other assemblers as a back end,
if use of MASM is dropped as a back end there are fewer assemblers to deal with.

HLA issues aside, MASM 6 & 7 will continue to be available. They're not *removing* the HLL control structures from those languages. They're simply opting not to include them in the next version of MASM. Not a direction any of us would like to see the language go, but MS doesn't support MASM for our benefit.

You should remove the equivalent items from HLA to see how usefull it is,
and to make the learning curve steeper.

You see the difference, don't you?
HLA was designed for beginners (and advanced programmers who grow up with HLA). It's support is geared around that audience. MASM, OTOH, gets continued support because of the need to support legacy device drivers and new device drivers that require assembly language. Those programmers are not beginners. Steep learning curve isn't an issue. Indeed, one could argue that by *removing* features from the assembler that device driver authors don't use, MS is *reducing* the learning curve for the assembler.

Taking the high level features out of MASM would make it worse than the other assemblers.
It currently is a feature rich, stable programming tool.
Removing features goes down the slippery slope until there is nothing left and it is discontiued.

I hate to say "I told you so...." but this is exactly what *I've* been saying for years. Specially, although MS is committed to supporting MASM in order to preserve their legacy code and satisfy the needs of those few device driver authors who must use assembly, the fact that MASM is *not* a commercial product pretty much means that "support" for this product is going to wane over the years. That this kind of thing would eventually happen was pretty obvious to me in the late 1990s (I can't claim it was obvious when I first started writing HLA in 1996, MASM was still a commercial product back then, but when Microsoft stopped selling MASM I knew that I'd made the right choice to move forward with my own assembler).

Whether or not the HLL/INVOKE/PROTO battle is won or lost at this point is not all that relevant. The bottom line is that the MASM community has just gotten a *very* strong indication of the future support of MASM.

The good news, however, is that the MASM 6 and MASM 7 products work just fine. As long as MS continues to make them available, the fact that MASM 8 or 9 doesn't support the HLL control structures won't be an issue.  As for 64-bit assembly not supporting this stuff, it's not something to worry about. If history is any indication, 64-bit computing won't take off for another 10 years anyway.

Removing INVOKE makes it far easier to write buggy code.
It is like removing type checking from high level languages.

Well, at least they didn't remove type checking from MASM :-)
Seriously, though, you're making an argument for using HLLs and skipping the use of assembly.

The programmers that will miss the features in the language the most
are the new and intermediate ones, if it is made hard enough only a few
experts will be able to use it.

Uh, don't forget that the new and intermediate ones will have the option of using HLA (yep, a 64-bit version is planned). If they want to insist on sticking with HLL control structures once they master assembly, they can continue to use HLA. They won't be lost to assembly language 'cause MASM doesn't support such features.

Device drivers used to be written in assembly.

But rarely anymore. And what assembly does appear in drivers is mostly short little functions that get called from C. You don't need INVOKE and PROTO (or any of the HLL stuff) for that kind of code.

Using INVOKE would be used early on and later could be replaced by more optimized code.
Code doesn't start optimized on the first writing, it gradually gets there.

Irrelevant. If invoke is so important, and people can't live without it, they can always use HLA64, when it becomes available. Or they can write 32-bit code and stick with MASM.

"People would adapt, even if it meant a few people actually switched back to C/C++."
If the solution is to quit programming in Windows Assembly for 64 bit x86, then that isn't a solution.

If they decided to remove control flow and prototypes and type checking from C/C++ there would be a rebellion.
Taking away features that make it easier to write readable, less buggy code is foolish.

Perhaps some people would rebell. And switch to HLA64. You won't find me complaining :-).  The bottom line is that Microsoft doesn't owe the MASM32 community anything at this point. Most MASM32 users obtained MASM for free. And most of the MASM32 code that I've seen is *hardly* earth-shaking (mostly it's demo code) -- it's not going to sell OSes or make Microsoft any money.  And given the size of the assembly community, if *every* MASM32 programmer doing serious work switched to Linux tomorrow, I don't think it would have any impact whatsoever on Microsoft.

OTOH, adding those features to MASM64 has some very real cost (development and support) that Microsoft will definitely have to pay for.

It is good to see most of the people in this thread value MASM with a strong feature set,
and not a cut down version that would make it far more difficult to write Windows Assembly.

I agree. And I wish this initiative the best of luck. A more powerful MASM would encourage more people to program in assembly, even when more powerful tools such as HLA are available. However, I still argue that you're beginning to see the end of support for MASM, something I predicted over five years ago.  Voting for continued support *will* extend MASM's life a bit, but I hope that the wise people around here are seeing that this is probably the beginning of the end of support for MASM.
Cheers,
Randy Hyde

[dsouza123]

"And switch to HLA64."
If it didn't have one fatal flaw...  the backwards order of the parameters,
it would be an excellent alternative, the especially the pascal flavor, like my favorite HLL.

All the high level languages I've used and various assemblers always have dest, source 
having to unlearn it for one language is too much.

[hutch--]

I certainly agree with Randy that win 32 will be with us for a lot longer than many expect. 64 bit code affords advantage to a reasonably small target market, large databases and files larger than 4 gig which are possible in this context. Sopme specialised image programs will be able to take advantage of the > 4 gig addressing range. While 640k was an endless pain for application design, 4 gig is a long way off being too small with similar problems.

I knew a lot of guys who put there development time and support for IA-64 and it predictably turned out to be a lemon with too many technical problems and very poor performance in x86 emulation. It had some life in multiprocessor mainframes but x86-64 will replace it there as well. I know there is a free version of XP64 but I don'tknow if the OS design is stable yet in terms of its architecture.

As was the case with win 32, the tools were crap for 2 to 3 years after it was introduced and that was with popular support for win95 from the consumer market but it is doubtful that win64 will get the same blast that win95 did. Expect to see poor, crappy and limited tools for some years with win64. VB / .NET and VC .NET and MFC quality code leading the pack.

There is the hint around that the compiler guys at Microsoft would LIKE to go in the RISC design direction slopping registers around all over the place which would be unfortunate as x86-64 is a NICE architecture for good quality assembler programming with extra registers and the CISC instruction range choice. While CISC is harder work for compiler designers, its a blessing for assembler programming.

Now in relation to 64 bit MASM, lousy lead version have occurred in the past. The first 32 bit capable versions were "very ordinary" (6.11 variants) and it was not until the full 32 bit PE patchs came out that MASM was viable again. There was a version for winNT 3.5 (6.11c) that was a real crap heap that no-one bothered to use. Microsoft did the work about 2 years down the track and made the PE version and it has been a very successful tool ever since.

I doubt that the 64 bit version will be any different and it will be shaped by demand. When you have very capable 64 bit assemblers available already in NASM and YASM, unless Microsoft want to give away the bottom end of the market so that the GPL movement can successfully infiltrate the Windows platform at the low end, they will in fact maintain MASM both for their own internal use as well as ensuring their own customer base is not forced to use tools under the GPL licence.

I probably differ with Randy on his views of the future of HLA, I see HLA as a new monolith looming on the horizon which will create a market of its own and develop a user base that will support it but I don't see that it will ever displace MASM as they are different tools with different concepts behind them. If MASM was removed from the market it would mean a shift to C and other assemblers as few will give away this power on the basis of fashion.

[GregL]

I found this on MSDN about the Windows x64 Calling Convention, pretty interesting.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/64bitAMD_6ec00b51-bf75-41bf-8635-caa8653c8bd9.xml.asp

[Porkster]

I found this on MSDN about the Windows x64 Calling Convention, pretty interesting.

Yes it's the point I was making earlier but no one seemed to care about the post..  INVOKE would be a hassle to implement properly.  Not to mention the modes can change quickly in the OS between the IA-32e modes.

It maybe best to make INVOKE only usable in full 64bit mode, on the default calling convention.  Coders can use the old ML.exe to make 32bit API stuff.

(EDIT) Actually I post this as a http://lab.msdn.microsoft.com/ProductFeedback/ViewWorkaround.aspx?FeedbackID=FDBK21759#3

.

[hutch--]

Thanks Greg, interesting link. 4 GP registers reserved for parameter passing with any other pushed onto the stack. The general design seems to be crippled by RISC theory and additional complexity to handle the RISC ideas but where it is not needed, 64 bit x86 look like it should be fun stuff.

The comments on invoke are much as before, if they can support making conventional function style calls in the compilers, they can do it with invoke as well. What looks interesting is if you choose to use the stack in manual code, you end up with 4 more registers to play with in the code design so in your own procedures, you have a lot more registers to play with in intensive code.

It will depend on how API functions are implemented but if it fits tis RISC model, it will be the 1st 4 arguments in the 4 specified registers without being order sensitive and the rest on the stack which will be much like normal.

Code something like,

Code Select Expand


mov rax, val1
mov rcx, val2
mov rdx, val3 etc ....
push nxt1
push nxt2
push nxt3
call proc_address
mov retval, rax


[Porkster]

After reading the Product Feedback's on MSDN for ML64, it's clear Microsoft is putting the dagger into the assembly community.   ML64 is destine to be a mere assistance to larger program coding in high level languages.

MASM is a community that isn't purchasing packages nor are they helping intermediate languages to dominate.

Microsoft doesn't need a full fledge assembly compiler with high level constructs, anymore.

Lets hope the power in macro'ing and mode detection is still available in the final ML64 or we will be doomed to win32 compatibility mode or basic hard coding of assembly api's and other instruction flow.

.