Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: C compilers (was a flame war : -) Message-ID: Date: 4 Apr 91 21:42:25 GMT References: <1991Apr3.233053.7051@ux1.cso.uiuc.edu> Organization: Not an Organization Lines: 93 In article <1991Apr3.233053.7051@ux1.cso.uiuc.edu> cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) writes: >In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>... > >>Why hasn't someone made the entire c.lib into a loadable library >>so all programs can share it instead of duplicating these routines >>hundreds of times all over everyone's hard disks? Why not even >>just printf.library (this alone would save megabytes on my hard disk)? > >I think Matt's DICE library routines could be placed into a library, >Matt? This really is something that should have been done *a* *hell* >*of* a long time ago... All the standalone routines can, and, in fact, pfmt() (used by [v][s][f]printf()) is standalone, as well as things like strcpy(), movmem(), etc... Under 2.0, many of the routines that would otherwise not be easily placed in a shared library have direct OS equivalents now. The reason you don't see much in the way of common code is that most programmers generally want to provide standalone executables. You can't put everything into a shared library, though... something like atexit() would be difficult. The actual overhead of c.lib isn't all that bad. >>Why didn't Jez Sans write a 'C' compiler? > >Who's Jez Sans? Never heard of him... General good guy... never wrote a C compiler because he never had the desire to, for the same reason I have never written, say, a postscript interpreter. What a dumb question. >>Why don't 'C' compilers support linkerless usage? Because a C program is generally made up of several modules, not to mention link libraries... this is another stupid question. Besides, you can generate absolute-relocated images just fine, it's called ROMABLE (in the DICE dist) and converts an executable into an absolute relocated image. Not EVEN to mention that the *ONLY* people who care about linkerless usage in the context you are talking about are, game programmers. The only time I use absolute relocated images is when I'm writing ROMd code for custom 68000 boards. >>Why don't 'C' compilers know about the routines in the OS without >>#pragmas? While we're at it, why not all the structures and other >>things from the header files, too? Huh? >>Why do 'C' programmers ask me whether I use: >> MULU #17,d0 >>instead of: >> move.l d0,d1 >> lsl.l #4,d0 >> add.l d1,d0 >>when it is basic programming normally done by assembler language >>programmers (one of the oldest tricks in the book)? > >I would never ask such a dumb question... Neither would I. I think Mike (Schwartz) missed the point of that particular posting... the point being that many of todays C compilers will do those kind of optimizations automatically so the programmer doesn't have to think about it. In assembly, you have to take a certain amount of time to plop them down. Of course, the MULU example above is intuitivly obvious... A compiler like GCC or SAS/C will do optimizations such as strength reduction and loop unrolling on arbitrarily complex subroutines, something that would take a LOT longer to optimize by hand, which is the point of the observation. >>Come on people, no flames for this, these are serious questions. >>-- >>**************************************************** >>* I want games that look like Shadow of the Beast * >>* but play like Leisure Suit Larry. * >>**************************************************** >Me too... > >Loren J. Rittle -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA