🚀 go-pugleaf

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~