ASM vs HLL

[cottrell at nbs-vms.ARPA]

[eat me]
/*

I got bitten by the line eater, so I'll post this again...

> > >	For the bare language, I might agree. However, any macro programmer
> > >worth the name after a year or so will have developed a set of macros
> > >that enable high level constructs but still allow precise control of
> > >the machine. I personally have a set of macros that give me more
> > 
> > AAAARGH!!!!!  One of the most common complaints I hear from those
> > who must maintain code is that the programmer had developed his own
> > personal language out of macros.  THIS DOESN'T MAKE CODE EASIER
> > TO MAINTAIN, IT MAKES IT FAR, FAR, HARDER.
> 
> Case in point:  ever tried to work on the Bourne shell code?  It helps to
> know a little of the syntax of ALGOL 68.  Of course, not even the mighty
> cpp can transform C into ALGOL 68, so what you get is a unique language.
> That's the problem with these sets of macros mentioned by >>: each one is a
> different language with different characteristics (and bugs).  A compiler
> is just a clever macro-processor for a specific set of macros, with the
> macros usually optimized so that they're expanded by inline code instead of
> interpretively.
> -- 
> Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
>    ...Keep your day job 'til your night job pays.

I hate to disagree with a fellow deadhead but...

That's part of programming. What do you think the macro capability
is there for? Macros are merely inline subroutines. Are you saying
we should not use ban 'JSR' instructions too? The net effect is that
we have to look elsewhere to see what is happening. The Bourne Shell
code is nontrivial anyway. I support some of Bourne's macros as an
attempt to fix C (yes I can criticize it) to require an explicit END
statement for IF, FOR, WHILE, SWITCH, & DO. I find this model more
robust than the 'next statement' construct, which can bite you by
matching else's with the wrong if, and require addition of braces
when adding the second statement to a clause. In practice, tho, I
rarely get hurt by this, and a sufficiently paranoid hacker can
always use the braces.

> Furthermore, developing macros can make an assembler look more 
> structured and introduce some higher-level concepts, but it normally
> makes the code produced LESS good than hand coding.

If that is true, how can a compiler produce better code than by hand?
High level languages are in a sense complex macros. Anyway, your code
is probably I/O bound. 

"Going where the climate suits my CODE"

*/