Path: utzoo!attcan!uunet!lll-winken!lll-lcc!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: In-line assembly in Lattice C
Summary: Flame.  Hit 'n' now.  Go on.  I dare you!
Message-ID: <6361@well.UUCP>
Date: 24 Jun 88 05:14:21 GMT
References: <5841@bloom-beacon.MIT.EDU> <558@sas.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: The CIA:  Third-World Governments Destabilized While-U-Wait.
Lines: 69

In article <558@sas.UUCP> toebes@sas.UUCP (John Toebes) writes:
>Lattice C does not support in-line assembly.  It does however support builtin
>functions which generate inline code for many of the common C functions.
>For example:
>    strlen("abcdefg")
>Is reduced to a single move instruction of a constant value.
>
NOTE		NOTE		NOTE		NOTE		NOTE

	This is not an ad hominem (Oh dear, the A.H. word!) attack against
John.  Hell, I don't even have the faintest idea how to *begin* to write a
compiler, assembler, interpreter, or any such animal.  However, there seem
to be some distressing developments in the world of C which I do *not* like
(a few of which were addressed briefly in a Star Trek:TNG parody I posted to
rec.arts.startrek recently (plug, plug...)) and which I'd like to vent
spleen about.

flame {

	Still trying to save the stupid programmers from themselves, eh
John :-)?

	You realize, of course, that this kind of optimization falls flat on
its face if I somehow manage to change the contents of the memory that
contains "abcdefg".  I could stuff a \0 where the 'd' is, and the program
would not notice.  Further, the type returned by strlen() is not
*guaranteed* to be an int.  I could have written one that returns a short;
where would that leave you?  Or worse, I could write a function that's
simply *named* strlen(), but would have no other relation to the "real"
strlen() whatsoever.

	You further realize, of course, that no respectable programmer would
ever write:

	strlen ("abcdefg");

	But would instead use (if he really *had* to):

	sizeof ("abcdefg") - 1;

	If the code is written by d*psh*ts, it is *not* the responsibility
of the compiler vendor to save their butts.  Bloated code is, by and large,
the responsibility of the guy who *wrote* it.  And if the programmer in
question doesn't realize this, then s/he has no business writing code for
public consumption.

	However, we're all about to have Antsy-C shoved down our throats,
despite the fact that it is only marginally more useful than K&R.
'volatile' is a Good Thing.  Function prototypes are a Good Thing.  #pragma
is of questionable value (largely because no one has adequetely explained to
me what it *does*!).  Enforced parenthetical grouping whether or not it's
necessary is Stupid.  Making string constants read-only is Stupid.  Breaking
all the string functions and giving them cryptic names is Stupid.

	If K&R gets stampeded over by An-C, I'm gonna go pure assembler.  At
least they won't be able to screw *that* up.

} endflame;

	This flame brought to you by a graduate of the Richard Sexton School
for Antagonistic Behavior and Amateur Plumbing.		:-) :-) :-) :-) :-)

[Postscript:  As it happens, John is less than thrilled with An-C, and has
promised me that, despite what ANSI does, he'll try and keep the Lattice
compiler useful.  John is a Good Guy.]
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape  ihnp4!pacbell -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Hmm, you're right.  Air is made up of suspended meat loaf."  -- Josh Siegel