🚀 go-pugleaf

> in article 476, landon dyer ({sun,lll-lcc,imagen}!atari!dyer) writes:

> Generally, assembly-language programs will run faster (and will
> be smaller) than compiler-generated code.  Depending on your
> machine's architecture, though, you may never want to program in
> its assembly language (e.g. IBM 801 and other RISCs).  Friendlier
> machines like the 68000 are another story.

i agree completely.  i've done a significant amount of development work
in assembly language on a macintosh (68k), and i didn't have any real
trouble coding "high-level" constructs.  sneaky c data structures like
linked lists and unions are no harder to create or understand in a
sufficiently rugged assembly language than they are in c.  most of the
stuff that would be really difficult (disk i/o, memory management, etc)
to implement repeatedly is supported by o/s calls (just like unix).

> 	Humans are perfectly capable of using those "wierd, high level"
> 	instructions that compiler writers claim are useless.  (Show me
> 	a 68000 C compiler that uses MOVEP, TAS or SNE!)

well spoken, landon.  one other point:  i think it's important for a human
to know that such instructions exist.  forget optimizers.  you'll write
better code if you understand your machine's instruction set.  every
assembly hacker knows the native integer size, byte ordering, and so forth,
for the machine he/she works on.  that's not true for every c programmer.

finally, development time probably *is* longer for assembly code, and
it's certainly non-portable.  on the other hand, when i want to write
a routine that sits on an digital input port and transforms incoming
data *instantly*, i'm not going to waste my time doing it in c.

					mike olson
					(...!ucbvax!blia!mao, i think)

all of my opinions have prior convictions, and are not to be trusted.