Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!genrad!panda!talcott!harvard!seismo!rochester!bullwinkle!uw-beaver!tikal!bobc From: bobc@tikal.UUCP (Bob Campbell) Newsgroups: net.lang Subject: Re: structured assembler (Beating dead horses) Message-ID: <358@tikal.UUCP> Date: Wed, 26-Feb-86 13:36:40 EST Article-I.D.: tikal.358 Posted: Wed Feb 26 13:36:40 1986 Date-Received: Sat, 1-Mar-86 23:29:50 EST References: <350@3comvax.UUCP> <463@kontron.UUCP> <1078@mmintl.UUCP> <409@3comvax.UUCP> <697@harvard.UUCP> <1053@terak.UUCP> Reply-To: bobc@tikal.UUCP (Bob Campbell) Distribution: net Organization: Teltone Corp., Kirkland, WA Lines: 70 Summary: Compilers Optimizers Assemblers In article <1053@terak.UUCP> doug writes: >Balderdash. C is not a substitute for assembler. While C is basically >as flexible as assembler, it is nowhere near as efficient. If the >application demands efficiency, there is still no alternative to >assembler. This also is not true, it is not fair to compare generic languages like 'C' vs assembler. Why not take a specific example and say the Consular 'C' compiler is not as efficient as my foobar assembler. (we have a 8086 assembler which is a dog both in speed of assembly and support of macros). I still feel that is it possible to have optimizing compilers which will on the average generate code which is 2 times better then the average human produced code. (Human should read experienced assembler programmer) Also to go back to a earlier point about Apple's Mac and assembler programming the improvements in the new ROM where in some cases the application of compiler style object code improvements to the assembler code. Specificly unrolling some loops which can be done easily by a optimizing compiler. >........ >program for the IBM PC. It was written in Pascal, and was on the market >long before (assembler coded) Lotus 1-2-3. Within a couple months after >1-2-3 was introduced, Context MBA was a dead product because 1-2-3 ran >a lot *faster*. Lotus is now well off financially, and Context is bust. Yet another interesting argument for which there are many counter examples: To take the easiest lets use UNIX*, unix is very popular right now in spite of the fact that it is slower than traditional operating systems written in in assembler. It is very popular because of it's user interface (the shell, pipes, simple i/o interface, i/o redirection, etc), and because it is portable. Given your analysis UNIX would be "bust" but it is not, and in fact it is getting stronger. Another factor which you are not considering is the "RISC**" factor. The RISC concept implies that having instructions which require special programming in assembly language, are the sign of a flawed computer. This is because the presence of the special instructions which can not generaly be used by a compiler, are instructions which are not used very often. The presence of these special instructions slows down the operation of the computer on the normally executed instructions (mostly move, and compare instructions). The net result is that the machine runs faster overall with out the special instructions. Some RISC computers have instructions which do not allow for easy programming in assembler. Wirth's lilth (maybe not a RISC, but still a interesting concept) machine in fact is built with the assumption that only code generated by a compiler would run on the machine (the machine does not check for expression stack overflows). To further the example the pyramid (which I am using to write) this is a Unix machine for which there is NO SUPPORT for the assembler. In spite of this lack of assembler it is always faster then any other machine that we at teltone have access to. Bob Campbell Teltone Corp. Kirkland Washington. uw-beaver \ fluke -+- tikal!bobc dataio / [Time for cute remark] Lets make smarter machines to run slower software faster. *Unix is a Trademark of some AT&T division. **Reduced Instruction Set Computer.