Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!styx!nike!cad!ucbvax!decvax!decwrl!glacier!mips!mash From: mash@mips.UUCP Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <493@mips.UUCP> Date: Mon, 2-Jun-86 04:33:01 EDT Article-I.D.: mips.493 Posted: Mon Jun 2 04:33:01 1986 Date-Received: Wed, 4-Jun-86 07:31:31 EDT References: <989@dataioDataio.UUCP> <131@stracs.cs.strath.ac.uk> <2786@utcsri.UUCP> <250@myrias.UUCP> <1723@umcp-cs.UUCP> <3844@sun.uucp> Reply-To: mash@mips.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 45 In article <3844@sun.uucp> guy@sun.uucp (Guy Harris) writes: >...discussion why cpp functionality must be available... >So there are ways of doing it without "cpp" being a separate program, but >the important point is that it still isn't just a matter of hiding "cpp"s >functionality in the lexical analyzer. We've found it handy to use "cpp" as pre-pass to FORTRAN, PASCAL, C [of course] and assembler: greatly eases multi-language software work. > >> and I would either have to include the work `inline' (asm.sed for you 4.1 >> and 4.2 folks) does, or have a separate ccom and c2+as phase. > >Or borrow the idea AT&T-IS has been talking about (see the note on >"Assembler windows" in the article "The Evolution of C - Past and Future" in >the recent UNIX edition of the AT&T Bell Laboratories Technical Journal - >October 1984, Vol. 63 No. 8 Part 2), where the "asm" keyword is used >differently: > > ...description of asm f(arg1, arg2, ...) {...} > >This has the advantage that it makes it easier to drop into assembler when >you absolutely have to, and the disadvantage that it makes it easier to drop >into assembler when you *don't* have to. Although asm() can be very useful on occasion, it's a sad thing, and it just about wrecks the use of good optimizing compilers. Unless I recall incorrectly, there wasn't much of this in PDP-11 days, but it really got popular on machines with slow subroutine calls. From experience, I much prefer a good optimizing compiler on a machine with fast calls: the wish for "asm" drops away pretty quickly. This leads to another set of questions: real data would be appreciated: Who uses asm? On what machines? How much performance was it worth? Why did you use it? Structural reasons? (i.e., getting to privleged ops) Performance of small functions (i.e., spl?()) Other performance (like getting long moves inline). Did you use it inside the kernel, in libraries, or in application code? Have you ever been bitten by compiler changes wrecking the code? Do you have equivalent asm() code for 2 or more machines? -- -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