Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!uwm.edu!wuarchive!kuhub.cc.ukans.edu!markv From: markv@kuhub.cc.ukans.edu Newsgroups: comp.sys.amiga.tech Subject: Re: Commercial C/C++ compilers Message-ID: <24892.26985ff4@kuhub.cc.ukans.edu> Date: 9 Jul 90 15:44:03 GMT References: <2796@orbit.cts.com> <13082@cbmvax.commodore.com> Organization: University of Kansas Academic Computing Services Lines: 106 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~