Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!sdcsvax!ucsdhub!esosun!seismo!uunet!munnari!jkjl
From: jkjl@munnari.oz (John Lim)
Newsgroups: comp.sys.mac
Subject: Re: The Mythical Man Month
Summary: Do we want less late products or buggier programs sooner ?
Message-ID: <2608@munnari.oz>
Date: 4 Dec 88 14:52:53 GMT
References: <6176@fluke.COM> <10330090@accuvax.nwu.edu>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 86

In article <10330090@accuvax.nwu.edu>, bob@accuvax.nwu.edu (Bob Hablutzel) writes:
> 
> Assembly language is _not_ inherently more complex. I program in assembler
> as my language of choice for two reasons: (1) I tend toward projects which
> either have to be very small, very fast, or very intimate with the operating
> system, and (2) I can understand better what is happening in a program I 
> write in Assembler. The problem is not inherent complexity, it's familiarity.
> 
> I will admit that one has to track register usage, and that this can sometimes
> be snarled. However, I cannot think of any other disadvantage of assembler, 
> provided you have a decent Macro based assembler. (MACRO on VMS and MPW
> Assembler both fit this bill).
> 
	
Here are some other advantages of *NOT* using assembler :
1. Team management is easier. It's harder for another person to understand
 what is going on.

2. Portability. You don't think the Mac is the ultimate computer, do you ? :-)

3. Goto-less programming. Less spaghetti-loops and more comprehensibility.
Yes, with MACROs you can avoid the spaghetti, but i find formating such a pain
in assembler. Try keeping track of begin-loop end-loop code without indentation.
Code-size tends to be so much bigger that you cant keep a whole procedure on
one page/screen, making comprehension more difficult (Try reading a procedure
that is 20 pages long, with while loops nested 3-4 deep in assembler !).

etc. Other reasons given below...

> The final difference here is that I am most comfortable with assembler, and
> therefore work fastest in it. Whenever I try to switch to Pascal, or any other
> high level language, I envision my code in assembler, and translate it to
> the high level language. I do not advocate assembler for everyone, but for
> me it is the language of choice; I am highly productive in it; and I wish
> people would stop maligning it.
> 
> I started this whole discussion ( I think :-)) when I said that compilers
> do not produce as efficient code as hand written assembly. To my mind, _every_
> piece of code should be as efficient as possible; anything else is simply
> wasting the users time. (Granted, a microsecond wasted is not a loss. But
> these things add up). If compilers truly did generate code as efficiently as

I think this is fallacious reasoning. I have programmed both in Assembler and
HLL Languages. Anything that slows the code by less than 1 tick (or
0.5 MIPs/60 = 8 333 instructions a tick) per second is unimportant. 
The user won't even notice the difference. And count the number of GetNextEvents
are called per second. Then you'll realize how much time is spent idling,
waiting for activity. A few microseconds adding up here and there make
virtually no difference when we are talking about the 'granularity' of a 
sixtieth of a second.

I think you are making too many assumptions about how people program. Most
programmers are interested in getting the job done, just like you and me.
But their projects are not small, o/s utility programs. How about Canvas,
PageMaker, etc. Can you write a 500-700K program in assembler in that
time schedule. 

I strongly object to your use of the word *_every_*. MF is extremely fast. 
Yet see how inefficient it is (disassemble it - i've had to to work out how
Moire interacted with it). It wastes 10-20 cycles per GetNextEvent setting
up and restoring A5 using a procedure when it could use INLINEs. Think it
makes a difference making it that much faster when you are worried how to
implement time-slicing using the PMMU without breaking Excel ? Huh !

> assemblers, why, tell me why, nearly everyone agrees that "For time critical
> or tight loops assembler should be used to optimize"

You said it : "_every_ piece of code". What the people here are on about is
speeding up that 1-5% of code that makes the user wait more than 1 tick between
GetNextEvents.

> 
> Tell me: What code is non-critical?
> 

95-99% of all code as I said above.

True code-optimization is important. But if you spend more than 5% of your
time trying to optimize, you're wasting your time unless the program is small.
I agree that for your programming, assembler may be ideal. But it aint always
the best, which seems to be the implications of your message.

Code-size is another critereon we could use. But I dont want to bring that
in as what i'm complaining about is your sweeping ideas about optimization.

	john lim