Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucrmath!rhyde From: rhyde@ucrmath.ucr.edu (randy hyde) Newsgroups: comp.sys.apple2 Subject: Re: HLLs vs. Assembly (was Re: IIgs Unzip thing) Keywords: C, Compiler, Assembly Language Message-ID: <14105@ucrmath.ucr.edu> Date: 1 May 91 22:28:53 GMT References: <9104041653.AB15986@apple.com> <10505@pitt.UUCP> Organization: University of California, Riverside Lines: 33 re: I wouldn't want to write assembly code on a big machine.... register optimizations... cache hits... etc... Actually, anyone with about a year's experience can handle most of this with no problem. I've written assembly code on 80386, 680x0, and 32532 machines (which IMHO, are big), and I'm learning SPARC right now. It's not that big a deal to do those things you're so frightened of. I can tell you what's worse-- writing a serial driver on the 6502 using the game port on the Apple II. I've written a couple of those in my time. At one time I had all the instruction cycle timings for the 6502 instr. set memorized (it's been a while since I can remember them, though!). I consider this a greater feat than learning about cache hits and delay slots, and stuff like that. As for compilers doing better than people at code generation, I must reiterate an earlier post-- (1) This applies only if you continue thinking in C while programming in assembly. If you do not switch to the assembly language programming paradigm (which, admittedly, takes a couple of years to learn), you don't stand a chance against modern optimizing compilers (which most available today are *not*). (2) The same data flow analysis tools which optimize compilers can be applied to assembly language. You could write a tool to tell you that you could be using the register better, or that moving a few instrs. around will speed things up. This needn't be limited to HLLs. Admittedly, such tools do not exist yet, but I'm working on such items (alas, not for the 65816, DFA tools wouldn't be much help for optimization [though I have developed a DFA tools for helping show program correctness of assembly language programs on the GS]). *** Randy Hyde