MASM on x64

[BogdanOntanu]

I agree with Eugen here:

I will never use an assembler that has no invoke or extended call syntax and .IF .ELSEIF .ELSE .ENDIF constructs included in the assembler. MACRO's and ARGs/USES/LOCAL are also very important.

The only thing i do not care much is .WHILE since i do my own loops ;)

Also the speed of compilation is very important for huge projects.

[Howard]

Kang Su

Thanks for giving us the opportunity for input. It's an honour!

I came from 8 bit ASM (CP/M) to 16 bit (MS-DOS) and then to C (& some ++) to speed things up. Being forced into the 32 bit Windows environment, I was overjoyed to stumble across MASM32 with this website, and especially to find, and get to grips with, INVOKE (coupled with PROTO). To me it gives the functionality of C but side-steps/simplifies  the Types issues. Thus I have since used INVOKE exclusively, (except for one Call/Ret it couldn't cope with).

I also got to grips with the @@: label syntax (with jmp @F or jmp @B etc.) and found that so excitingly simple that I increased it's application to @@0:  thru to @@9:  (with jmp @F7 or jmp @B1 etc.) in a XAssembler I wrote. It certainly saves inventing stupid label names for short skips, besides aiding reading code tremendously (you know immediately which direction to look, and approx. how far).

From there I progressed to exploring the use of .IF / .ELSEIF / .ELSE /.ENDIF and have found them so useful that I now rarely use anything else for decisions - it's ideal for the MessageCracker etc. (Also use .WHILE /.ENDW  & .REPEAT / .UNTIL from time to time.)
(I'm waiting for someone to write a utility - if I don't do it myself at some stage - to find matches, similar to the brace-finding feature in some C IDEs.)

The upshot of all of this is that to me now the INVOKE function is indispensable, while the others would be sorely missed.

Howard

[hutch--]

I will try and address a number of issues here. Firstly, the 32 bit versions available, 6.14, 6.15 and 7.00 are all very reliable so there is simply no reason NOT to use them where 32 bit code is required. I seriously doubt that anything new will happen in 32 bit Windoews so there is no real need to displace them with a later version.

With the architecture of win64 being different to win32, it would probably simplify the development for ML64 to only have to handle the win64 code. No legacy 16 bit code and no legacy 32 bit code, just the required capacity for 64 bit code. In development budget terms this would have to be a more attracive proposition by not duplicating existing capacity for the old stuff so the development team can concentrate on the dedicated capacity for win64.

In terms of priority of pseudo high level constructions, I would tend to place them in this order.

1. INVOKE  Critical for C/C++ programmer who are used to prototyping and who have little chance of writing bare mnemonic code.

2. .IF block syntax for sequential conditional testing. Nearly as critical for reliable higher level code.

3.  .WHILE / .REPEAT loop code syntax.  Useful but can generally be replaced with manual loop code.

One of the very useful things is the multiple conditional testing that exists in the current 32 bit versions for the block .IF syntax and the loop code system.

Code Select Expand


.if var == number || var < toplimit || var > lowlimit

It both simplifies the writing of this type of code and makes it more reliable in terms of results.

To summarise the suggestions.

(a)  Retain the 32 bit versions unmodified. They are proven performers.
(b)  Produce the 64 bit version free of legacy code. Simpler and lower development cost.

The more recent VC distributions are done on multiple CDs so the extra program should not be a consideration here in terms of size..

For the 64 bit version, retain the INVOKE syntax, it is far too useful to lose.
If it is possible, also retain the block .IF syntax as it makes many forms of more complex code reliable and maintainable.
If it is not a great technical burden in development costs, the loop code capacity has the advantage of using the complex conditional evaluation that the .IF block syntax has.

[Porkster]

I concur with you Hutch on your last wishes.

Let hope there aren't any complications between AMD and Intel CPU's.  If there is than it would be best to let AMD maintain their Meet-the-Standard position, rather than let multi standards ruin and complicate everything.

.

[drhowarddrfine]

I concur with you Hutch on your last wishes.

Is that what you want on your tombstone, hutch?

[hutch--]

Hey Doc,

I actually have ambitions of outlasting 512 bit Windows or its successor.  :bg

[kanggatl]

I'd like to thank EVERYONE for their feedback.  Due to several factors beyond my control, these feature may or may not make it into the final product.  But I can say that if it does, your feedback will have been a big part of it.

Again my thanks, and my hope to continue to work with the people on this forum (regardless of the outcome of these features).

Thanks!

Kang Su Gatlin
Visual C++ Program Manager
http://lab.msdn.microsoft.com/productfeedback/

[Porkster]

Thank you , Kang Su Gatlin.  by the way, I had just noticed you are from Microsoft.  I didn't realise.

Regarding MASM, you must admit that most features should be able to be retained as they already exist in the framework of the source and aren't a problem in the transition to Win64.  For "INVOKE' well it's very handy and it will most likely be rewarding if the hard work to keep it is done now as if not, many projects both official and home done will be delayed due to lack of convenience.
            
A good 64bit Assembler that suits Microsoft OS will only be a benefit for companies supporting drivers and advanced timing apps for Microsoft platforms.   Apple computers as an example have system product hardware standards which can add to their choice in timed application for science and research, etc.  If Microsoft don't support a good assembler then they will surely lose further support in these sectors of industry.

Please make your assembler powerful and usable.

Cheers.

.

[OceanJeff32]

I tend to agree with Hutch, but I also know how to do all these things in code.

I think Microsoft should include INVOKE and .IF etc directives.  But at the same time, I prefer C over C++ and I prefer pure assembly over macros.

I'm sure in the future, WHEN I BECOME MORE ADVANCED AS A PROGRAMMER, ESPECIALLY USING OTHER PEOPLE'S CODE, I will be more comfortable with C++ code, and all it's funky functionality. AND these macros under discussion here in MASM.

I do find it VERY CONVENIENT TO USE INVOKE to call the Windows API, as well as functions that I create, but I don't consider it mandatory... I do consider it mandatory if someone uses these macros, if you will, that they understand the code behind them.

Just one man's humble opinion,

Jeff C
:U

[pbrennick]

Kang Su Gatlin,
I, also, agree with Hutch on this one.  I remember years ago when the Macro Assembler first appeared that I was a pure mnemonic programmer and I disliked the macro capability.  This attitude continued until the advent of Windows forced me to take a different view.  This method of programming (macro assembly) makes writing Windows programs in assembly a more enjoyable task.  I think it is only us oldtimers who have any knowledge of programming before the Macro Assembler.  I started with Motorola using the D4 burner pack with the 6809e microprocessor, it did not even have a keyboard or a monitor and we had to write our own assembler.  For heavens sake, let's not walk backwards!  Microsoft has always provided the 'best in class' type of tools, I would hate to see the end of this superb track record.

Paul

[Bieb]

Apple makes for an excellent example of what could happen here.  There is no convenient and usable assembler for PPC, and look at how many people program for Macs.

[drhowarddrfine]

Couldn't you use nasm or as since it traces its roots to FreeBSD?

[mariø]

this threads makes me to think in the future (64bits plataforms) most used programming languages.
nowdays, a lot of people still develop with VB6, knowing that there is no update or support for it.
.NET isn't very accepted, and masm is for a minory like us.
I think C and C++ will have a very large lifetime, but my question is: what language will choose people that couldn't produce 64bits applications using VB?

[pbrennick]

Robert,
Actually, you are behind the times on this one.  Although, that was once a correct statement, it no longer is as Apple's free developer tools for MAC OS X contains the assembler.  However, as far as I am concerned, it is too little, too late and I will never go back.  Way back when during the beginnings of the MAC, assembler development tools or any other development tools were very restricted and difficult to get unless you were a licensed developer.  As a result of this very stupid plan, I migrated to Microsoft and I have never looked back.  I told them they can can the license, I did not want to be associated with them any longer.  Now Microsoft owns part of Apple, how funny is that?

Paul

[Bieb]

Okay, maybe it's possible in theory, but no one ever does, as it's far more complicated than x86.