rlcarr@athena.mit.edu (Rich Carreiro) (06/20/88)
In an earlier article, someone said that Lattice C supported in-line assembly. I have Lattice C 4.0 (and have applied both patches). I have never found anything in the manual about in-line assembly. Am I just missing something, or wass the earlier article hosed? If Lattice does support in-line assembly, please tell me what pre-processor directives invoke it. Thanks, ******************************************************************************* * Rich Carreiro "...and she's buying a stairway to heaven." * * rlcarr@athena.mit.edu - "Stairway to Heaven" by Led Zeppelin * *******************************************************************************
filip@alberta.UUCP (Don Filipchuk) (06/21/88)
Rich Carreiro writes : >In an earlier article, someone said that Lattice C supported in-line >assembly. I have Lattice C 4.0 (and have applied both patches). I have never Patches to Lattice 4.0 ? I have never heard of them. Are these patches by Lattice? If so, why haven't I heard of them ? (I am a registered owner, I would think that if something had to be fixed in the compiler that I would at least be notified that fixes were available) Don Filipchuk
toebes@sas.UUCP (John Toebes) (06/22/88)
In article <5841@bloom-beacon.MIT.EDU> rlcarr@athena.mit.edu (Rich Carreiro) writes: >In an earlier article, someone said that Lattice C supported in-line >assembly. >* Rich Carreiro "...and she's buying a stairway to heaven." * 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. /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
berry@hor-res.UUCP (No comment) (06/22/88)
In article <5841@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes: > In an earlier article, someone said that Lattice C supported in-line > assembly. I have Lattice C 4.0 (and have applied both patches). I have never I posted that one. I have MANX so I'm not sure about Lattice. I didn't find it in the manuals either but with some source from Matt Dillon (Dmouse). > ... Am I just missing > something, or wass the earlier article hosed? I can't remember the last time I was hosed... -- -Steve Berry- ...!bunny!hor-res!berry "Dare to be gorgeous and unique. But don't ever be cryptic or otherwise Unfathomable. Make it unforgettably great." Intuition Reference Manual, pg 231.
rlcarr@athena.mit.edu (Rich Carreiro) (06/22/88)
In article <256@cadomin.UUCP> filip@cadomin.UUCP (Don Filipchuk) writes: > Patches to Lattice 4.0 ? I have never heard of them. Are these > patches by Lattice? If so, why haven't I heard of them ? > (I am a registered owner, I would think that if something had > to be fixed in the compiler that I would at least be notified > that fixes were available) The patches are available via the Lattice BBS. They are called amfix400.arc and amfix401.arc. Instructions are available after de-arcing. I too never heard ANYTHING from Lattice about these. I heard of the first when Bryce posted an announcement to the net. I heard of a second when a friend told me he had dloaded it. So much for Lattice's customer support (are you listening John Toebes?). The patches also clarify and update the manual, which has some rather important errors. Also, it patches lc, BLINK, OML, maybe OMD (I don't remember), maybe LC1 and LC2, as well as a bunch of internal files such as some floating point routines and the stub routine and some memory transfer routines. I would advise that you get it. If you do not have a modem, call Lattice and I believe that they will send you the patches for a nominal charge, though I may be mistaken on that. ******************************************************************************* * Rich Carreiro "...and she's buying a stairway to heaven." * * rlcarr@athena.mit.edu - "Stairway to Heaven" by Led Zeppelin * *******************************************************************************
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (06/23/88)
In article <5866@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes: > In article <256@cadomin.UUCP> filip@cadomin.UUCP (Don Filipchuk) writes: > > (I am a registered owner, I would think that if something had > > to be fixed in the compiler that I would at least be notified > > that fixes were available) > I too never heard ANYTHING from Lattice about these. > I heard of the first when Bryce posted an announcement to the net. I > heard of a second when a friend told me he had dloaded it. So much > for Lattice's customer support (are you listening John Toebes?). Ever stop to think how much your compiler would cost if Lattice had to mail a notice of patches to every registered user? The manual advises you of the availability of the Lattice BBS. It says: "The LBBS is available 24 hours a day and contains: o General information on Lattice products. o Program patches which you can down-load to eliminate bugs located after your product was released. o Notification of new releases on our Current Revision List. o Other special information and programs for the serious user." I think that's excellent support. It's better than most companies provide. Before I figured out how to use the LBBS I wrote Lattice about a problem I was having. They called me on the telephone, answered my question, explained how to use the BBS, and mailed me a version of the compiler with the latest patch applied. How many other companies do you know of that provide customer support that good? By the way, I'm very happy with the C compiler, too. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (06/24/88)
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
peter@sugar.UUCP (Peter da Silva) (06/25/88)
In article <6361@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: [ no self-respecting programmer would write ] > strlen ("abcdefg"); > But would instead use (if he really *had* to): > sizeof ("abcdefg") - 1; Once upon a time, getting a library working for the Small 'C' compiler, I wrote: #define prints(s) write(1, s, strlen(s)) prints("abcdefg"); Of course, this was *not* a situation where performance was important. > If the code is written by d*psh*ts, it is *not* the responsibility > of the compiler vendor to save their butts. When you have hundreds of programmers working on a system, some of them (maybe most of them) are going to be dopshots. > 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. You know, I really don't disagree with any of this stuff... I just think that there is *no* construct that's so loony that it's not going to be useful sometime. For example, see Ken Arnold's character-to-printable-string macro that I think was in an early version of curses.h. I can't remember it exactly, but it's got stuff in it like: #define ctrl(c) \ (((c)<' ')?("^"[1]=(c)+'@',""[-2]):(((c)>'~')?"^?":(""[0]=(c),""[-1]))) It actually generated "M-^X" as well. I think you can see how it works. ANSI definitely breaks *this* one. > 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. See discussions of optimising RISC assemblers in comp.arch. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
doug-merritt@cup.portal.com (06/28/88)
>there is *no* construct that's so loony that it's not going to be useful >sometime. For example, see Ken Arnold's character-to-printable-string macro >that I think was in an early version of curses.h. I can't remember it exactly, >but it's got stuff in it like: > >#define ctrl(c) \ > (((c)<' ')?("^"[1]=(c)+'@',""[-2]):(((c)>'~')?"^?":(""[0]=(c),""[-1]))) Thank you for the appreciation :-), that monstrosity was my invention. Ken was saying how you couldn't do it as a macro without side-effects nor a global variable, and I just had to come up with a counter example. We both thought it was brain damaged, but hey, it did the job...I wasn't aware that it actually got released, though. Nor that anyone but Ken (and a few of my friends I showed it to for laughs) had ever seen it. It worked on many different types of machines, but clearly it could get broken by a compiler that layed out string constants in memory differently than usual. I've never seen such a compiler, but I'm sure they exist...any machine where there's a difference between a "packed" string and an "unpacked" string would run into trouble (possibly a DEC 10/20, for instance). I'd been meaning to submit it as a obfuscated-C entry but I never got around to it. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
dave@dms3b1.UUCP (Dave Hanna) (06/29/88)
In article <6361@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > 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 > 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. Now wait a minute, Leo. Let me say that I have nothing but respect for you and the work you've done, but that argument is no more valid than saying that the compiler is broken because it can't guarantee the validity of the code it generates for "i = 1;" because I might modify the memory location that contains the constant 1. You can break it if you try hard enough, but a compiler has to be able to assume that a constant is going to stay a constant, and "abcdefg" is a string constant. (As a post script, I once spent the better part of a week debugging a program for a guy that swore our FORTRAN compiler was busted. In fact, he had found a way to modify the constant 0!) > Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ Dave Hanna -- Dave Hanna, Daltech MicroSystems | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |