A switch macro

[Robert Collins]

At the below link I found a reference to a macro. I tried using it in one of my projects but the assembler complains. Is it an invalid macro for MASM or am I just using it incorrectly?

http://www.madwizard.org/snippets/viewSnippet.php?s_ID=81

Code Select Expand


  '
  '
  '
  '
start:

       mov eax, 255         
     
      ;   
      ; Just an example
      ;
      .switch eax
        .case 250
          ;do something
          .break

        .case 255
          ;do something
          .break

        .default
          ;do something
     .endswitch

end start


[donkey]

Hi,

The code on Thomas's site and specifically QvasiModo's stuff is all for MASM so it should work. I think you will also find that macro in the MASM32 macro.asm file or whatever it's called. Not being a MASM user, and even less of a macro user I am not too familiar with it but from my understanding and the quality of QvasiModo's work in general I believe it works as documented. Just to note that QvasiModo is an excellent coder who I have collaborated with on a few things and he is generally very cautious and meticulous, I would be surprised if he released something that was not thoroughly tested.

BTW .break is reserved in MASM, in QvasiModo's macro it appears on a quick perusal that you have to use .breakdef

[Robert Collins]

Actually I just copied the code as shown at the web site and placed it in a file then included that file in my project. I get assembly errors just on the included file. I don't have to actually use the macro. I wont argue with you about his quality of work but I will get an error even if I write a macro that starts with a period.

.mymacro MACRO
    ;do something
ENDM

will generate an assembler error for the name 'mymacro'

[donkey]

Can't help you too much there Robert, it is far too MASM specific for me, also not being a big fan of macros (everyone knows my general opinion of them) I have never investigated their limitations. In MASM however I believe you must use OPTION DOTNAME
to enable names beginning with a "."

[Robert Collins]

Well you may not like macros but you solved the problem. Using option dotname did the trick.

Thanks, donkey

[hutch--]

Sounds like a lot of hard work for nothing, the MASM32 project has Greg Falen's switch macro and it is very reliable. Have just added Michael Webster's switch$ macro for string comparison and its reliable as well.

[Robert Collins]

I just like playing around and trying anything and evrything even if I don't have any immediate use for some of them. I like to experiment with all variations of almost anything I see. It wasn't so much that it was .switch macro but more so that it was a dot-something and this aroused my curiosity. I have a feeling as time goes on you are going to see that I will post a ying-yang of questions of all sorts even if they really serve no practical purpose just because I have that uncontrollable want to know about me.

[donkey]

Well you may not like macros but you solved the problem. Using option dotname did the trick.

Thanks, donkey

No problem Robert,

[personal opinion]
I just don't like anything that obfuscates or hides the actual code, after all we chose assembler to get away from that stuff. Getting some macro to write your code is the same as relying on a compiler to do it. Also making assembly more like C just seems self defeating to me, if you want C use C, if you want assembler use mnemonics :)
[/personal opinion]

[hutch--]

 :bg

They all learn over time.  :toothy

[Robert Collins]

I just don't like anything that obfuscates or hides the actual code, after all we chose assembler to get away from that stuff. Getting some macro to write your code is the same as relying on a compiler to do it. Also making assembly more like C just seems self defeating to me, if you want C use C, if you want assembler use mnemonics :)

When I first got a job in an Assembler shop I had exactly the same attitude about macros as you do. So, when my boss gave me my first assignment I was determined to write all the mnemonics myself bypassing all macros possible. Well, the program worked and I was content. Then as time went on I did this more and more until I got to the point that it just became second nature to me to write the actual code rather than to use macros. Then one day the computer department upgraded their OS. Well, every application had to be re-compilied for the new OS. Oh yes, mine re-compilied without any errors. But later all hell broke loose. Almost everyone of the programs that I had done came crashing down. My boss was very concerned about this and so decided to take a look at my writings. Man, he was pissed. He called me into his office and really laid it down on me. Never, he said, ever write any programs without using the macros. When you use macros and later change upward to a different OS or a different model macros are also updated with the new OS. When you re-compile your code the assembler guarantees that it will insert the upgraded macro and that macro guarantees that the inserted code will perform correctly. The absolute machine code that I used instead of using macros did not work on the new OS.

This is the way it is in the business. If you are completely on your own and your programs will never be used except for yourself then more power to you if this is your style of programming. All of this MASM stuff that I am learning is for me and also the company I work for. Even when I write programs only for me I still use macros mainly because I am more interested in solving for the problem and not so much now something works within the structure of a macro. Also, I use macros because I tend to write ying-yang of programs and I become somewhat layback about it and if there is a function or a macro that will do it for me then I take advantage of it.

Oh well, your way is fine in your own world of programming.

