Xref: utzoo comp.arch:5910 comp.lang.misc:1744 comp.lang.c:11702 Path: utzoo!yunexus!geac!daveb From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.arch,comp.lang.misc,comp.lang.c Subject: Re: using (ugh! yetch!) assembler Message-ID: <3135@geac.UUCP> Date: 5 Aug 88 12:46:14 GMT Article-I.D.: geac.3135 References: <856@l.cc.purdue.edu> Followup-To: comp.lang.misc Organization: GEAC Computers, Toronto, CANADA Lines: 78 From article <856@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin): > But what do you recommend if your languages (C, FORTRAN, etc.) are > incapable of doing even a remotely reasonable job with the program? >... Now many (all that I have > seen, but I have been told that there are ones which do not have this problem) > C compilers will not allow asm instructions to use the compiler's knowledge of > which registers are assigned to which variables. There are two problems here: expressive power of the language and quality of the compiler/embedded-assembler interface. Problem 1: Language. Get a better language. No smileys here, its a serious suggestion. C may be my favorite language, but I won't claim it is either modern or consistently well-implemented. Use FORTRAN for numerical problems if C gets in the way, C for structure-shuffling if FORTRAN gets in the way. Use Ada or C++ if the non-extensibility of either gets in the way. Problem 2: Compilers. Get a good one, for whatever language you buy. Make sure it will use the machine's standard[1] call interface if one exists, so you can mix languages. An anecdote: I once used an Ada[2] cross-compiler, back when Ada was **real** new and implementations tended to be weak. When I had to generate an in-line trap, I discovered I could state it all in the HLL. One declaration of a bit pattern (which was the instruction), one package definition to define the interface to it and umpty-dozen pragmas to say put it in-line parameter A must be in register An and An+1 parameter B must be in register R1 Net result? It generated almost "perfect" code for the trap, without any register-moves or call-return linkages. This is extensible to modeling almost any machine instruction[3], and one can always re-write the package to turn it into a different instruction (or sequence of instructions) if you have to port it. --OR-- You can try to invalidate the problem, and make the compiler generate optimal code. Yes, I said MAKE. Another anecdote: last year, I had to speed up a critical inner loop in a very large system written in Pascal. The compiler **would not** accept a declaration for the construct that was needed (a pointer to an array greater than its normal maximum size). It was initially done by allocating the array in the non-pascal startup code and using inline assembler to access it. It was ***slow***. When I looked at the code generated, inlining had only saved me the call-return instruction pair, not the required register/stack setup for the call. So I wrote out the addressing expression in Pascal, as arithmetic. The code it generate was one instruction "poorer" than the optimum, because it moved the result from the general registers to the address registers at the end. This was 6 instructions better than the inline assembler, and 8 better than out-of line instructions. (The move occurred as a result of my using an explicit union: if the language understood casts, it might have disappeared too). Result? We got our speedup, even though Pascal "knew" it wasn't supposed to be that helpful. So don't dispair, you can get out of almost any problem in Confuser Science: you just have to go back to first principles and attack the meta-problem. --dave (no cute statement today) c-b [1] Including de-facto ones, if the hardware one is yucky... [2] Ada is a trademark of the U.S. Gov't (Ada Joint Project Office) [3] This is generally a super-non-portable idea, though. -- David Collier-Brown. |{yunexus,utgpu}!geac!daveb Geac Computers Ltd., | Computer science loses its 350 Steelcase Road, | memory, if not its mind, Markham, Ontario. | every six months.