Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon From: dillon@CORY.BERKELEY.EDU (Matt Dillon) Newsgroups: net.micro.amiga Subject: Re: C compiler comparison Message-ID: <8610050658.AA12992@cory.Berkeley.EDU> Date: Sun, 5-Oct-86 02:58:08 EDT Article-I.D.: cory.8610050658.AA12992 Posted: Sun Oct 5 02:58:08 1986 Date-Received: Tue, 7-Oct-86 19:50:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: University of California at Berkeley Lines: 153 >From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) > Also probably due to their use of 16 bit ints, which are, in >general, twice fast as equivalent 32 bit operations. Not twice as fast, since '32 bit operations' does not imply 32 bit memory access *all* the time. I seem to remember going through all this before (and being corrected on some points): 32 bit register operations are only slightly slower than 16 bit register operations. Memory operations are, of course, twice as slow, but if you include instruction fetch as well, the overall slowdown is not all that much. Also, you should note that there are far more register operations performed over memory (data fetch) operations in generic code. Thus, the overall speedup using 16 bit ints isn't as much as you might think. >>5. Manx DOES NOT USE THE STANDARD AMIGA FILE FORMAT. This >> is why the Manx compiler refused to work under AmigaDOS >> 1.2 (and perhaps still refuses, I don't know.) Manx >> made up their own object file format and wrote their own >> linker. Object produced with Manx will not be compatible >> with the Commodore assembler or Commodore libraries. >> > Jim Goodnow, author of the MANX compiler, had this to say about the >Alink object format in the Amiga conference on The WELL: >-------- >Actually, the Metacomco format is fairly limited since it doesn't >support any type of expression and is only a slight superset of >the load format. There are a lot of things we do with our load format >that can't be done within the limitations of the Metacomco format. >On the other hand, it is fairly simple to convert the Metacomco >format to the Aztec format and there will be a utility for that >purpose, that will convert object modules and/or libraries. >The object format we use has actually been evolved over several years >and is virtually identical for the 8080, 6502, 8086 and 68000 systems >that we support. I'm interested in exactly what the Metacomco format doesn't have that is needed. One thing that it doesn't have has to do with relative and address base calculations: I hear A new hunk type will be added by Lattice in 3.04 and supported by Blink. Anything else that the current format doesn't have? In diverging from the 'standard' object and library formats, Manx users must do a little work to get the latest revision of amiga libraries (a conversion program would make this trivial). >-------- In a later message, Jim also writes: >There are several problems. The biggest, is that a number of the items >in a hunk do not have a size. For example, a symbol item consists of a >number of chunks consisting of a name length, name, and offset. When the >loader loads your program it doesn't care about your symbols, but it can't >just seek past them, it has to look at each name size, skip the name and offset >and then look at the next name size. If you have a lot of symbols, can make a >big difference. A similar problem comes when you want to look at external >references. The first pass of a linker just wants to look at symbols and >their offsets to get everything resolved. It would have been nice if each >module had a header that told you where in the file the symbols were located >so you could go right to them and get them. Here I agree with the comment... A provision should have been made for the equivalent of UNIX RANLIB (Create a Random access library). The thing about the symbol-size (not being able to skip entire symbol sections) is justified, but those sections are generally so small that the file buffering reads them in anyway; I don't think you would see much speed improvment there. >>You don't need LSE at all to run Lattice C; it's just a >>text editor. I use MicroEMACS 3.6, which is public >>domain. MAKE can be had for free in the public domain, >>so don't buy Manx just for MAKE and don't buy Lattice >>MAKE either. >> > Agreed. But having 'make' is still nice. > I've also observed that some people on the net actually *like* the >lattice compiler, saying that the new version has advantages over MANX. > > Let me put it to you this way: Which would you rather type? This: > >1> df1:lc1 -idf1:include/ -oram: foo >1> df1:lc2 -v ram:foo >1> alink df1:lib/lstartup.obj+ram:foo.o library df1:lib/lc.lib+df1:lib/amiga.lib to ram:foo faster > > or this: > >1> cc foo.c >1> ln foo.o -lc -o foo > > I realize I may be exaggerating the situation a bit, but I think >MANX is *infinitely* easier to use. And no flames about using batch files >to run the Lettuce compiler; my disks grind quite enough, thank you. > > What can I say? I like MANX. Gosh, I guess the MAKE I'm using w/ Lattuce is just a ghost. As for 'cc', there is a version of that for Lettice also (though I just use some nice aliases from my shell to do all the dirty work). 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 -The Manx linker is not any faster than Blink (so much for RanLibs). -there are PD MAKE's and CC's for Lattice -Doesn't have error reporting as in-depth as lattice. -32 bit ints seems to be a hack (not the major optimization point) -Code compaction gained with 16 bits ints completely lost with 32. Points for Lattice: -Adheres to the Amiga standard -very nice error reporting Points not for Lattice: -two pass compiler executable's for both passes total 200K+ (takes a long time to load) -current released stdio library not in very good shape. -doesn't have equivalent save/restore state -doesn't directly support the FFP library for floating point Points of NO INFORMATION: (that I do not have any info on) -Does Manx directly support the FFP library? -Is the Manx compiler one pass or two? executable size? -how large is a symbol table dump compared to the size of The #include files dumped? -do utilities exist in PD to convert standard libraries/object modules to Manx and back? -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. 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