bga@pnet51.orb.mn.org (Bruce Albrecht) (07/05/90)
I don't want to start any compiler wars, but I am looking for comments or
knowledge about C/C++ compilers for the Amiga. From what I understand, both
Aztec and Lattice C are now ANSI compliant, with SDB. It used to be the
case that code for Aztec could be compiled on Lattice, but the converse was
not always true. Is that still the case? Is the Lattice C++ compiler based
on C++ ver. 1, or C++ ver.2? Can you compile any ANSI C program if you have
the C++ compiler, or do you really need C and C++? What are the relative
speeds for the Aztec C, Lattice C, and Lattice C++? Are any of the PD C
compilers good enough to that I can skip buying a commercial one?
UUCP: {amdahl!bungia, uunet!rosevax, crash}!orbit!pnet51!bga
ARPA: crash!orbit!pnet51!bga@nosc.mil
INET: bga@pnet51.orb.mn.orgdaveh@cbmvax.commodore.com (Dave Haynie) (07/06/90)
In article <2796@orbit.cts.com> bga@pnet51.orb.mn.org (Bruce Albrecht) writes: >From what I understand, both Aztec and Lattice C are now ANSI compliant, with >SDB. Lattice and Aztec are both claiming to be ANSI compliant. I don't have the new Aztec yet, but Lattice does appear to be ANSI-enough such that I can't tell the difference. >It used to be the case that code for Aztec could be compiled on Lattice, but >the converse was not always true. Is that still the case? There were often cases where some degree of conversion was necessary. Much dependend on the program. For instance, I originally wrote DiskSalv in Lattice 3.03. When I got the Manx compiler, I easily converted it over (so I could use SDB). When I got Lattice 5.0, I converted a much different DiskSalv back in a couple of hours, with all the ANSIfication included. On the other hand, I have never been able to get SetCPU to run under Lattice (though I never considered it worth more than a few hours of work to even try). With the new versions, you still have to say "maybe". If you write a pure ANSI program in Lattice, it should compile directly in Manx. However, Lattice has some non-ANSI functions in its libraries, along with the ANSI functions. Manx probably does too. So there's one point where you may need some conversion. Non-standard things like chip memory storage classes may differ too. The ANSI committee produced rules for dealing with this kind of thing, but there's no requirement that two different companies would necessarily do these kinds of things the same exact way. In any case, they should be far more interchangable than Lattice 3.03 was with Manx 3.6a... >Is the Lattice C++ compiler based on C++ ver. 1, or C++ ver.2? As I recall, the Lattice V1.00 cfront was based on AT&T cfront 1.1a. >Can you compile any ANSI C program if you have the C++ compiler, or do you >really need C and C++? No. C++ came before ANSI C. While many of the ideas in C++ were adopted by C, such as the new function parameter declarations, there are still very likely some differences. >What are the relative speeds for the Aztec C, Lattice C, and Lattice C++? Like I said, I don't have the new compiler, but the time based on the ones I've used go on this timeline: -+------------+--------+---------+-----------+----------------+---------+- | | | | | | | A Sneeze Manx Lattice A Trip to Lattice Lattice Out for 3.6a 5.0 the Coffee 3.03 C++ 1.0 a cold Machine Beer One of the strengths of both the Lattice 5.0 and the Manx 3.6a is that they can be made resident (Lattice in the traditional 1.3 "resident" fashion, Manx via the clever "rez" utility). >UUCP: {amdahl!bungia, uunet!rosevax, crash}!orbit!pnet51!bga -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM
sorber@motcid.UUCP (Russell C. Sorber) (07/08/90)
daveh@cbmvax.commodore.com (Dave Haynie) writes: >>What are the relative speeds for the Aztec C, Lattice C, and Lattice C++? >Like I said, I don't have the new compiler, but the time based on the ones >I've used go on this timeline: > -+------------+--------+---------+-----------+----------------+---------+- > | | | | | | | >A Sneeze Manx Lattice A Trip to Lattice Lattice Out for > 3.6a 5.0 the Coffee 3.03 C++ 1.0 a cold > Machine Beer Are these compile times or speeds of the executable program? More explanation is necessary for this to be meaningful. As for one of the original posted questions about buying or going with a PD compiler, a PD product is not equivalent to a purchased product for several reasons (even if the code generation was equivalent, which from what I observe, it isn't). One must also consider 1) Who will fix the bugs first? Someone who is paid to do it for eight or more hours/day or someone who does it in their spare time. 2) What is the technical support plan for the PD product? What happens when the author is on vacation or gets tired of answering questions? What's the documentation like? 3) What is the upgrade/improvement plan on a free product? Does it come with an assembler, a symbolic debugger, 68020 or 68881 support? I guess it depends how much time you have available to mess around with the added problems of PD. If I was building a commercial product, or even a serious amateur, though. I don't think I would mess around with PD compiler tools for the same reasons I choose to buy the hardware instead of make it myself. Russ Sorber Software Contractor Currently at Motorola Cellular Div.
markv@kuhub.cc.ukans.edu (07/09/90)
In article <13082@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > In article <2796@orbit.cts.com> bga@pnet51.orb.mn.org (Bruce Albrecht) writes: >>From what I understand, both Aztec and Lattice C are now ANSI compliant, with >>SDB. > > Lattice and Aztec are both claiming to be ANSI compliant. I don't have the > new Aztec yet, but Lattice does appear to be ANSI-enough such that I can't > tell the difference. Lattice is completely ANSI compliant except for tri-graph and locality support (there is no tri-graph support, locality support is incomplete) and possibly (according to Lattice, I've never had problems) some "complex obscure declaration sequences". >>It used to be the case that code for Aztec could be compiled on Lattice, but >>the converse was not always true. Is that still the case? > > There were often cases where some degree of conversion was necessary. Much > dependend on the program. For instance, I originally wroteDiskSalvin Lattice > 3.03. When I got the Manx compiler, I easily converted it over (so I could > use SDB). When I got Lattice 5.0, I converted a muchdifferent DiskSalv back > in a couple of hours, with all the ANSIfication included. On the other hand, > I have never been able to get SetCPU to run under Lattice (though I never > considered it worth more than a few hours of work to even try). Hmm, what problems do you have with SetCPU? IF you stick to ANSI standard functions and Amiga standard functions, everything should be portable without a whole lot of problems, on the other hand both compilers, especially Lattice, offer a pretty good set of extra functions that are nice to use, but if you do, well... >With the new versions,you still have to say "maybe". If you write a pure ANSI > program in Lattice, it should compile directly in Manx. However, Lattice has > some non-ANSI functionsin its libraries, along with the ANSI functions. Manx > probably does too. So there's one point where you may need some conversion. > Non-standard things likechip memory storage classes may differ too. The ANSI > committee produced rules for dealing with this kind of thing, but there's no > requirement that two different companies would necessarily do these kinds of > things the same exact way.In any case, they should be far more interchangable > than Lattice 3.03 was with Manx 3.6a... Definitely, my expirince with Lattice -vs- what I have seen about Manx 5.0 is Lattice is a little more picky about keyword ordering for non-standard features, but other differences are easy to deal with. >>Is the Lattice C++ compiler based on C++ ver. 1, or C++ ver.2? > > As I recall, the Lattice V1.00 cfront was based on AT&T cfront 1.1a. Lattice C++ is based on CFront 1.2 (not 1.1). As of six months ago Lattice had plans for both a native code and a 2.0 level product. >>Can you compile any ANSI C program if you have the C++ compiler, or do you >>really need C and C++? > No. C++ came before ANSI C. While many of the ideas in C++ were adopted > by C, such as the new function parameter declarations, there are still very > likely some differences. But, the Lattice C++ package includes a full implementation of the Lattice 4.0 level compiler (with support for 100 char identifiers added) so you HAVE a working *mostly* ANSI C Compiler. >>What are the relative speeds for the Aztec C, Lattice C, and Lattice C++? > > Like I said, I don't have the new compiler, but the time based on the ones > I've used go on this timeline: > > -+------------+--------+---------+-----------+----------------+---------+- > | | | | | | | > A Sneeze Manx Lattice A Trip to Lattice Lattice Out for > 3.6a 5.0 the Coffee 3.03 C++ 1.0 a cold > Machine Beer > > One of the strengths of both the Lattice 5.0 and the Manx 3.6a is that they > can be made resident (Lattice in the traditional 1.3 "resident" fashion, Manx > via the clever "rez" utility). That scale is about right. You had better have a LOT of memory (like over a meg FREE) if you want to use C++ or Lattice's global optimizer. Making the compiler resident (with Lattice remember you need to Resident LC1 and LC2 besides LC) you get a HUGE time gain when doing large multi-file makes. Putting QUAD: in RAM: helps, and doens't eat much memory since you only have one .q file at a time. Some features about Lattice I like is is is possible to code interrupt servers and handlers in C. And now Resident libraries (.library type libs) can be done in C via some special keywords, some Blink tricks, and a few special object modules. Lattice's support for residentable programs and some guru trapping and background processes is nice too. I like CPR also, although it still has some problems. >>UUCP: {amdahl!bungia, uunet!rosevax, crash}!orbit!pnet51!bga > -- > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "I have been given the freedom to do as I see fit" -REM -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
daveh@cbmvax.commodore.com (Dave Haynie) (07/17/90)
In article <24892.26985ff4@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >>>Is the Lattice C++ compiler based on C++ ver. 1, or C++ ver.2? >> As I recall, the Lattice V1.00 cfront was based on AT&T cfront 1.1a. >Lattice C++ is based on CFront 1.2 (not 1.1). As of six months ago >Lattice had plans for both a native code and a 2.0 level product. Well, every time I run it, it claims to be based on V1.1a. Unless the cfront program is lying to me, that would be pretty conclusive, eh? >But, the Lattice C++ package includes a full implementation of the >Lattice 4.0 level compiler (with support for 100 char identifiers >added) so you HAVE a working *mostly* ANSI C Compiler. What they left out was documentation on the V4.x compiler, because they obviously don't intend to support the use of the C compiler as part of the C++ distribution. Like, when/if the single phase compiler is written, the LC1 program, at least, disappears from the Lattice distribution. >That scale is about right. You had better have a LOT of memory (like >over a meg FREE) if you want to use C++ or Lattice's global optimizer. >Making the compiler resident (with Lattice remember you need to >Resident LC1 and LC2 besides LC) you get a HUGE time gain when doing >large multi-file makes. Putting QUAD: in RAM: helps, and doens't eat >much memory since you only have one .q file at a time. Absolutely. The cfront program also needs a very large stack, I usually give it 1/2 a meg or so. It'll run with a much smaller one, but it tends to crash much more. >Mark Gooderum Only... \ Good Cheer !!! -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM