Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!hao!husc6!mit-eddie!ll-xn!ames!oliveb!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.lang.c Subject: Re: Inline assembler; a quiz (long; sorry) Message-ID: <478@winchester.UUCP> Date: Mon, 22-Jun-87 13:38:05 EDT Article-I.D.: winchest.478 Posted: Mon Jun 22 13:38:05 1987 Date-Received: Tue, 23-Jun-87 05:06:55 EDT References: <608@zen.UUCP> <2299@hoptoad.uucp> <21211@sun.uucp> <464@winchester.UUCP> <829@omepd> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 63 In article <829@omepd> jimv@omepd.UUCP (Jim Valerio) writes: >This is a paraphrase and clarification of some mail that I sent to John Mashey >which he urged me to post to the net. To summarize this discussion, it started with some mnetion of asms. I observed that asms got in the way of optimizers. Jim sent me a well-done note that said asms were OK, especially if done as they had done them. When apparently reasonable people disagree, it's often worth looking for deeper reasons to gain insight about the different conditions that lead to this. jim says: >When I say inline assembly language what I mean is not the the usage found, for >example, in 4.3bsd Unix, where an arbitrary string is randomly inserted between >C statements..... >In his mail to me, John argues that these 4 cases are less important to them >because in their implementation: > a) leaf procedures like these only have a 2-cycle overhead, > b) in most cases, features that cannot be gotten to from a high-level > language don't exist, > c) the compiler would need to know a great deal about the side effects, > and a function call automatically has the right effects. > >In our case, (c) is the same, (a) is nearly the same, and (b) is apparently >a legitimate difference. (I suspect that the true cost of leaf procedures >is more than 2 cycles here, when you count overhead due to i-cache misses, >software calling conventions required for separate linking, and whatever.) Not really, or at most 2+ a fraction. > >In conclusion (and despite the reasons John gives), I feel that the inline >assembly language function facility was well worth its implementation cost. Actually, I'd agree with Jim, for his environment. Note, however, that what he's talking about is REALLY a way to dynamically add something like code-generation templates to the compiler (not exactly, but much more like that than the typical asm statement). The deeper generalizations that I proposed are as follows: I think there is a spectrum of reasonable viewpoints, based on 3 things: a) Overall architecture: extremes are: A1: architecture has many features not easily generated directly by compilers A2: architecture has few such features b) Subroutine call speed [especially for minimal routines]: B1: very slow B2: very fast c) Compiler technology level C1: pcc or near-equivalent C2: all-out optimization technology (IBM's internal one for the RT PC), HP's, MIPS In general, the more of the "1" cases, the more likely that "asm", especially a good one of the type you've described, seems to be useful. The more of the "2" cases, the less interest people are likely to have, not because there are NO cases where it would be useful, but because it seems to be not worth the effort. Bottom line: I think both positions are reasonable; they just get there from different assumptions. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086