Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!caip!cbmvax!higgin From: higgin@cbmvax.cbm.UUCP (Paul Higginbottom) Newsgroups: net.micro.amiga Subject: Re: C compiler comparison (a heavenly development system!) Message-ID: <838@cbmvax.cbmvax.cbm.UUCP> Date: Sun, 5-Oct-86 14:33:30 EDT Article-I.D.: cbmvax.838 Posted: Sun Oct 5 14:33:30 1986 Date-Received: Tue, 7-Oct-86 20:54:37 EDT References: <8610050658.AA12992@cory.Berkeley.EDU> Reply-To: higgin@cbmvax.UUCP (Paul Higginbottom) Organization: Commodore Technology, West Chester, PA Lines: 122 In article <8610050658.AA12992@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >... >Points for Manx: > -Based on 16-bit ints making for more compact code. > -Compilation is faster (this is the biggest point) > -has options to save and restore the symbol table so you don't need > to include all those include files all the time. > -optional in-line assembly > -optional assembly generation (?) > -comes with a vi-like editor (?) > -comes with a make utility > -stdio library is well done > >Points not for Manx: > -Doesn't use the Amiga standard for modules This has never made the slightest bit of difference to me. I only use C so am hardly worried about mixing object files. Also, you mentioned that this would make it harder to have the latest library because they're released in MetaComco format - well, how many have versions have been released? Two? Three MAYBE? There's no "disadvantage" here, Matt. > -The Manx linker is not any faster than Blink (so much for RanLibs). That's not a DISADVANTAGE - you're just writing points about areas where Lattice is "AS GOOD AS" Manx. > -there are PD MAKE's and CC's for Lattice So? This is a negative for Manx? > -Doesn't have error reporting as in-depth as lattice. Definitely agree, Manx should be improved on this score. The latest beta version IS beta, er, better. > -32 bit ints seems to be a hack (not the major optimization point) > -Code compaction gained with 16 bits ints completely lost with 32. Definitely agree, the 32 bit mode of the compiler is not only weak, it has BUGS. But then, the Manx system was DESIGNED to only use 16 bit ints, and I think anyone who buys Manx and only uses the 32 bit option is foolish. I have used it just to compile things I know will need 32 bit ints (i.e., generally that means sloppy code that interchanges pointers and ints - do these people run their compilers in SILENT mode? Surely they must get tons of warnings.) >... >Points of NO INFORMATION: (that I do not have any info on) > -Does Manx directly support the FFP library? Yes, it's pretty nice - the "float" type uses mathffp, and the double (in 3.20a was unimplemented and was basically internally treated like a float except for storage and passing size) can now be treated as mathieee, or manx-double-precision (if you don't want to have to rely on a library being around or the load time off disk), or 68881 support (don't know how this works). > -Is the Manx compiler one pass or two? executable size? Compiler LITERALLY produces an assembler source file and 'cc' invokes the assembler with the temporary source file (which can be kept around with an option). The temp file can be made wherever you want (I use RAM of course). The compiler is about 74K (v3.30c) and the assembler is about 42K (impressive, and the assembler now supports all the assem directives for compatibility. > -how large is a symbol table dump compared to the size of > The #include files dumped? Well, I don't know if this helps, but here's how I run. I have a symbol table file of EVERY SINGLE INCLUDE Amiga has in RAM, and it's 114K. The ram driver under 1.2 appears to be INCREDIBLY fast, and the compiler seems to take about a tenth of a second to load it in. > -do utilities exist in PD to convert standard libraries/object > modules to Manx and back? You can convert TO Manx, but not back (i.e., upward compatible). HOWEVER!!! The next release of Manx will allow you to FREELY INTERMIX Amiga and Manx object code, and link libraries. > -has anyone done any speed tests Lattice vs Manx which DO NOT > include the time it takes to load the executables? (this is > for compilation). Also, don't include manx's ability to load > symbol table dumps.. What I'm interested in is a comparison > of actual compilation speeds. Well, this isn't an ideal speed example, but it might give you an idea. Consider the following: cd ram: edit in test.c which is the standard hello world program cc test (1.5 seconds - that includes compile and assemble) ln test.o -lc (5 seconds) >I agree that Lattice has a bit of catching up to do in terms of speed, >but think that Manx is off track by going off standard. > > -Matt The non-standard issue that Manx lacks is completely irrelevant for me, because a) it doesn't affect my FULL-TIME development, and b) if a standard is bad, why should one use it (e.g IFF)? Lattice has a TON of catching up. I read recent praises about Lattice's "slick optimizing ability" but I've gone through tons of Manx compiler output, and some of the code it producing is nothing short of astonishing. Math operations converted into bit shifts if constants are powers of two, knowledge of "easy" constants like 0, 1, -1, etc. Uses short relative addressing wherever possible. My development system by the way, is an Amiga with Comspec's 2Mb AX2000 add-on, a MicroForge hard drive, and one external floppy. A lot of stuff goes into ram at powerup but all source/object remains on the hard drive. My system is usually faster than a VAX-750 I've used (even UNLOADED). My only gripe with Manx is that the 32 bit option isn't perfect. Paul Higginbottom. Disclaimer:I do not work for Manx or Commodore and my opinions are my own.