4526P@NAVPGS.BITNET (Lt. Scott A. Norton, USN) (11/29/86)
I am planning to get a C compiler, and would appreciate your comments
and suggestions on which compiler I should buy. In particular:
a. comparative efficiency of object code produced ( time and space )
b. Completeness of the implementation ( I know C is not standardized...)
c. Known bugs.
d. Compatability with public domain C programs. ( It looks like most
of these are Lattice dialect...)
d. Should I get the "Developer's version," "Personal version," or what?
I am not planning to be a developer and write DeLuxe Paint, but I am
a proficient 68000 assembly programmer, and it seems you must buy an
upscale version to get the assembler.
Please send comments to:
BITnet: 4526P@NAVPGS
ARPAnet: 4526P%NAVPGS.BITNET@wiscvm.wisc.edu
Tks/ Scott Norton.
Disclaimer: "My friend Lenny, he just ain't too smart." ( - Of Mice and Men )chiu@princeton.UUCP (Kenneth Chiu) (11/30/86)
In article <795@ulowell.UUCP> 4526P@NAVPGS.BITNET (Lt. Scott A. Norton, USN) writes: > I am not planning to be a developer and write DeLuxe Paint, but I am > a proficient 68000 assembly programmer, and it seems you must buy an > upscale version to get the assembler. The Manx assembler is not directly compatible with the include files. This is a major headache if you want to write programs that interface with kernel. -- Kenneth Chiu UUCP: princeton!chiu Princeton University Computer Science Department BITNET: 6031801@PUCC
cmcmanis@sun.uucp (Chuck McManis) (12/01/86)
In article <795@ulowell.UUCP>, 4526P@NAVPGS.BITNET (Lt. Scott A. Norton, USN) writes: > Please send comments to: > BITnet: 4526P@NAVPGS > ARPAnet: 4526P%NAVPGS.BITNET@wiscvm.wisc.edu > Tks/ Scott Norton. I tried both of these addresses and they bombed, such are the vagaries of this hodge podge of networks... Comments on the Lattice C compiler version 3.10 > a. comparative efficiency of object code produced ( time and space ) Lattice has made great gains in this area, I would speculate that this is due to pressure put on them by Manx. Load modules that don't use printf are comparable now. > b. Completeness of the implementation ( I know C is not standardized...) Lattice is going straight for the ANSI standard. This is probably a good thing, they don't seem to know which way to jump with the library yet but this version has lots of neat new functions, including support for the FFP routines and some new ieee routines. > c. Known bugs. I just found one in the *library* that causes file pointers to switch back from unbuffered to buffered. Luckily this version of the compiler comes with an Object Module Librarian so putting in the fix is easy. > d. Compatability with public domain C programs. ( It looks like most > of these are Lattice dialect...) Since Lattice comes with the developers package this is not unusual, it is also easier to port your programs back to to a PC this way (should you ever want to) Generally most stuff will compile on either compiler again the biggest problem is the libraries and the fact that the Amiga system calls really want 32 bit ints not 16 bit ones. > d. Should I get the "Developer's version," "Personal version," or what? A matter of personal preference, the cheapest version of Lattice ($225) now, comes with the text utilities grep, files, splat, wc, etc and an assembler, and the Blink linker, and the compiler. Combined with microemacs and the Software Distilleries make program you have a pretty complete development environment. In general for serious Assembly work you will probably want the MetaCompCo assembler (Scotts Valley, CA) or the DevPAC from the guys in britain. [These are definitely my own opinions here!] -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
root@sbcs.UUCP (Root) (12/04/86)
[possible repost of this message - hit 'n' if you have seen it] Chuck, The C compiler I am using for my Amiga is not sooo bad - in fact it is made by your company. Seriously, the Sun C compiler produces good, correct code for either 68000/68010/68020's. All one has to do to use it is to rewrite a few multiply/divide routines, and get/write a C library (Manx commercial version comes with lib source, right?), and of course, cook up a format converter from a.out -> AmigaDOS executable. I have been doing development using a system similar to this for several months now, and am convinced that cross development is the only way to go for serious work. If memory serves, I believe I read somewhere that Amiga does their development using the (expensive) GreenHills compiler system that also runs on a SUN. Why suffer the slings and arrows of Manx, Lattice, etc if you have access to a Sun workstation? Rick Spanbauer
john13@garfield.UUCP (12/04/86)
In article <9776@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: >In article <795@ulowell.UUCP>, 4526P@NAVPGS.BITNET (Lt. Scott A. Norton, USN) writes: >> d. Compatability with public domain C programs. ( It looks like most >> of these are Lattice dialect...) > >Since Lattice comes with the developers package this is not unusual, it >is also easier to port your programs back to to a PC this way (should you >ever want to) Generally most stuff will compile on either compiler again >the biggest problem is the libraries and the fact that the Amiga system >calls really want 32 bit ints not 16 bit ones. On this point I must beg to differ, as I have *never* gotten any of the PD programs, from Amicus or Fish disks, or here off the net. All that I have tried have worked fine with Manx (I still try Lattice on a source every now and then just to make sure). Most older sources seem to have been broken by fixes made to bugs in the compiler; I can't say for sure, but you would think it would at least get past the include files without streams of errors! Of Lattice's recent improvements I can't comment; a Lattice C ordered from the mainland that arrived here yesterday was still v3.03, so I'd check the version number before buying (although this might not be such a problem in the States). One of the biggest advanages that Manx has, in my opinion, I very rarely see mentioned: this is Manx's use of pre-compiled symbol tables. For example, say you are compiling the VT100 source, composed of several modules. Each one would begin with several #includes, such as #include <intuition/intuition.h> For each module to churn through these takes an eternity, and you can't put all of your include files in ram unless you have a meg or two. However, Manx only needs to read these in once, at which time it can save all the #defines, structure definitions, etc. When compiling subsequent modules that reference the symbols, you can have the symbol table loaded in almost instantaneously! The real beauty of this scheme is that it requires no change in the source code; any #includes that your program tries to perform will be disabled if the symbols are already present in memory. Needless to say this results in a dramatic increase in speed. What is the fastest Lattice could compile and link a file that uses the intuition include files, without packing absolutely everything into ram? Manx, with only "cc" and the c.lib library, can do it in 35 seconds. Hardly gives you time to put on the coffee, quite a change after Lattice :-) John
jones@dg_rtp.UUCP (Greg Jones) (12/04/86)
In article <9776@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: > >Comments on the Lattice C compiler version 3.10 > >> d. Should I get the "Developer's version," "Personal version," or what? > >A matter of personal preference, the cheapest version of Lattice ($225) >now, comes with the text utilities grep, files, splat, wc, etc and an >assembler, and the Blink linker, and the compiler. Combined with microemacs >and the Software Distilleries make program you have a pretty complete >development environment. > >In general for serious Assembly work you will probably want the MetaCompCo >assembler (Scotts Valley, CA) or the DevPAC from the guys in britain. > I have the 3.10 lattice compiler and have found that an assembler is also included on the release. It is called asm, but I don't know how it compares to the one mentioned above. -- Greg Jones Data General, RTP, NC ...!seismo!mcnc!rti-sel!dg_rtp!jones
phils@tekigm.UUCP (12/10/86)
In article <248@sbcs.UUCP> root@sbcs.UUCP (Root) writes: >by your company. Seriously, the Sun C compiler produces good, correct >code for either 68000/68010/68020's. All one has to do to use it is to >rewrite a few multiply/divide routines, and get/write a C library (Manx >commercial version comes with lib source, right?), and of course, cook >up a format converter from a.out -> AmigaDOS executable. I have been doing >development using a system similar to this for several months now, and >am convinced that cross development is the only way to go for serious >work. I see two problems with this. First is the questionable legality of putting the Manx library on a machine other than that for which the compiler was bought. I'd like to see some comments from some of our more legal-minded readers about this, as I have been considering doing just this, but have felt legally obliged to provide routines of my own design, or at least in the public domain. The second pertains to what your development environment is. If you are able to develop code which can be quickly downloaded to the Amiga, that's one thing. But if, for example, you develop code via modem and must download at 1200 baud, the extra time required for download more than makes up for the amount of time it takes to compile in a native environment (i.e., on the Amiga). This brings it down to which compiler generates better code. We have a GreenHills compiler running on a Gould Unix system (read: *fast* compilation times). In many cases, I have found that at least the size of the code generated by the Manx compiler compares very favorably with the GreenHills compiler. (Of course, that only means anything when Manx writes the right code 8-) !! ). I'm not sure about speed. Another thing about the GreenHills compiler is that (unless there's a switch I don't know about) it doesn't generate PC relative code for anything. It's all absolute. This results in bigger code which must be relocated before execution when AmigaDOS loads it. (read: longer startup times). For these reasons, I'll continue to use my Manx compiler for anything that doesn't require more disk than I have available (2 floppies for now). ------------------------------------------------------------------------------- "I'm sure you think you understand what you thought I said, but I hope you realize that what you heard is not what I meant." Phil Staub P.O. Box 3500 Tektronix, Inc. Vancouver, Washington 98668 ISI Engineering M/S C1-904, (206) 253-5634 ..tektronix!tekigm!phils -------------------------------------------------------------------------------
grr@cbmvax.UUCP (12/10/86)
In article <248@sbcs.UUCP> root@sbcs.UUCP (Root) writes: > I have been doing >development using a system similar to this for several months now, and >am convinced that cross development is the only way to go for serious >work. If memory serves, I believe I read somewhere that Amiga >does their development using the (expensive) GreenHills compiler system >that also runs on a SUN. Why suffer the slings and arrows of Manx, >Lattice, etc if you have access to a Sun workstation? > Rick Spanbauer What you say may be true, but there are some philosophical issues with cross development vs. native mode. Contemplate the effect on the state of Amiga CLI, Utilities and Development tools if Amiga had switched to native mode development somewere along the line... Of course much of the code was written before there was an operating system or a fully functional chip set. The Sun setup also contains a hardware device to control and download to an amiga. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
root@sbcs.UUCP (Root) (12/13/86)
Phil Staub writes: > First is the questionable legality of putting the Manx library on a machine > other than that for which the compiler was bought. Perhaps I am mistaken, but the real issue is whether Manx charges a royalty for use of their C library. They cannot possibly care whether their C library is linked with code generated in hand coded assembly language, their compiler system, or another code generator. As to the other issue, that of their development system being purchased for the Amiga and then actually residing on the Sun, well simply tell them that the license for use is to be assigned to the Sun. Note that my solution was to write my own C library, so how Manx handles licensing is a non issue for me. > The second pertains to what your development environment is. If you are able > to develop code which can be quickly downloaded to the Amiga, that's one I don't download to the Amiga - I use NFS to run the programs directly from the Amiga. > This brings it down to which compiler generates better code. > We have a GreenHills compiler running on a Gould Unix system (read: *fast* > compilation times). In many cases, I have found that at least the size of > the code generated by the Manx compiler compares very favorably with the > GreenHills compiler. (Of course, that only means anything when Manx writes > the right code 8-) !! ). I'm not sure about speed. Another thing about the "Better" code (smaller, I think you meant) is _a_ reason, but there are more important factors: 1) The Manx compiler system was (is?) buggy. In a few weeks use of Manx, I found at least 2 compiler bugs. I've been using Sun's compiler for months now and have run across only one bug. 2) The Manx compiler system utilities crashed quite a bit. `make' crashes were particularly annoying. 3) Long compilation/link times. Didn't have Perry's Recoverable Ram Disk (ASDG corp - very nice products!) at the time - this might have made the compile/link cycle shorter. Currently, I can compile several modules and link whole system in the time Manx took just to link a few modules together on floppy (yes, .o's too large for RAM:). 4) A set of floppy disks could not hold all the object/binaries needed (last count about 7 mBytes src/object). 5) Sun comp. sys is as "Unix like" a compiler (e.g. has enums, better structure handling, etc) a compiler as you're likely to find for the Amiga. 6) The Sun comp. sys has truly optimized code, e.g. strength reduction in array indices, common subexpression elimination, branch tail reduction, etc, etc. 7) Superior development environment available in Unix. I like SCCS, vi, a "real" make, yacc, lex, etc available in Unix. All of the above are "standard equipment" in the $400 Sun Unix release. 8) We needed the option of generating true 68020 code at some point in the future. > GreenHills compiler is that (unless there's a switch I don't know about) it > doesn't generate PC relative code for anything. It's all absolute. > This results in bigger code which must be relocated before execution when > AmigaDOS loads it. (read: longer startup times). Granted that the Sun system cannot generate index register data references, however, they can generate PC relative code references. They also do span dependent instruction optimization in the assembler (bra <-> jmp as necessary). Rick Spanbauer PS. Don't totally misinterpret my position Re: Manx - I feel that it is the finest compiler system available for small 68000 systems today.
phils@tekigm.UUCP (Phil Staub) (12/15/86)
In article <251@sbcs.UUCP> root@sbcs.UUCP (Root) writes: >Phil Staub writes: >> First is the questionable legality of putting the Manx library on a machine >> other than that for which the compiler was bought. >Perhaps I am mistaken, but the real issue is whether Manx charges a >royalty for use of their C library. Actually, what I had in mind was the legality of compiling the *source* for the Manx library on a machine other than the one licensed, with the intent of building a library on that machine which could be used to generate Amiga executables. > As to the >other issue, that of their development system being purchased for the >Amiga and then actually residing on the Sun, well simply tell them >that the license for use is to be assigned to the Sun. I still want to retain the rights to use the compiler on my Amiga, for two reasons: first, the Amiga is mine. The Gould on which I would potentially be generating code is not. I have no qualms about spending my bucks on my computer, but I refuse to do so for the Gould. Second, I seriously doubt I could get my company to spring for it, since I, as an Amiga owner, am in a distinct minority, and I am not using it in my development work. >> The second pertains to what your development environment is. If you are able >> to develop code which can be quickly downloaded to the Amiga, that's one >I don't download to the Amiga - I use NFS to run the programs directly from >the Amiga. I think my point has been made here. My Amiga is at home, connected to the machine on which the GreenHills compiler runs by modem *only*. If I had the NFS option, I would undoubtedly be doing just what you are doing. >> This brings it down to which compiler generates better code. >"Better" code (smaller, I think you meant) is _a_ reason, but there are >more important factors: > > 1) The Manx compiler system was (is?) buggy. Notice my comment about "when Manx writes the right code". I should have said "generates" instead of "writes". > 2) The Manx compiler system utilities crashed quite a bit. `make' > crashes were particularly annoying. This may depend upon what you mean by 'crashed'. If you mean "don't work quite as documented", or maybe even "don't produce proper results", I would agree. I found the librarian in 3.20a to be my biggest headache. On the other hand, if you mean "crash the machine", I can only think of one example, and, yes, it was with 'make'. > 3) Long compilation/link times. Agreed. I, too, wish I had a hard disk or lots of ram. > 4) A set of floppy disks could not hold all the object/binaries needed > (last count about 7 mBytes src/object). I believe I commented that if I were to ever work on a project as large as you describe, I would have to make other arrangements than Amiga-native compilation. > 5) Sun comp. sys is as "Unix like" a compiler (e.g. has enums, > better structure handling, etc) a compiler as you're likely > to find for the Amiga. > 6) The Sun comp. sys has truly optimized code, e.g. strength > reduction in array indices, common subexpression elimination, > branch tail reduction, etc, etc. > 7) Superior development environment available in Unix. I like > SCCS, vi, a "real" make, yacc, lex, etc available in Unix. > All of the above are "standard equipment" in the $400 Sun > Unix release. I don't have access to a 680x0-based Unix box. That's why I talk about the GreenHills cross-compiler. GreenHills, although good, could hardly be expected to be as solidly supported as a native compiler. For example, the GreenHills compiler we are using doesn't even have an assembler and linker. It had to be combined with an assembler/linker/librarian package from Oasys. On point 5, these items are supposed to be improved in the "next" Manx release. > 8) We needed the option of generating true 68020 code at some > point in the future. I may be mistaken, but I'm under the impression that the next "real" release of Manx will do this. >> GreenHills compiler is that (unless there's a switch I don't know about) it >> doesn't generate PC relative code for anything. It's all absolute. >Granted that the Sun system cannot generate index register data >references, however, they can generate PC relative code references. Again, I'm not talking about Sun, I'm talking GreenHills, which I still maintain does not have the capability of generating PC relative code. >PS. Don't totally misinterpret my position Re: Manx - I feel that it is > the finest compiler system available for small 68000 systems today. I agree. Thanks for your comments. -- ------------------------------------------------------------------------------- Phil Staub tektronix!tekigm!phils (206) 253-5634 Tektronix, Inc., ISI Engineering P.O.Box 3500, M/S C1-904, Vancouver, Washington 98668