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