Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!husc6!panda!genrad!decvax!decwrl!ucbvax!PAVEPAWS.BERKELEY.EDU!dillon
From: dillon@PAVEPAWS.BERKELEY.EDU.UUCP
Newsgroups: net.micro.amiga
Subject: Re: Question about Alink
Message-ID: <8605142327.AA13269@pavepaws>
Date: Wed, 14-May-86 19:27:37 EDT
Article-I.D.: pavepaws.8605142327.AA13269
Posted: Wed May 14 19:27:37 1986
Date-Received: Fri, 16-May-86 05:45:50 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 78


	The problem isn't with Alink....  My guess is Lattice didn't put
together their library correctly.

NOTE: ********* When I talk about libraries in this message, I'm talking about
LINK libraries.... the things you specify in  ALINK, NOT run-time libraries.

* What is a Library

	A Library is made up of any number of object files.  If your source file
makes a call to a function in a library, the entire object file that function
resides in is then picked out of the library and included.  Here's an example:

**************
source file:
	open(..)
	write(...)

library:  (This is ONE library)
	-------- object module 1 -------
	open  
	read
	write
	close
	-------- object module 2 -------
	printf
	sprintf
	-------- object module 3 -------
	fopen
	 . .   etc.....
**************
	Now, you source program calls open() and write(), So object module 1
will be linked in as part of the executable (the ENTIRE object module 1).
Additionaly, if a routine in an included object module makes a call to another
object module, the other object module is included also.  So if open() made
a call to  printf() (for some strange reason), then object module 2 would also
be included, even though you didn't call  printf() from your source program.

	The same goes to cross-library calls.  If open() made a call to, say
Lock(), which resided in a different (but also specified in ALINK) library, 
then the particular object module Lock() exists in would also be linked into
the executable.

WHERE ALINK WENT WRONG

	Amiga libraries are nice in that you simply have to pile object files
together, but this method of doing things leaves much to be desired.  For one,
nowhere is there a sorted names list.  Alink must seek around all over the 
library to find named routines and object modules.  It seems to me that it 
would have been very simple to modify the library format to make Alink go 
faster.  How often do you make libraries?  Even if you do create libraries
frequently, the command to put them together in a better format would take
no longer than the appending one object file on another anyway. 

	Additionaly, Alink takes too much memory.... it really is a hog. On
my 512K Amiga, I can barely have my modem program running while doing an
Alink.

	Alink is slow.  It shouldn't be.  I see no reason for it to be slow.
A compiler, yes, An assembler, maybe, but a linker? no way.

WHERE LATTICE WENT WRONG

	It's Lattice's fault that the executable's are so big.  I don't know
who the idiot was over there allowed it to be released in such a state.  It's
probably no single person's fault, but it seems just plain STUPID.... I doubt
it would take more than 40 hours programming to fix the problem.  There are
two possibilities that I can think of:

	1) Lattice chunked too many functions in it's object files before
	   putting them together to form the library

	2) Lattice has cross links from one object file to another causing
	   massive amounts of inclusion at link time of routines which 
	   would otherwise not be used.


						-Matt