From: darren@zikzak.apana.org.au (Darren Brett Gower)
Newsgroups: bit.listserv.i-amiga
Subject: Re: Lattice upgrade (LONG!)
Date: 22 Jan 1993 02:28:44 +1100
Organization: Zikzak public access UNIX, Melbourne Australia
NNTP-Posting-Host: zikzak.apana.org.au

Ian BRADLEY <CSHD92IB@VAXA.ANGLIA-POLYTECHNIC.AC.UK> writes:

>Hi,

>I have lattice C, (SAS C) 5.10, but is it worth #100 to upgrade. The people at
>hisoft thought so, but then they are probably biased. I know about the
>on-line help, but what else is new.
>[...]

Ok, firstly the list of whats new (from the 'Whats new' in the manuals):

* extensive online help via amigaguide. Describes each utility, CPR, editor,
  library functions, diagnostic message description, compiler options;

* EMITS (an electronic mail through internet functionality that allows you
  to report bugs and receive help via Internet mail directly to/from the techs.
  Response generally happens within 24 hrs);

* New front end (lc has gone). 'sc' allows compilation of assembly, C and
  object (.o) files all on the one command line. Conversion utils are
  provided for version 5 makefiles and programs;

* Full ANSI compatibility (version 5 was not);

* 1.3 header files gone - 2.0 ones included (which are backward compat.);

* 'sc' loads AmigaDOS resident libraries which do all the jobs of the old
  'lc', 'lc1', 'lc2' and 'go'. This means they stay resident btw compiles
   unless memory is low (speed compiles);

* GSTs (these are kinda like the precompiled headers of version 5 but
  MUCH better - they stay resident so don't have to reload unless memory
  is low);

* scmsg: (a message browser which is linked to 'sc' and any editer via
  AREXX. It shows compile warns/errors in a window and you click to edit
  directly to the error...);

* new optimiser abilities (including peephole optimizer and inlining of
  functions and new global optimizations);

* much improved CPR to allow you to use general C structure for control;

* new options to get the compiler to add code which automatically extends
  your stack if it becomes low during a run;

* ability to produce a listing of which lines of your code were 'hit'
  during a run so you can test all code paths are getting exec'd the
  way you expect during a run;

* dynamic adjustment to low memory situations during a compile (it frees
  memory if it needs to);

* auto initialisation functions can be called before main(),
  auto termination functions can be called after you exit();

* reference to unnamed unions allowed;

* new #pragma tagcall for variable parameter stuff;

* other stuff ... :-);

--- END BLURB (which was not verbatim, but close...) ---

Now for my opinion:

It's *worth* it! :)

The compiler is easier to work with, while keeping the same structure as
you know with version 5. The new messages generated from 'sc' on errors are
much more helpful, and the documentation is first class. The online help is
something I don't _regularly_ use, but when I do it is a damn sight better
than having to try to find the manual page (although with the new design of
the manuals it isn't difficult ...).

The editor is a *little* better (it uses a file requestor! :-)) but is pretty
much unchanged.

Version 6 in general produces smaller and faster code (for instance a small
program of mine when recomiled  dropped from 9K to about 7.5K, not significant
but helpful none the less).

EMITS is *excellent*. I have used it extensively and I have always been
satisfied with the result (I can't say the same for dealing with Sydney
on a few occasions during verison 5, although they were ok I guess).

Be warned: If you have a floppy only system, the optimizer can only be used
under 2.0 (not that I would recommend such use anyway!). The system uses
multiple assignments to get the optimizer paths to work. It may work with
a 1.3 hack util that allows multi-assigns, I don't know.

Compiler speed (especially when using GST's) is *unbelievable* compared to
previous versions. Potentially no header files need be loaded after the
first compile, and all temporary files are *memory resident* if
system memory permits. This *greatly* speeds compiles.

As a general rule (I've mentioned memory a lot) I'd reckon about 2meg+
would be optimal, 1meg beneficial and 512K <blows rasberry>. The more the
better though (I have a flare for the obvious 8-)).

Overall - it's a *very* worthwhile investment.

regards,
Darren.
BTW: I am in no way affiliated with SAS or its subsiduaries. I *am*
a happy SAS customer....
-- 
+----------------------------+------------------------------------------+
| Darren Gower               | "I'd be careful who you call smart or    |
| - The Executioner          |  not smart.  Smart isn't knowing how to  |
| darren@zikzak.apana.org.au |  save six bytes.  Smart is knowing WHEN."|
|                            | - Peter Cherna,                          |
| Zikzak public access UNIX, |  Operating Systems Development Group,    |
| Melbourne, Australia.      |  Commodore-Amiga, Inc.                   |
+----------------------------+------------------------------------------+