jtang@orion.cf.uci.edu (James Tang) (04/30/89)
I am looking for a C compiler. So far I have come across MJC 2.0, GCC-134, and Sozoban compiler. (MJC - Mark Johnson C) Anyone care to comment on each of the C compiler? It's overall performence, versatility, and compatibility. Any recommendation? Any comment would be appreciated. Thanks in advance! james Usenet: jtang@orion.cf.uci.edu Bitnet: JWTang@UCIVMSA.BITNET
steve@pnet51.cts.com (Steve Yelvington) (05/01/89)
jtang@orion.cf.uci.edu (James Tang) writes: >I am looking for a C compiler. So far I have come across MJC 2.0, GCC-134, >and Sozoban compiler. (MJC - Mark Johnson C) Anyone care to comment on each >of the C compiler? It's overall performence, versatility, and compatibility. >Any recommendation? > >Any comment would be appreciated. Thanks in advance! > >james > >Usenet: jtang@orion.cf.uci.edu >Bitnet: JWTang@UCIVMSA.BITNET I've used two out of three, so... Mark Johnson C is limited in comparison with the other two, although it is a fine compiler in comparison with anything you'll find for free in the IBM-PC world. The generic (Unix-like) library covers only the bare necessities. The GEM bindings appear to implement most of the AES and VDI functions. MJC uses two passes to create an executable file. The first is a combined preprocessor, parser and code generator that emits a very terse assembly language of Mark's own design. The second is a combined assembler-linker that creates a .TTP, .TOS or .PRG file. The libraries are maintained as assembly source code, so throughput suffers somewhat. I found MJC to be more than adequate for learning C and the only compiler that I would recommend to someone with a 520 and a single-sided disk drive. (It was developed on such a machine.) Sozobon C is a far better compiler, definitely of professional quality. It appears to generate code that is superior (smaller/faster) than that created by Laser C and generally similar in size/performance to that created by Mark Williams C. It includes dLibs, the C library that Dale Schumacher developed to circumvent the shortcomings of the Atari/DRI/Alcyon compiler's library. The whole package is highly compatible with Alcyon -- you can use Alcyon libraries, and vice versa -- and complete, with a full complement of utilities. The compiler comes complete with source code to itself, the libraries, and all the utilities, so you can modify *anything* in the package. The current distribution does not include GEM bindings, but two sets of GEM bindings (GEMFAST and GEMQ) are available (also free). Sozobon is being ported to Minix, and a whole raft of improvements is in the works. GCC is the GNU C Compiler from the Free Software Foundation. I have not used it, but by reputation it is an excellent compiler whose primary sin is the requirement of a lot of RAM -- you probably need a Mega 2 or better to be happy with it. Incidentally, all three of these compilers require that you use a command-line processor (not supplied). I'm working on a GEM front-end for the Sozobon CC program, and if I ever get the TEDINFO structure untangled in my own head, I'll release it. /* * UUCP: {uunet!rosevax,amdahl!bungia,chinet,killer}!orbit!thelake!steve * ARPA: crash!orbit!thelake!steve@nosc.mil * #member <STdNET> The ST Developers Network */
7103_300@uwovax.uwo.ca (Eric Smith) (05/01/89)
In article <1810@orion.cf.uci.edu>, jtang@orion.cf.uci.edu (James Tang) writes: > I am looking for a C compiler. So far I have come across MJC 2.0, GCC-134, > and Sozoban compiler. (MJC - Mark Johnson C) Anyone care to comment on each > of the C compiler? It's overall performence, versatility, and compatibility. I haven't used MJC2.0, but I wasn't too impressed by an earlier version, which had a very minimalist feel and was missing most of the preprocessor (that should be fixed now, I'm sure). Sozobon seems to be OK. If you've got the memory, though, get the GCC. It's definitely the best C compiler for the ST that I've seen. I did some benchmarks on Sozobon, Laser, and the GCC, and the rankings were pretty consistently GCC > Sozobon > Laser, except for compilation speed (Laser is incredibly fast). Also, the GCC is ANSI compliant, although the library that comes with it isn't (Jwahar Bammi and I have written a new library that will be out soon and that fixes this). The major drawback of the GCC is the memory requirements. It will run (barely) on a 1040, but for serious work with it you need 2 Megs of memory and a hard disk. I have a Mega 2, and I still run across programs that the optimizer runs out of memory on. -- Eric R. Smith email: Dept. of Mathematics 7103_300@uwovax.uwo.ca University of Western Ontario 7103_300@uwovax.bitnet London, Ont. Canada N6A 5B7 (a shared mailbox: put my name on ph: (519) 661-3638 the Subj: line, please!)
apratt@atari.UUCP (Allan Pratt) (05/02/89)
In article <1048@orbit.UUCP> steve@pnet51.cts.com (Steve Yelvington) writes: > GCC is the GNU C Compiler from the Free Software Foundation. I have not used > it, but by reputation it is an excellent compiler whose primary sin is the > requirement of a lot of RAM -- you probably need a Mega 2 or better to be > happy with it. I got GCC version 1.23 for the ST from Simon Poole (indirectly), and I found that its 68000 code generation is TERRIBLE. It is beaten by ALL the other Atari C compilers I could find (Dhrystone 2.1), by a factor of two or more in some cases. This includes using -O, but no other optimization options; some may pay, others aren't available (like "no-function-cse"). For 68020 the code quality is not substantially better: it doesn't beat MWC's 68000 code (both running on a 68020 (well, 030), obviously). And without the 68030's cache enabled, GCC's 020 is worse than all but Aztec's +P (large code, data, and ints) 68000 code. My point is that this port of GCC stinks. It could be that 1.3x is better; I hope so. I suspect that the GCC back-end was originally coded for 68020, and somebody went in and made 68000 work from that; this resulted in the bad times for 68000. These are the ST timings I got for Dhrystone 2.1. (I can't publish any non-ST times.) All are on the same ST, with the same things going on in background (mainly checking for special "hot" keys; the background stuff is why the times are slower than yours). COMPILER OPTIONS NOREG REG -------- ------- ----- ---- GCC 452 475 GCC -O 540 540 AZTEC large 768 834 MWC 986 1065 MWC -O -Vpeep 1014 1091 ALCYON 982 1097 AZTEC small 1063 1161 TURBO -GJMPRZ 1650 1730 (from J.Oklamcakn) Aztec is version 3.6c; "large" is +P, meaning large code, large data, and 32-bit ints; "small" means the defaults: small code (PC-relative) small data (address-register relative) and 16-bit ints. Aztec large and GCC have 32-bit ints, all others 16. Turbo C blows everybody else away partly because they pass arguments in registers, and probably Julius ran it on a bare ST (nothing running in Vblank). ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
randyh@hpsad.HP.COM (Randy Hosler) (05/02/89)
As far as public domain compilers go I use MJC, but then I only have a 520 and a single sided drive. I couldn't get Sozobon to run under those conditions. MJC is not in the same ballpark as Sozobon or commercial compilers but you can learn alot about C and the ST with it. I think that if you have a setup like mine then MJC is the way to go. While we're on the subject... Does anyone have the startup code for a desk accessory for MJC 2.0? I would appreciate it posted here or emailed. Randy Hosler |\ | | _ | |/ |-| /\ < | [] /\ randyh@hpsadpe |\ . | | \/ _> | \_ |
egisin@mks.UUCP (Eric Gisin) (05/03/89)
In article <1471@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > I got GCC version 1.23 for the ST from Simon Poole (indirectly), and I > found that its 68000 code generation is TERRIBLE. It is beaten by ALL > the other Atari C compilers I could find (Dhrystone 2.1), by a factor of > two or more in some cases. This includes using -O, but no other Someone must have botched the port of GCC. I've been using versions of gcc as a cross-compiler for the ST since version 1.23. It always had Dhrystone 2's of 1200+, better than everything except Turbo C. I use the Sun configuration, compile with -m68000 -mshort -fsoftfloat(?), and Henry Spencer's string functions. I download the objects at 1200 baud; its worth the trouble.
sarnila@tukki.jyu.fi (Pekka Sarnila) (05/04/89)
Just a note. With gcc you get a crosscompiler for unix. So if you have acces to BSD unix system, you can compile your ST programs there, including the big ones that woun't in ST. -- ------------------------------------------------------------------- Pekka Sarnila, University of Jyvaskyla Finland sarnila@tukki.jyu.fi -------------------------------------------------------------------
poole@forty2.UUCP (Simon Poole) (05/05/89)
In article <1471@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: ........ >I got GCC version 1.23 for the ST from Simon Poole (indirectly), and I ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ May I point out that this is NOT TRUE! While a do have a copy of this version of gcc: a) I did not port it. b) I did not redistribute it (particulary not to the US) (If this was an attempt at a flame Allan, it was rather badly aimed). >found that its 68000 code generation is TERRIBLE...... This is actually true, the code produced with -m68000 and -mshort is not very good, which is no wonder, since gcc is targeted for a 68020 and the -m68000 flags just tells it to avoid 68020 specific stuff. .....It is beaten by ALL >the other Atari C compilers I could find (Dhrystone 2.1), by a factor of >two or more in some cases. This includes using -O, but no other >optimization options; some may pay, others aren't available (like >"no-function-cse"). ..... ?as far as I remember, all the flags that are sensible work (and do give some performance improvement). ..... For 68020 the code quality is not substantially >better: it doesn't beat MWC's 68000 code (both running on a 68020 (well, >030), obviously). And without the 68030's cache enabled, GCC's 020 is >worse than all but Aztec's +P (large code, data, and ints) 68000 code. I'm not quite sure what you are trying to prove with this statement, that code that uses the mc68000 `small` model is faster than corresponding `large` model code is no secret and not supprising. If you want to limit all your programs to 32kB data structures and 16 bit ints, please don't let us stop you. (BTW did you try real programs or did you just try Drhystone????) > >My point is that this port of GCC stinks. .... ^^^^ The machine description is the standard 68020 one, the code that is produced has got nothing to do with the actual Atari port. As to the quality of the 68020 code produced (I've used/am using gcc on other machines) I can assure you that gcc is pretty good, and that I'm not the only person that thinks so. >These are the ST timings I got for Dhrystone 2.1. (I can't publish any >non-ST times.) All are on the same ST, with the same things going on in >background (mainly checking for special "hot" keys; the background stuff >is why the times are slower than yours). [numbers deleted] Using ONE number to classify a compiler is not a very good idea, I could just as well claim that mwc and Turbo C are broken because they fail on one moderately complex and long macro (in Flex). Gcc is interesting on the ST, because: - it's an ANSI C compiler - it produces true `large` model code - the code produced for the above model is good - it has automatic register allocation - program size and complexity is only limited by available memory - it's free -- ---------------------------------------------------------------------------- Simon Poole Due to a new job these addresses will be going away after the 1. of June! UUCP: ...mcvax!cernvax!forty2!poole BITNET: K538915@CZHRZU1A
usenet@TSfR.UUCP (usenet) (05/08/89)
In article <703@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes: >In article <1471@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >> [Discussion of lousy Dhrystones for GCC] >> .....It is beaten by ALL >>the other Atari C compilers I could find (Dhrystone 2.1), by a factor of >>two or more in some cases. This includes using -O, but no other >>optimization options; some may pay, others aren't available (like >>"no-function-cse"). ..... >> ..... For 68020 the code quality is not substantially >>better: it doesn't beat MWC's 68000 code (both running on a 68020 (well, >>030), obviously). And without the 68030's cache enabled, GCC's 020 is >>worse than all but Aztec's +P (large code, data, and ints) 68000 code. > >If you want to limit >all your programs to 32kB data structures and 16 bit ints, please don't >let us stop you. (BTW did you try real programs or did you just try >Drhystone [sic] ????) If the Dhrystone was completely invalid, it wouldn't be used. 10-15% variance can probably be ignored, but when a compiler turns in results that are half of the other compilers, it's probably an indication that something is badly damaged in that compiler. And if the '020 code it produces doesn't work as well as someone else's '000 code on a '020, well, that's one sick puppy. `Limited' by 16-bit ints && 32k data structures? Hmm, that's a novel idea. I'll be on the lookout for those `limits' in the future. >>My point is that this port of GCC stinks. .... > ^^^^ >As to the quality of the 68020 code produced (I've used/am using gcc on >other machines) I can assure you that gcc is pretty good... Pity the ST is only a 68000. If Gnu CC is designed for a '020, perhaps that explains the abominable benchmarks when it's chopped up for the ST. However, I don't see any connection between your use of GCC on other machines (presumably '020s?) and the awful performance reported by apratt. >>These are the ST timings I got for Dhrystone 2.1. >Using ONE number to classify a compiler is not a very good idea... Yes, but if that one number is *so* substandard, it's a good indication that _something_ is *NOT* *WORKING* in that implementation. >... just as well claim that mwc and Turbo C are broken because they fail on >one moderately complex and long macro (in Flex). Maybe so. But the compiled code works quickly, which is one of the _really_ important things for some of us. (It's easier to write a new cpp than it is to write a new code generator.) Alcyon C chokes on complex expressions that GCC will probably digest without a quiver, but if the code coming out of GCC runs half as fast as Alcyon, I'll gladly live with having to `fix' the source code for Alcyon. -david parsons -orc@pell.uucp
jsm@phoenix.Princeton.EDU (John Scott McCauley Jr.) (05/08/89)
Just to add my $0.02 about GCC on the Atari ST. Last summer I was doing cross-compiles. The numbers here are approximately right -- they are from memory. I was getting 750+ Drystones a sec (after optimal tweaking) on my monochrome 1040 ST. The same code (except for i/o routines) was running about six times faster on a 20 Mhz Sun 3 with a 68020. This was about 20% better than the Sun C compiler. (Both Sun and GNU have come out with faster versions since then.) There are three factors (at least) to take into account: 1) Memory bandwidth. The 020 can do 32 bit fetches where the 000 has to fetch 16 bits at once. 2) Clock speed. Asuming 100% cache hits, we should see 25 Mhz out of the Sun. 3) The 020 has better timings on some 000 instructions I think. I tried both 000 and 020 code on the Sun, and there was little difference. If you assume that the 1) and 2) are the main factors, then I was getting the Atari ST dps figure within 10% (factor of 3 for clock speed, factor of 2 for memory access). So perhaps I should run small model Atari ST code on the Sun and get 10,000+ dps.... Wow! Instant Vax 8700! Scott -- Scott McCauley, jsm@phoenix.princeton.edu (INTERNET) Home: (609) 683-9065 Office: (609) 243-3312 (FTS 340-3312) Fax: (609) 243-2160 (FTS 340-2160)
7103_300@uwovax.uwo.ca (Eric Smith) (05/08/89)
In article <539@TSfR.UUCP>, usenet@TSfR.UUCP (usenet) writes: > In article <703@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes: >>In article <1471@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >>> [Discussion of lousy Dhrystones for GCC] >>> .....It is beaten by ALL >>>the other Atari C compilers I could find (Dhrystone 2.1), by a factor of >>>two or more in some cases. This includes using -O, but no other >>>optimization options; some may pay, others aren't available (like >>>"no-function-cse") ... >> [discussion of problems with benchmarking deleted ] > If the Dhrystone was completely invalid, it wouldn't be used. 10-15% > variance can probably be ignored, but when a compiler turns in results > that are half of the other compilers, it's probably an indication that > something is badly damaged in that compiler. Here are my benchmark results for the GCC v1.31, Sozobon, and Laser C v1.01. Several things to keep in mind (besides, of course, the generic problems with benchmarks): (1) Both Laser and the GCC have newer versions available (1.35 and 2.0 respectively). (2) I used Dhrystone 1.1, NOT 2.1 , so these results are not directly comparable to the ones posted by Mr. Pratt. They should give an indication that the GCC does indeed generate good code, though. (3) I don't know why GCC 1.23 supposedly generated such poor code. I do know that its library had a few bugs; sometimes a buggy time() routine can do strange things to timing routines :-). In the table below, all compilations are done with the -O flag, where available. The GCC has several extra levels of optimization available which were *not* used. Benchmark results: Compiler Dhrystones/sec Laser 1.01 818 Laser w. regs. 849 GCC 1.31 979 GCC w. regs. 979 (<- the GCC optimizer knows how to use regs.) Sozobon 1.0 932 Sozobon w. regs 978 One final note: Laser and Sozobon were using 16 bit int's; GCC uses 32 bit int's. Newer versions of the GCC also support 16 bit int's (actually 1.31 did as well, but the library didn't have any 16 bit routines). -- Eric R. Smith email: Dept. of Mathematics 7103_300@uwovax.uwo.ca University of Western Ontario 7103_300@uwovax.bitnet London, Ont. Canada N6A 5B7 (a shared mailbox: put my name on ph: (519) 661-3638 the Subj: line, please!)
meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks) (05/08/89)
[I've trimmed down the original article quite heavily. FM
In article <1471@atari.UUCP apratt@atari.UUCP (Allan Pratt) writes:
I got GCC version 1.23 for the ST from Simon Poole (indirectly), and I
found that its 68000 code generation is TERRIBLE. It is beaten by ALL
the other Atari C compilers I could find (Dhrystone 2.1), by a factor of
two or more in some cases. This includes using -O, but no other
Why don't you mention the DRI C compiler??
Not a speed monster either.
These are the ST timings I got for Dhrystone 2.1. (I can't publish any
non-ST times.) All are on the same ST, with the same things going on in
background (mainly checking for special "hot" keys; the background stuff
is why the times are slower than yours).
COMPILER OPTIONS NOREG REG
-------- ------- ----- ----
GCC 452 475
GCC -O 540 540
The gcc 1.34 version is above 1000 if I recall correctly.
Don't have the exact figure handy.
AZTEC large 768 834
MWC 986 1065
MWC -O -Vpeep 1014 1091
ALCYON 982 1097
AZTEC small 1063 1161
TURBO -GJMPRZ 1650 1730 (from J.Oklamcakn)
Aztec is version 3.6c; "large" is +P, meaning large code, large data,
and 32-bit ints; "small" means the defaults: small code (PC-relative)
small data (address-register relative) and 16-bit ints. Aztec large and
GCC have 32-bit ints, all others 16. Turbo C blows everybody else away
gcc 1.34 has also the option to use 16 bit ints.
partly because they pass arguments in registers, and probably Julius ran
it on a bare ST (nothing running in Vblank).
The gain with turbo C is also achieved by carefully handcrafting the
library routines in assembler.
By the way: which library did you use with gcc? This will influence the
timing greatly.
Some other facts:
gcc is a full ansi compiler and it is free (while being supported better
than most or perhaps all of the other compilers mentioned)
Anyway, apart from the fact that gcc is a memory hog for me it is still
a great compiler. I use it as frequent as Turbo C
Frans Meulenbroeks (meulenbr@cst.prl.philips.nl)
Centre for Software Technology
( or try: ...!mcvax!phigate!prle!cst!meulenbr)apratt@atari.UUCP (Allan Pratt) (05/10/89)
In article <703@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes: > (If this was an attempt at a flame Allan, it was rather badly aimed). It was NOT an attempt at a flame. If I were trying to flame somebody in particular, I hope there wouldn't be any doubt. I misread an attribution on a readme-type file with the distribution; the porting and library credit really goes to JRD @ Stony-brook.SCRC.Symbolics.COM. However, I don't hold him responsible for the code quality. The library is another matter; it's a hodgepodge of PD stuff from around the world, and he is the first to admit it. Its argument parsing in crt0.s and argument passing in exec.c are mutually inconsistent and actually incompatible, and there are other omissions and inconsistencies. Why no-function-cse doesn't work, I don't know. Function-cse (common subexpression) means that the address of a function to be called is a candidate for being put in a register, especially if it's used more than once. This means the "dumb" (pre-optimizer) pass puts it in a register, generating this: lea _foo,a0 jsr (a0) A later, optimizing pass should notice that _foo is moved into a register only once, then used in a sense where a register is not needed, and "fold" that subexpression into "jsr _foo" as you would expect. But it doesn't. And I couldn't turn this off with the documented switch "-fno-function-cse." But that switch is missing. Anyway, I look forward to getting a newer version of the compiler, on tape from Bammi at CWRU in Ohio, so this will all blow over soon. Sorry to have been such a boor. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
poole@forty2.UUCP (Simon Poole) (05/10/89)
In article <539@TSfR.UUCP> orc@TSfR.UUCP (David L. Parsons) writes: >In article <703@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes: >>In article <1471@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >>> [Discussion of lousy Dhrystones for GCC] ......... >>If you want to limit >>all your programs to 32kB data structures and 16 bit ints, please don't >>let us stop you. (BTW did you try real programs or did you just try >>Drhystone [sic] ????) > > If the Dhrystone was completely invalid, it wouldn't be used. 10-15% If 99% of the people that use dhrystone don't even know what it mesures, how are they to know if it's valid or invalid???? >variance can probably be ignored, but when a compiler turns in results >that are half of the other compilers, it's probably an indication that >something is badly damaged in that compiler. And if the '020 code it >produces doesn't work as well as someone else's '000 code on a '020, ^^^^^^^^^^^^^^^^^^ `small model` code (16 bits integers) is faster on a 020, regardless if you are generating 020 or 000 code (this is not quite true for stuff that's in the cache). >well, that's one sick puppy. I think it would be instructive for you to have a look at the actual dhrystone code. To show why dhrystone results shouldn't be overrated, here a profile of dhrystone 1.1 (sorry, didn't have the sources of 2.1 handy): granularity: each sample hit covers 2 byte(s) for 0.01% of 125.57 seconds flat profile: %time the percentage of the total running time of the program used by this function. cumsecs a running sum of the number of seconds accounted for by this function and those listed above it. seconds the number of seconds accounted for by this function alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. %time cumsecs seconds calls name 18.3 23.04 23.04 1 _Proc0 15.1 42.02 18.98 500002 _strcpy 14.1 59.74 17.72 500000 _Proc1 13.9 77.18 17.44 500000 _strcmp 7.5 86.66 9.48 500000 _Proc8 6.1 94.31 7.65 500000 _Func2 4.8 100.38 6.07 1500000 _Func1 4.7 106.23 5.85 1500000 _Proc7 4.0 111.26 5.03 500000 _Proc6 3.9 116.15 4.89 500000 _Proc3 2.6 119.42 3.27 500000 _Proc2 1.7 121.53 2.11 500000 _Proc4 1.7 123.62 2.09 500000 _Func3 1.5 125.56 1.94 500000 _Proc5 [rest of profile deleted] As you can see a good 30% of the time is spent in the libary routines strcpy and strcmp (this was run on a machine with assembler strcpy and strcmp), so bad/good dhrystone ratings do not HAVE to be representive of the actual code generated. One way to get very high dhrystone ratings is to make strcpy and strcmp compiler builtins, if the compiler is smart enough it can even turn the strcpy in to a block move. If Allan was running dhrystone with the first set of libary routines distributed with the Atari gcc port, it's no wonder he got so bad results (in particular if he didn't at least recompile them with the -fomit-frame-pointer flag). -- ---------------------------------------------------------------------------- Simon Poole Due to a new job these addresses will be going away after the 1. of June! UUCP: ...mcvax!cernvax!forty2!poole BITNET: K538915@CZHRZU1A
jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (05/14/89)
Date: 10 May 89 11:55:56 GMT
From: mcvax!cernvax!ethz!forty2!poole@uunet.uu.net (Simon Poole)
If 99% of the people that use dhrystone don't even know what it mesures,
how are they to know if it's valid or invalid????
In my experience, that sort of question rarely comes up when
benchmarkers are talking about their results.
[...]
To show why dhrystone results shouldn't be overrated,
[...]
As you can see a good 30% of the time is spent in the libary routines strcpy
and strcmp
[...]
Thanks, Simon, for injecting a note of sanity into a topic that usually
degenerates into religious feuding.
One of the things that wins about GCC is that you've got a lot of
flexibility about how to do things. In the case of the offending
library functions that are taking 30% of the time, at least one fix is
trivial: Just declare the things inlinable, and let the compiler do its
thing. As near as I can tell, that's as good as what you'd get if you
taught the compiler about them as internal functions. I tried declaring
the simpleminded strcpy implementation inline, and got a couple
instructions of setup, and a 3-instruction loop embedded in the code.
If that's not good enough, you can probably save one instruction by
hand-coding it, and again, GCC allows you to define hairy assembler
constructs, which can get access to C values. The double-float code
does this extensively. Jwahar Bammi has an OSBIND.H that uses this
feature, too.
The point of all this is that you can easily tune the code GCC produces
to look like just about anything. If what you do with your ST is run
benchmarks all day, then you can make it produce good benchmarks. If
you do something else, you can tune it for that. All the sources are
available (several times over), so you can make it do whatever you like.
Finally, for those of you who don't like those solutions, there's an
even easier one: Don't use it!