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
QuoteVisual 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.
Quote from: drhowarddrfine on February 28, 2005, 11:53:47 PM
<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.
Quote
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
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 :).
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.
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
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.
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
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
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.
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
Quote from: doomsday on March 01, 2005, 03:27:22 PM
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
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.
Quote from: hutch-- on March 01, 2005, 06:04:10 AMIt 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.
.
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?)
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:
QuoteIt 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
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.
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
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.
.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.
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.
.
QuoteI concur with you Hutch on your last wishes.
Is that what you want on your tombstone, hutch?
Hey Doc,
I actually have ambitions of outlasting 512 bit Windows or its successor. :bg
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/
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.
.
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
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
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.
Couldn't you use nasm or as since it traces its roots to FreeBSD?
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?
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
Okay, maybe it's possible in theory, but no one ever does, as it's far more complicated than x86.
Mario,
.NET is NOT a language. It is a collection of classes. You must use a programming language that works with the .net platform.
Quote from: drhowarddrfine on March 14, 2005, 07:18:16 PM
Mario,
.NET is NOT a language. It is a collection of classes. You must use a programming language that works with the .net platform.
yes, but with vb (and C#, if i'm not wrong) your are forced to use those classes (and distribute the 25Mb Framework). But I don't think that VB-->VB.net or C# will be the natural migration that people will choose.
Bieb,
Maybe because I started programming with the Motorola processsor family is the reason that I find, for me, that the reverse was actually true. I had a difficult time, for a short while, moving to the Z80, 8080, 8085 and 8086 (even the 8088). BTW: even though the Z80 is in the family, it is not an INTEL processor. It was developed by MOSTEK and then ZILOG (or is that backwards). Too many years ago! I don't think you even know about those days.
mariø,
Nicely stated.
Paul
Quote from: pbrennick on March 16, 2005, 05:00:09 PM
It was developed by MOSTEK and then ZILOG (or is that backwards). Too many years ago!
I think you have it in the right order. Zilog's web site (http://www.zilog.com/)
Thanks, FourB, it was a nice little processor and so was the 8085. I spent a good deal of my career programming that processor in a language called NumaLogic which I did not invent but made it function correctly and was responsible for all its development until the advent of the LM6 version of the language (which occurred after I had sold the rights to it and it spread everywhere. Most all programmable controllers (PCs, as they were known at the time, PCs today are something totally different) today are run using some version of that language. That is my claim to fame!
Paul
Loved the z80. Those days were good. Sinclair Spectrum 48K.
I loved the Apple II as well but only tinkered a little into the assemble side of it. I know that wasn't a Zilog based computer.
I remember in the 80's Zilog was about to introduce an advance Z80 called something like z20000 or something (not a product code.) It may have been the 16bit version. Never hit the market properly or some other CPU took over sales.
EDIT : Maybe I'm confusing it with the z80000. http://cpcoxygen.digi-alt.net/magazine/02/z80/z80.htm
.
Porkster,
Yes, the Apple 2E used the 6502 (a joy to program) and the Sinclair (TI-99) was a Texas Instrument processor (9900, I think).
Paul
Quote from: pbrennick on March 19, 2005, 01:40:37 PMSinclair (TI-99) was a Texas Instrument processor (9900, I think).
Hehheh, you obviously had a clone Spectrum. I think they released the Spectrum in the US under licence to Texas Instruments.
My problem in those days is I would always run out of memory or I would waste too much time making the perfect sound or scroll routine. My projects were too grand for the technology.
.
Porkster,
I think Zilog released the Z8000. I remember TI having the chip but locked it so it was not user programmable. I programmed the Z80 in my first computer, a Sinclair ZX81.
Porkster,
I know I am getting old and my memory is failing. :bdg But, having said that, I googled it. The TI-99/4A Home Computer used the TMS9900 16-bit processor, hope this helps.
Paul
Quote from: hutch-- on March 03, 2005, 12:10:32 AM
.....
I actually have ambitions of outlasting 512 bit Windows or its successor. :bg
I'm with you on that one! :wink
Scott
Wow, the only one of all those CPUs that sounded familiar was the Z80. I've got one in my calculator, and it was the first chip I ever tried to learn Assembly for (although I soon gave up, I might go back to it some day).