[donkey]

Hi Robert,

I would tend to agree if macros were used in that context, however they are not meant to nor are they normally used in that way. For example the switch macro is not something that is OS dependant at all, it is simply a cascading compare block. What I believe you are talking about is the interface to the OS which is handled (usually) procedurally, for example a change to the registers that must be preserved or to the message pump. That is something I take great care with, breaking my programs down into small manageable procedures that are self contained, if they change the way it's done then I rewrite a small procedure. I also tend to use libraries of procedures that when upgraded will recompile nicely for any changes to the OS. A macro on the other hand is not used for that purpose at all, it generally, though not exclusively, replaces critical code such as compare blocks or loops and almost always does it badly because it tries to generalize at the worst possible place.

There are some macros that I have little or no problem with, those that are intrinsic such as invoke, because I know exactly what it will do (not the MASM invoke which is the worst of all with LEA etc...). But most I try to avoid like the plague, they introduce bugs into code that are hard to track down and even harder to correct without affecting the entire app and perhaps others. For example 9 out of 10 apps might work just fine with a macro but there is a duplicate label in another, you change the label in the macro and the one with a problem works but now the other 9 have problems. Instead of debugging one app, you're now doing 10. This is perhaps a nonsensical example but it is only to make a point, I don't need to be reminded that you can just change the label in the app with a problem.

Finally, assembler is by it's very nature platform specific and is not portable though I must say that some have tried and failed miserably at making it so. Writing a portable x86 Win32 program is an oxymoron, if it is x86 Win32 then that's what it is, it will not recompile and run on Linux, HLL's can do this to a certain degree but they generally lose alot of power in doing so.

Personally, I write as a hobby, I don't program for a living or even work in IT for that matter. I just like assembly language, and it is the only language I know so I don't pine for high level constructs. However I do hate it when programmers send me source to look at and I have to unravel 100's of macros just to find the problem, it is almost always the way some macro unrolls in a specific context.

[Robert Collins]

Actually, that was the main reason my programs failed was due to me writing absolute code that had a direct interface into the OS. You have a very good point about other such macros (ie switch). I have to agree with you about what you say about programmers sending you the source to look at and then having to unravel 100's of macros just to find the problem. That can be a real headache. I look at other people's code all day long and I can honestly say that 98% of problems I find are never within the macros embedded within their code. It usually turns out that most programmers where I work are more educated in the use of system macros than they are in the mneumonics of the language. When the problems do occur at the macro level it is mainly because the programmer mis-used the macro and of course it generated the incorrect code. However, I can usually spot errors in macro usage quicker than I can spot errors in their source code. I guess in my case I was just pretty much bound to the standards of using macros I just got so use to it that I don't give second thought to writing my own 'switch' logic when I know there is a macro already available for me to use.  Even if I wanted too I don't think I can avoid using macros (in the business world) because I have to adhere to 'standards' and other people will also be looking at my code. Whenever I write any application I have to take into account that the guy accross the isle, who may not be up to par yet, may have a very difficult time understanding what I have done if I don't keep my code as simple and clean as possible. In the environment in which I write programs, macros are 'clean', they make the code more readable, reduce errors, and keeps your stuff consistant with the rest of the applications. It is very common for many programmers to be working on the same project and each programmer, although allowed to express their talents, still have to have a 'common' orthadox way and from the company's point of view macros are definitly one way to keep your code in line with the other people's code. Companies can be very strict about how you write your programs. You don't have that problem. You are free to write your programs as you see fit and that is your advantage over me.

[hutch--]

I draw the distinction on the basis of what code type it is and with 32 bit Windows code written in assembler, you have both high level code and low level code and there is no reason to have to write them the same way.

A fairly large amount of Windows code is hack OS interface code that is not smart or different or subject to optimisation so there is little reason to spend any more time getting it up and going than is necessary.

The asumption that code needs in any sense to be even across an application does not take into account the old rule that 10% of the code does the work and the remaining 90% does very little. The percentages may vary a little but not by very much but it does establish a priority for where the work needs to be done and what you get back for it. Beautifully hand crafted MessageBox code may be a work of art but it works no better than one spat out with a macro and it does not end up any smaller or faster.

This is much the comment for any API based code, write it so you can understand it and safely maintain it and put your work where it matters where you may have either speed critical code or massive complexity to deal with. Clean simple to read and maintain code survives where messy complicated code is ignored by most people as they don't understand it and probably cannot be bothered trying to learn it.

What you get with a poweful macro system is the capacity to design your own language and this is in fact a very advanced capacity where you can tune the language you use in a way that makes it a lot more productive in development terms and if you get it right, you get very good code generation as well as fast development time.