may@husc4.harvard.edu (jason may) (01/15/87)
What are the very latest (either just-out or about-to-released-
very-soon) versions of C, both Lattice and Manx, and how much do they cost?
What are the various versions ("commercial", "developers", other) available?
What do the different versions include? Does Manx still compile faster and
give tighter code than Lattice? Which companies will give free/cheaper
updates to improved versions? What other questions should I ask?
Replies can be posted or mailed.
Thanks in advance,
Jason
may@husc4.harvard.edu ...seismo!harvard!husc4!maylmurray@wdl1.UUCP (Lance Murray) (02/15/88)
I am a new subscriber and have heard rumblings about MANX vs Lattice. What's
the *REAL* story? What are the incompatabilities, advantages of each,
disadvantages of each? Why are the incompatabilities there?
-lance-
lmurray@ford-wdl1
{sun, hplabs, ucbvax}!wdl1.uucp!lmurray
/* #include <std.denials> */
/* #include <cute.saying> */
/* After macro exapsion: */
/* These comments are my own opinion, and may not reflect the */
/* feelings of my employer (FACC). */
/* "Does bouncing count?" -- Silk, The Belgriad (book 4 ?) */
page@swan.ulowell.edu (Bob Page) (04/18/88)
For anyone thinking about upgrading, switching, or buying a C compiler: Read Chris Zamara's review of Lattice 4.00 in the first (April 88) issue of Transactor for the Amiga. It's very balanced, and he makes direct comparisons bewteen Manx Aztec C and Lattice C. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
olva@geocub.UUCP (Olivier Vayssettes ) (01/05/89)
Comparative inquiry between MANX & LATTICE C compilers. I am going to write a large C and assembly program for Amiga. I have been told about possibilities of LATTICE 5.0 and MANX 3.6 (I think 3.6 is the most recent one). If you have already used these compilers (even only one of them), could you tell me your opinion about their advantages and drawbacks, so that I could choose between them? If I have a sufficient number of replies, I will broadcast the result on the net Thank you very much for your replies. Olivier Vayssettes Universite de Bordeaux - France
rwallace@vax1.tcd.ie (01/21/89)
In article <496@geocub.UUCP>, olva@geocub.UUCP (Olivier Vayssettes ) writes: > Comparative inquiry between MANX & LATTICE C compilers. > > I am going to write a large C and assembly program for Amiga. > I have been told about possibilities of LATTICE 5.0 and MANX 3.6 (I think > 3.6 is the most recent one). If you have already used these compilers > (even only one of them), could you tell me your opinion about their > advantages and drawbacks, so that I could choose between them? I have used both compilers and I personally find Manx C vastly superior. The compiler itself is much faster. It's also much more compact which means it'll fit in RAM disk on my 1-meg Amiga whereas Lattice C has to be loaded in from floppy if I'm working on a big project which slows things down a lot more. The precompiled header files are much better than Lattice C's "compact" versions of the files which have to be recompiled every time. The developer and commercial versions come with a number of incredibly useful utilities like GREP and MAKE. The only advantage of Lattice C is its support for function prototypes, which is only one small advantage set against the many major disadvantages. Manx 3.6 also has the source-level debugger. With regard to code produced, even using 16-bit integers, stack-checking disabled, every option chosen to make the code as efficient as possible, Manx C always produces programs that are much more compact, and usually faster as well. The link overhead for Manx is lower and examination of assembly listings shows that Manx produces better code in most ways. I think that about covers everything. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (01/25/89)
In article <30997@vax1.tcd.ie> rwallace@vax1.tcd.ie writes: >In article <496@geocub.UUCP>, olva@geocub.UUCP (Olivier Vayssettes ) writes: >> Comparative inquiry between MANX & LATTICE C compilers. >> >> I am going to write a large C and assembly program for Amiga. >> I have been told about possibilities of LATTICE 5.0 and MANX 3.6 (I think >> 3.6 is the most recent one). If you have already used these compilers >> (even only one of them), could you tell me your opinion about their >> advantages and drawbacks, so that I could choose between them? >I have used both compilers and I personally find Manx C vastly superior. >The compiler itself is much faster. It's also much more compact which means >it'll fit in RAM disk on my 1-meg Amiga whereas Lattice C has to be loaded in >from floppy if I'm working on a big project which slows things down a lot more. >The precompiled header files are much better than Lattice C's "compact" >versions of the files which have to be recompiled every time. The developer >and commercial versions come with a number of incredibly useful utilities >like GREP and MAKE. The only advantage of Lattice C is its support for >function prototypes, which is only one small advantage set against the many >major disadvantages. Manx 3.6 also has the source-level debugger. When you make this sort of comparative posting, could you please specify the versions you're basing your comparisons on? You're out of date in several respects, which would have been obvious if you had said what version of Lattice you're basing your opinions on. (Note that the request explicitly asked about Lattice 5.0.) Manx is smaller, and fits more comfortably on un-expanded Amigas. Manx is also probably still faster comiling. On the other hand, Lattice C 5.0 has precompiled header support as well as the "compact" headers. The standard version comes with grep, lmk (make), lse (an editor), a profiler, source level sybolic debugger, cross reference tool, optimizer, assembler, and a handful of other tools. Lattice, besides having function prototypes, also is much closer to ANSI compatibility. It has extensions for mixing memory models in the same source file, forcing data to be loaded into chip or fast ram, specifying what registers arguments should be put in (for calling assembly, or perhaps for writing non-time-critical interrupt handlers or libraries in C). It has startup modules for creating resident programs, and startups which will catch most gurus and other exceptions and dump a traceback before exiting cleanly. Lattice also does some "lint-like" checks for bad parameters (using the function prototypes), mis-matched assignments, conflicting declarations, and more, which some people hate, but which I would hate to program without. >With regard to code produced, even using 16-bit integers, stack-checking >disabled, every option chosen to make the code as efficient as possible, >Manx C always produces programs that are much more compact, and usually >faster as well. The link overhead for Manx is lower and examination of >assembly listings shows that Manx produces better code in most ways. I don't think this is true anymore. Lattice 5.0, especially with the optimizer enabled, produces quite good code. Executable size is competitive with Manx, even without using a lot of tricks. And linking is much faster now that Lattice has added indexing to the library format. In general, I think Lattice and Manx are much closer than you think. I highly recommend Lattice if you are willing to give up some compile speed in return for type checking, function prototypes, and ANSI compatibility. Manx, on the other hand, compiles faster, and the compiler is smaller. Speed and size of the final code just isn't that different anymore, and Lattice probably has the edge in speed...at least for now. >Russell Wallace, Trinity College, Dublin >rwallace@vax1.tcd.ie -Dan Riley (dsr@lns61.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
jimm@amiga.UUCP (Jim Mackraz) (01/25/89)
In article <30997@vax1.tcd.ie> rwallace@vax1.tcd.ie writes: )In article <496@geocub.UUCP>, olva@geocub.UUCP (Olivier Vayssettes ) writes: )> Comparative inquiry between MANX & LATTICE C compilers. )I have used both compilers and I personally find Manx C vastly superior. ) .... I think you have to make a new comparison now that Lattice 5.0 is out. It is vastly improved, in both features and code quality. Basically, Aztec has been taking an extended "pit stop" in the Amiga compiler race, and Lattice has passed them by. I've recently switched over. One big reason is that Lattice is receiving active support and Aztec is not. The aztec compiler is still smaller, but both compilers can be made resident (using different tools). (You should have lot's-o-ram anyway.) Also, the advantages Aztec had by being "non-standard" in file format, execution of child processes (e.g., by its "make"), environment variables, and so on are now not so beneficial. It is becoming increasingly important to hook up with the standard environment. Lattice now has precompiled include files (and you can use more than one), comes with grep and make (a nice one), the ANSI stuff, a good source debugger. Also, in some cases (a module in the Amiga rom), Lattice has been able to produce more compact code. Their global optimizer is quite powerful, and the register passing makes writing or interfacing to libraries more efficient and simple. Basically, I think rwallaces analysis was completely valid, until Lattice 5.0. Based on the support issue, I'd say the tide has turned. jimm -- Jim Mackraz, I and I Computing "Like you said when we crawled down {cbmvax,well,oliveb}!amiga!jimm from the trees: We're in transition." - Gang of Four Opinions are my own. Comments are not to be taken as Commodore official policy.
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (01/25/89)
Just my two cents. I have and use both Manx 3.6 and Lattice 5.0. I prefer Lattice. The support is infinitely better; the improvements have been happening (when was the last time you heard anything from Manx?) Sure, it's bigger and slower, but you'll have fewer bugs with the prototyping and better warnings . . . Executable sizes are comparable; if you use stdio, Lattice will be slightly larger because Lattice uses a more conformant stdio; if you don't use stdio, Lattice will probably be smaller. I still use Manx for a sizable fraction of my development, because I have so much code with Manxisms in it that I just haven't had time to bring over to Lattice. I plan to insure that any future PD code I release works under both. I suggest you log on to BIX and compare activity in the Lattice conference (where bug fixes are often posted minutes after bug reports) to activity in the Manx conference (when was the last time Jim logged on? All I ever see there are curses and complaints.) If this is biased, well, you asked for my opinions. I was a beta tester for the original Manx product and helped beta test Lattice 5.0. My preferences are obvious. -tom
dale@boing.UUCP (Dale Luck) (01/25/89)
In article <3271@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >In article <30997@vax1.tcd.ie> rwallace@vax1.tcd.ie writes: >)In article <496@geocub.UUCP>, olva@geocub.UUCP (Olivier Vayssettes ) writes: >)> Comparative inquiry between MANX & LATTICE C compilers. > >)I have used both compilers and I personally find Manx C vastly superior. >) .... > >I think you have to make a new comparison now that Lattice 5.0 is out. > >Basically, I think rwallaces analysis was completely valid, until Lattice 5.0. >Based on the support issue, I'd say the tide has turned. > > jimm I have to agree with jimm here. We've been oscillating between Manx and Lattice for our first release of the Xlib and toolkits for the Xwindow programmers library. Right now, Manx still chokes on much of the source code from the standard distribution whereas Lattice slogs along just fine. I'm not interested in modifying the source code to make it work with any particular compiler. It is a support issue. I don't want to have to remodify the source code when the next release of X comes out. So comforming compilers get my vote of support. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (01/26/89)
From article <30997@vax1.tcd.ie>, by rwallace@vax1.tcd.ie: > versions of the files which have to be recompiled every time. The developer > and commercial versions come with a number of incredibly useful utilities > like GREP and MAKE. The only advantage of Lattice C is its support for > function prototypes, which is only one small advantage set against the many > major disadvantages. Manx 3.6 also has the source-level debugger. These sound like comments which are pertinent to Lattice version 4. Version 5 is much improved. It offers precompiled header files, the Lattice Compiler Companion (a suite of text and file management programs including grep and LMK which is Lattice's name for their make program), and a very nice source level debugger. I can't speak to the issues of speed and code size because I haven't used the Manx compiler. I've been very pleased with the Lattice compiler and the support Lattice provides. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3
karl@sugar.uu.net (Karl Lehenbauer) (01/27/89)
With regard to the discussion of which C compiler is better, as Dan Riley says, it determines on which versions you compare. First there was only Lattice, so for a while it was the best choice because it was the only choise. Then came Aztec, which at the time produced faster, smaller code, didn't need as much disk space for the compiler and such, and compiled programs significantly more quickly. At that time there were few if any hard disks, so many people found these advangates to be rather compelling. There was a matter of the additional cost of buying another compiler and no doubt this affected many decisions as to which way to go. A subsequent Lattice release (4.0?) put Lattice back on top, with better performance. I'm not sure when function prototypes arrived for Lattice (they haven't yet for Aztec), but they are really good for catching bugs, and I wish Aztec had them (more on that in a bit.) Aztec then came out with the 3.4 release. The big improvement here was 'sdb', a windowing symbolic debugger that, despite some bugs and problems debugging certain code constructs, has been a tremendous productivity improver, for me at last. This, in my opinion, caused Aztec to again achieve predominance over Lattice. Lattice subsequently came out with their own debugger and made other improvments in the compiler. They also have come out with C++, although users on the net haven't been terribly impressed with it in its current form. I think right now, Lattice is a bit ahead of Aztec, but not substantially enough for an Aztec 3.6 user to make the jump. I haven't examined the code generated by Lattice, but Aztec's leaves much to be desired. It's frustrating to see the compiler moving values from a perfectly useful d-register into another d-register to perform a calculation on it. Also, it does stuff like dereferencing a chain of pointers p->q->bar on every reference -- even if it already has the address it needs sitting in a register. I talked to Aztec tech support on the phone recently, though, and they say that a new version, scheduled for release in March (but it'll probably slip by months -- they're pretty bad about doing that) which is full ANSI, including prototypes, and does register tracking and global register allocation, so it should generate much better code and also spurt Aztec ahead of Lattice again until the Lattice people come out with their next version. It's a good thing there are two C vendors for the Amiga. If there were only one it's doubtful it'd be as good as the two are, although I do not think either meets the standards of the cardinal IBM PC C-compilers. -- -- uunet!sugar!karl | "We've been following your progress with considerable -- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV -- Usenet BBS (713) 438-5018
jesup@cbmvax.UUCP (Randell Jesup) (01/28/89)
In article <3342@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >With regard to the discussion of which C compiler is better, as Dan Riley >says, it determines on which versions you compare. So true. >A subsequent Lattice release (4.0?) put Lattice back on top, with >better performance. I'm not sure when function prototypes arrived >for Lattice (they haven't yet for Aztec), but they are really good for >catching bugs, and I wish Aztec had them (more on that in a bit.) Function prototypes arrived with 4.0, along with direct library calls (another big win - no more move push params, call stub which pops params and calls rom). >Lattice subsequently came out with their own debugger and made other >improvments in the compiler. They also have come out with C++, although >users on the net haven't been terribly impressed with it in its current >form. I think right now, Lattice is a bit ahead of Aztec, but not >substantially enough for an Aztec 3.6 user to make the jump. 5.0 also includes another VERY important feature: a global optimizer. I beta-tested it, and spent a LOT of time looking at code quality. The optimizer, while not as good as I am (in most cases :-), does a VERY good job. I was astounded at what it did to for (i = 0; i < foo; i++) loops. It also does an excellent job of putting values it will need later into spare registers for temp storage (I thought I had caught it a few times, it turned out it was smarter than I was), and also does a far better job at allocating registers than my register statements do (since it can switch registers between different variables in different sections of a routine). 5.0 also included things formerly in the Lattice Compiler Companion, such as LMK (a good make clone), grep, splat, diff, and an integrated editor, LSE, formerly a seperate product. >I haven't examined the code generated by Lattice, but Aztec's leaves much to >be desired. It's frustrating to see the compiler moving values from a >perfectly useful d-register into another d-register to perform a calculation >on it. Also, it does stuff like dereferencing a chain of pointers >p->q->bar on every reference -- even if it already has the address it needs >sitting in a register. Lattice 3.10 used to do that, 4.02 was somewhat better, but didn't have an optimizer. >I talked to Aztec tech support on the phone recently, though, and they say >that a new version, scheduled for release in March (but it'll probably slip >by months -- they're pretty bad about doing that) which is full ANSI, including >prototypes, and does register tracking and global register allocation, so >it should generate much better code and also spurt Aztec ahead of Lattice >again until the Lattice people come out with their next version. Also lattice seems (in my perhaps biased opinion) to give better support. There is fast response on BIX to problems, plus they run a BBS for registered owners. There have been over 2000 messages in lattice/amiga.c on bix, and they post preliminary versions of patches there when possible. (For example, the 5.01 patches, which will be superceded by the 5.02 that will be mailed to registered owners.) Manx used to be ok (all done by Jim Goodnow, Manx tech support personel rerely used bix), but support seemed to disappear about 6 to 8 months ago. (I hear Jim has been busy, and moved to New Jersey). >It's a good thing there are two C vendors for the Amiga. If there were only >one it's doubtful it'd be as good as the two are, although I do not >think either meets the standards of the cardinal IBM PC C-compilers. Lattice 5.0 is coming pretty close, certainly it's closer to ANSI than most PC compilers, and the optimizer puts it in the league of the large- caliber PC compilers. Disclaimer: I some of the people who worked on 5.0, and I beta tested it. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
shimoda@infohh.rmi.de (Markus Schmidt) (01/29/89)
Hi! Everyones talking about the precompiled .h-files in Lattice. Manx did this since V. 3.4 and it saved me a LOT of time when Lattice didnt even know what it was :-) Hoever, I think you should wait for Manx 4.1. to compare to Lattice 5.0. .-----------------------------------------------------------------. | shimoda@rmi.de `---' The last remaining adventure | | shimoda@gopnbg.UUCP |O o| since there are no more tigers: | | ==Y== Doublebuffered async. I/O _ | |----------------------- `U' ------------------------------ _ // | | Good terminalpackages begin with A: AmigaCall, A-Ta.. \// | `-----------------------------------------------------------------'
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (02/01/89)
<I haven't examined the code generated by Lattice, but Aztec's leaves much to <be desired. It's frustrating to see the compiler moving values from a <perfectly useful d-register into another d-register to perform a calculation <on it. Also, it does stuff like dereferencing a chain of pointers <p->q->bar on every reference -- even if it already has the address it needs <sitting in a Lattice 4.0 was doing a nice job of saving temporary values - including references. At least in the cases I looked at, which were of the form: if (long->messy->pointer->chain <cmp> magic_value) long->messy->pointer->chain = magic_value ; It would only chase through the pointer once. That meant I didn't have to go convert all of those to: tp = &long->messy->pointer->chain ; if (*tp <cmp> magic_value) *tp = magic_value ; Which is a major win as far as I'm concerned. <I talked to Aztec tech support on the phone recently, though, and they say <that a new version, scheduled for release in March (but it'll probably slip <by months -- they're pretty bad about doing that) which is full ANSI, The one time I looked at Aztec, I decided it wasn't worth fooling with after finding three bugs in the compiler on the first project I was working on - one of which couldn't be worked around. Because of that, I don't have any kind of feel for how well they deliver on promises like "full ANSI". I'd be interested in hearing how well they do; especially on the nitpicky little details (type of main correct? return XX from main? stdargs treatmenat? predefined symbols? obscure ANSI functions?). >Everyones talking about the precompiled .h-files in Lattice. >Manx did this since V. 3.4 and it saved me a LOT of time when >Lattice didnt even know what it was :-) Yup - Manx having them undoubtedly caused Lattice to put them in. Likewise, Lattice going ANSI probably had something to do with Aztec doing the same thing. Trouble is, Aztec still hasn't figured out what prototypes are - and they've saved me a LOT of time. >Hoever, I think you should wait for Manx 4.1. to compare to >Lattice 5.0. Lattice did a disgusting thing with 5.0, and forced me to purchase the "Compiler Companion" with the update. I was upset enough about this to call Aztec to see if when 4.1 was going to be out. Answer: 2nd quarter of '89. 5.0 came out before Xmas of '88. I need ANSI features _now_, not three months from now. So guess who got my check? And when 4.1 comes out, I'll compare it to what Lattice is shipping _then_, not what they're promising in three months. Vaporware is always _going_ to be better than real product - at least until the vaporware gets here. Now, as for that "Compiler Companion". Several people have mentioned it. I think it sucks - and would rather not have had to purchased it. LMK is ok - and even lets you specify a file to search for default rules (which is why I'm using it). Other than that, they were a waste of disk space. All the little utilities are verbose, and don't really work very well together (nuts - you can't even feed the output of grep to itself in a usefull manner), except where they were force-fit. Whoever wrote them got the Unix tools, but didn't get the philosophy that makes them work well. Worse yet, those tools are bigger and slower (though sometimes not until I've recompiled with 5.0) than the pd versions on the fish disks. Finally, there's LSE: an editor that manages to be both bigger, slower & less powerfull than mg. Among it's sins are 1) understands vertical overscan, but not horizontal overscan; 2) isn't very configurable; 3) can't edit enough files; 4) only two windows, which must split equally; 5) no ARexx interface (even though the debugger has one!) 6) Not very well amigafied - at which point I gave up on it. While I'm at it, I'd like to point out that the debugger sorta sucks when it comes to "Amiga" interface. Opening windows for string requesters? SubMenus with two entries: "On" and "Off" (meaning it's faster to enter the keyboard command even when I've _already_ got the mouse in my hand)? Just like the Unix utilities, whoever did this seems to have gotten the look, but not the soul, of what the tools should be. <It's a good thing there are two C vendors for the Amiga. If there were only <one it's doubtful it'd be as good as the two are, although I do not <think either meets the standards of the cardinal IBM PC C-compilers. I don't use IBM C compilers; but Lattice 4.0 and later are better than the "pcc" shipped with most versions of Unix. And I agree that there being two compilers for the Amiga probably made that happen. <mike -- Il brilgue: les toves lubricilleux Mike Meyer Se gyrent en vrillant dans le guave, mwm@berkeley.edu Enmimes sont les gougebosqueux, ucbvax!mwm Et le momerade horsgrave. mwm@ucbjade.BITNET
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (04/06/90)
In <20994@eerie.acsu.Buffalo.EDU>, commike@procyon.cs.buffalo.edu (Alan Commike ) writes: >With the last set of fish disks, there is a third freely distributable >C compiler available. I was wondering if anyone has done any comparisons? I haven't seen NorthC yet, but it looks to me like a compilation of ZC, A68K, BLink, and some extra goodies. >I haven't heard much about pdc lately. Is it still being worked on? >What about A68k and Blink - are they both in their final revisions?? I don't know about all the efforts toward PDC, but I do know that Jeff Lydiatt has not done much with it since ZC showed up. A68K will never be in 'final revision', since Charlie is one of those folks that just has to keep twiddling with it, especially if someone says "Wouldn't it be nice if...". BLink is in a unique position. The freely distributable version will not be worked on further by the folks that originally wrote it, since it evolved into a Lattice product. This does not preclude someone else from taking the original BLink source, if available, and improving on it. -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
ews00461@uxa.cso.uiuc.edu (04/09/90)
PDC is available by anon ftp from uihub.cs.uiuc.edu in the amiga directory. Most of the work done in getting it to its latest revision was done by Lionel Hummel and Paul Petersen (I think that name is correct...) I believe PDC is *done* as far as Lionel was concerned. Last time I spoke with him, he said he was considering starting work on a NEW C compiler. I've not read this notesfile in a while, could someone summarize the freely distributable C compilers available for the Amiga ? I didn't know that PDC wasn't alone. Never heard of Zc or NorthC. If this has been covered recently, don't post... email... Eric W. Sink e-sink@uiuc.edu
gsgi_cif@uhura.cc.rochester.edu (Gregory Gibson) (06/07/90)
I want to learn C. Which C compiler would you buy, if you wanted a C compiler
for the amiga which would let you write some programs but not huge ones, like
an editor or Vlt. I know this is a hard question.
What is the difference between a C compiler, and the Professional package,
I guess is my question. I can't decide if I need the Profession Package
until I understand the difference between it and the more basic package...
Thanks - I appreciate the time it takes to relpy by e-mail...
--
Gregory Gibson
gsgi_cif@uhura.cc.rochester.edu or gsgi_ltd@uordbv.bitnet
UUCP: {decvax,harvard,ames,rutgers}!rochester!ur-cc!gsgi_cifJFS10@psuvm.psu.edu (06/07/90)
I have an old version of Lattice C that was given to me as a gift. I never would have spent the money on a langauge that is was planning to teach myself. Shortly after I got that compiler, 2 PD compiler became available. Now there are three PD C compilers. Szosobon C V1.01, PDC V3.33 and now DICE 2.00 by Matt Dillion. All are available by FTP, but I do not their exact location. Szosobon C (Zc) is available on a Fred Fish disk. I have used ZC and PDC. DICE is new. Zc does not support floating point math yet. The code it generates is a little bit larger than PDC. PDC does support floating point, but I have not been able to get it to work. I think that they are both very good products especially when you take price into consideration. Both are easier to use than Lattice and they also seem faster. The only problem with the PD compilers is that they require include files for the amiga specific routines. I use the ones from Lattice, but you can buy them from CBM for $20.00. I think I am going to buy them because they are upto date. ---------------------------------------------------------+ Jonathan Swaby | Computer Instructional Specialist | Center for Computing Assistance College of Liberal Arts | Penn State University | ---------------------------------------------------------+
GWO110%URIACC.BITNET@brownvm.brown.edu (F. Michael Theilig) (06/08/90)
On 7 Jun 90 13:19:17 GMT you said: [Stuff ...] > Shortly after I got that compiler, 2 PD compiler became >available. Now there are three PD C compilers. Szosobon C V1.01, PDC V3.33 and > now DICE 2.00 by Matt Dillion. All are available by FTP, but I do not >their exact location. Szosobon C (Zc) is available on a Fred Fish disk. >I have used ZC and PDC. DICE is new. Zc does not support floating point [More stuff...] There are FOUR Freely distributable compilers available. PDC 3.33, Sozobon C 1.01 (FF314), DICE 2.00, and NorthC 1.0 (FF340). Sozobon and NorthC are ported from the same compiler on the Atari ST, but will produce different .s files. They also product executable without adding anything else. PDC and DICE require Amiga.lib. Since I haven't gotten Amiga.lib yet, I haven't tried out these compilers. ZC (Sozobon) generates BIG code, but it's reasonably fast. NorthC generates smaller code (however still big), but the text output is *REAL SLOW*! The compiler front end for NorthC doesn't work quite right. A newer version of NorthC is scheduled fairly soon. PDC and DICE seem to generate smaller assembly source files than the other two. All four would be sufficient for learning C or just tooling around. >---------------------------------------------------------+ >Jonathan Swaby | >Computer Instructional Specialist | >Center for Computing Assistance College of Liberal Arts | >Penn State University | >---------------------------------------------------------+ ---- F. Michael Theilig - The University of Rhode Island at Little Rest GWO110 at URIACC.Bitnet GKZ117 at URIACC.Bitnet "Gooooood coffee."
hclausen@adspdk.UUCP (Henrik Clausen) (12/06/90)
In article <5066.275d1986@cc.curtin.edu.au>, Lynch_MJ@cc.curtin.edu.au writes: > In article <44589@eerie.acsu.Buffalo.EDU>, v117gv8r@ubvmsd.cc.buffalo.edu (Thomas E Burnett) writes: > > only 1 disk drive and 512K ram. > > Is there a PD version of C available. What do people think of > > commercial C packages that are available? Check out Dice on Fish 359 - is supposed to be compact, fast and efficient. > People that I know have used Lattice C (a commercial C-Compiler) have spent > more time trying to debug the compiler than they have programming!!! > So don't go near Lattice-C. You must've heard about V3.00 or something. I use 5.05 currently, and though I do hit compiler bugs at time, it's a real decent package. This objection to Lattice is completely unjustified. Have a nice day -Henrik | Henrik Clausen, Graffiti Data | If the Doors of Perception where cleansed, | | ...{pyramid|rutgers}!cbmvax! | Man would see Reality as it is - Infinite. | \______cbmehq!adspdk!hclausen___|_________________________________W. Blake___/