Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tnc!m0154 From: m0154@tnc.UUCP (GUY GARNETT) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: <789@tnc.UUCP> Date: 9 Apr 91 15:54:04 GMT References: <1991Mar31.003933.1483@mintaka.lcs.mit.edu> <1991Apr1.020748.26863@mintaka.lcs.mit.edu> Reply-To: m0154@tnc.UUCP (GUY GARNETT) Organization: The Next Challenge, Fairfax, Va. Lines: 95 [OK, you've got it: No flames, serious answers] [Software written in C versus assembler. You can't recompile when a better compiler comes along, and all of this stuff is bigger and slower than it has to be. "Sometimes this tradeoff is something you might live with, others its not".] The tradeoff has to be evaluated by the systems analyst who designed the software, or the programmer who coded it; there is simply no other way. The tradeoff is three ways: between algorithm and program design, coding and debuggin time, and maintainance time. Over the lifetime of a significant commercial application, the third is by far the largest expense; it makes good economic sense to take any steps necessary to minimise it (even if it costs in terms of the first two). This is why most productivity applications are written in a higher level language. I would also like to point out that tight, fast assembly coding will not cure a poor design (as a case in point, take OS/360 and its descendants - they are pure assembler, at this point literally millions of lines - and the current MVS/ESA is still a hog!). To take a specific point: [AmigaOS v2.0 comments] I'm sure that Commodore would love to have v2.0 coded entirely in assembler, tight and fast, by a team of the worlds best 680x0 assembler programmers. Unfortunately, they are in business to make money; they cant afford the development time or the staff requirements to do that. Perhaps you'd like to do it full-time (on an unpaid basis, of course)? I didn't think so; neither would I. I'm sure that Commodore's engineers are getting it to us as fast as they can, and will be delivering the best performance that they can. Sure, it could be better (but there's always 2.1 :) but I don't want to have to waqit 5 years for it to come out, and then have to pay $500 for the update. [Why does the best compiler run so slowly] I'll bet that gcc was designed to be relatively portable, and has a number of stages, each of which add to the compile time (as opposed to a fast one- or two- pass compiler which emits object code directly instead. So the design of the compiler imposes speed constraints. The implementation (probably coded in C, for portability) adds others. On top of it all, good optimization involves heavy symbol manipulation on the part of the compiler (IBM's VS FORTRAN has one of the best optimizers I've seen, and when its fully enabled, compile times increase by a factor of 3 to 5. Then again, it produces better assembly code than any IBM ALC/370 coder I've met; although there might be some that can better it). Personally, I'd like an implementation of Object-Oriented Turbo Pascal (v5.5 or later language spec) for the Amiga, with a front end (symbol based) and a back end (code based) optimizers. The OOP language extensions add a lot of power to the language, and an assembly inclusion feature would allow the worst speed offenders (which can be identified with Turbo Profiler) to be recoded in assembly. I've doe a of development with this package on the PClones, and it beats (in terms of good code and easy development) all of the other development environments I have tried on the PC. [c.library and printf.library] Good Idea. Why don't you (or someone else who is a very good assembler programmer) write them and make them freely distributable (or even better yet, give them to Commodore for inclusion in the 2.0 (or maybe 2.1) distribution? [linkerless C; why does C need #pragma to know about library routines] Like an assembler that could only emit complete object modules, a "linkerless" C compiler would loose a lot of its power. The liker is your friend, it can save you from compiling the same code fragment over and over again. C needs a #pragma to pass parameters to library routines because the Amiga subroutine calling conventions are different from the default C calling convention. It is easy, and certainly much more efficient that passing arguments on the stack (which would also make assembly coding much more cumbersome). On the other hand, it is certainly possible (although more difficult) to design a compiler which passes arguments in registers by default; it is even possible to design one which "knows" about the library bases and can "automagically" manipulate them (opening and closing libraries as needed) - as a matter of fact, I have a specification for such a language, but I have not tried to implement it (I need to add object oriented facilities to the spec, see the above about TurboPascal). [Trapping the guru] I don't know why people don't do this more often, either. Ideally, the compiler should generate such code as part of the run-time package, with an option to disable it. On the other hand, it should also be possible for any programmer to add it to the standard startup code. [optimizing MULU] Any decent peepholer (compiler back-end optimizing technique) should be able to pick this one up. C programmers who ask you what it means just aren't paying attention (or didn't bother to read the code). On the other hand, a comment line might not be a bad idea, either. Wildstar