Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!iuvax!watmath!watcgl!bmacintyre From: bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) Newsgroups: comp.sys.amiga Subject: Re: To macro, or not to macro? (LONG) ... a programming style. Message-ID: <10197@watcgl.waterloo.edu> Date: 8 Jun 89 14:28:37 GMT References: <2454@van-bc.UUCP> <19191@cup.portal.com> Reply-To: bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) Organization: UofW Computer Graphics Lab Lines: 140 In article <19191@cup.portal.com> stephan@cup.portal.com (Stephen Derek Schaem) writes: >I will try to show some point that make me fell that way about macro, It's not > just idea but *experience*... I certainly hope you aren't implying that the rest of the people discussing this don't have experience. It's not a good way to jump into a discussion. _I_ have *experience* in assembler and I _totally_ and _completely_ dissagree with you. Absolutely. But, anyway ... >1) Macro more or less readable? >2) Macro used for library call: >3) Macro = sub: >4)The point make with CLR, CLEAR, ClearData: You essentially repeated the same arguments four times, that you feel that macros make the code harder to read, mostly because people will not trust them, so they have to look at them all the time. - if you can't tell what it does by it's name, rename it. That is the point of higher level primitives such as macros. - if you do not trust the macros you are using, why are you using them? One of the main reasons for macros is that you can do something tricky or potentially easy to screw up ONCE and not worry about it. All the little examples give so far are pointless. There are ALWAYS special cases when it is better to do something straight, without a macro. But if you are repeating the same 4 instructions over and over, doesn't that tell you something? >5) Optimizing code: Are you talking about optimizing code after it works or before? If you are talking about after, by all means, tweek it to your hearts content. If you are talking about _before_ or while you are writing it, I am reminded of a comment someone posted a while ago about the difference between computer scientists and hackers ... Get it working first ... slowly. Who cares? Then optimize. Macros are great for making it easy to do things CORRECTLY, if not efficiently. You complain about reloading a6 during a libcall? SO WHAT!!! IF ( and I emphasize the _IF_ ) that call happens to be in a part of the program that is chewing a large percentage of the time, redo it. AFTER YOU FIND OUT! Please! Don't waste time optimizing stuff that isn't slowing down a program in a significant way. I am reminded of an organization that one of my employers told me about. They had a policy that any impovements/optimizations to their OS had to be run through a huge test suite and produce a noticable improvement in the execution of the code before they were officially added ... Anyway, enough preaching. It just annoys the hell out of me when people start globally condeming macros because they do things like reloading a register too much. >6)Xref or no Xref? Well I dont use a linker very often And I try to keep it >that way. Why? Religious issue? Do you have something against modularity?!?! Nevermind ... :-) >You you have to pass time >writing a good macro that will at the end (if you want full control) be as big >as a normal code. That's the point ... you don't _want_ FULL control! Why do you think higher level languages are so popular? Let the machine do the grunt work for you ... if you want to recode something over and over, fine. Don't try to say that this is a _superior_ style. It is your prefernce, fine. So do it. Be happy. It's you right! :-) > [ using macros that specify which register the lib base goes in ] >It's good if you use only a6, but when you have Dos or other >and have 3 library base used at the 'same' time you do extra work for 'nothing So why not write a better macro? What is the matter with a macro that has the following functionality: Call Blat [, parm1 [, parm2]] ( if not specified, parm1 is a6, parm2 is nothing ) - if parm1 is a?, us a? as the lib base ( ignore any parm2 ) - if parm1 is d? if parm2 is specified, parm2 must be a?, trans d? to a? and use it as the lib base otherwise, transfer it to a6 and use it as the lib base - if parm1 is a name if parm2 is specified, parm2 must be a?, trans name to a? and use it as the lib base otherwise, transfer it to a6 and use it as the lib base So, Call Blat means jsr Blat(a6) Call Blat,a5 means jsr Blat(a5) Call Blat,d5 means move.l d5,a6 jsr Blat(a6) Call Blat,DosBase,a3 means move.l DosBase,a3 jsr Blat(a3) etc ... What is the problem? >Question a preferences?: Maybe, But I can live easy EVEN better without macro. Sorry about your luck. >Well I saw to maybe people abusing macro... Well, I saw to maybe people abusing the english language ... what in the heck is The Portal System, anyway ... :-) As for "abusing macro", you already know my view on that. Macros make Assembler easier to understand, easier to write correct code quickly. I don't care about efficiency of coding when I first write code. I care about efficiency of algorithms and _correctness_ of algorithms and code. Optimization comes later, _if_ it is needed. If it ain't broke, for heaven's sake DON'T FIX IT! >Stephan Schaem: There isn't any toy I can't Break:-) I can see why! -- = Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} // = = now appearing at the Computer Graphics Lab, U of Waterloo! \X/ = = "There's nothing the matter with BR that a shot gun blast wouldn't fix" cge = = "It's not my fault, fatboy!" - Felder, pilot of TL Student Driver On Board =