Path: utzoo!mnetor!uunet!cbmvax!rutgers!mcnc!rti!sas!toebes
From: toebes@sas.UUCP (John Toebes)
Newsgroups: comp.sys.amiga
Subject: Re: Gadgets question
Message-ID: <330@sas.UUCP>
Date: 2 Feb 88 14:06:26 GMT
References: <4830003@hpiacla.HP.COM> <280@draken.nada.kth.se>
Organization: SAS Institute Inc.,Cary NC,25712
Lines: 48

In article <280@draken.nada.kth.se>, drs-ano@duvan.nada.kth.se (Gunnar Nordmark) writes:
> I have had this problem with lc2 many times. lc2 doesn't load because there
> isn't a sufficiently large memory chunk left. It needs at least 88K of
> *continious* memory to load.
> 
> All I can say is that if lc2 was divided into small hunks of code that could be
> loaded into different parts of memory, (like almost every other large program),
> none of us would have this stupid problem.
> 
> Personaly I suspect the *reason* that lc2 (and lc1) contain these truly HUGE
> code hunks is that Lattice want's to press the limits of certain compiler
> benchmarks. (Programs with few large hunks loads slightly faster than those
> with many small hunks).
> I wonder how many microseconds they gained with this approach :-)
>   -- Gunnar Nordmark --         NORDMARK@vaxkab.lne.kth.se

:-) Nice try but no cigar :-)

There are several reasons that LC2 (and LC1) is loaded as two contiguous chunks.

1) By loading as several separate chunks, memory BECOMES MORE FRAGMENTED
   whenever you run a compile in the background (think about it).  Since
   many developers tend to do editing while running several compiles
   (rebuilding a project) it is important that the compiler be able to
   continuously load.  From my tests with Hack (a 180K contiguous chunk) I
   have been able to load the contiguous version MANY more times than the one
   broken up into 64K and even 16K chunks.  If someone has some real life
   practical statistics on the Amiga (not theoretical - everyone has that)
   with multiple programs interacting that prove otherwise I would be happy
   to see them.  Remember that were are dealing with a multi-tasking machine
   and some programs were intended to be run while others are around.

2) By keeping the code ina single chunk it is significantly smaller as all
   subroutine calls can be done through 16 bit relative BSrs.  Breaking the
   code into 2 40K chunks adds almost 4K to the in memory image (by increasing
   the size of all calls from 4 to 6 bytes as well as 8K of relocation
   overhead.  Most people want the compiler to take up less disk space,
   not more.

3) As for compiler load speed, that is for people to decide.  The current
   compiler loads noticibly faster than the 3.10 version, something that
   makes a difference when developing a product.  It is our intention to
   produce a quality professional C development environment on the Amiga.

/*---------------------All standard Disclaimers apply---------------------*/
/*----Working for but not officially representing SAS or Lattice Inc.-----*/
/*----John A. Toebes, VIII             usenet:...!mcnc!rti!sas!toebes-----*/
/*------------------------------------------------------------------------*/