Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!cbmvax!daveh
From: daveh@cbmvax.cbm.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: Getting smaller binaries
Message-ID: <1687@cbmvax.cbmvax.cbm.UUCP>
Date: Thu, 16-Apr-87 14:29:57 EST
Article-I.D.: cbmvax.1687
Posted: Thu Apr 16 14:29:57 1987
Date-Received: Sun, 19-Apr-87 08:40:59 EST
References: <235@rocky.STANFORD.EDU>
Distribution: world
Organization: Commodore Technology, West Chester, PA
Lines: 47

in article <235@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says:
> In article <1108@rpics.RPI.EDU> guilford@rpics.RPI.EDU (Jim Guilford) writes:
>>  I was thinking that a large part of binaries tends to be large chunks of
>>library code such as printf and its associated luggage. I was thinking that
>>it may not be too bad of idea to make most of these large "add-ons" into a
>>real amiga-style library, and then have all programs share it. 

> I was thinking along the same lines. I'm working on a Lisp compiler (a class
> project) for the Dec-20, and I was wondering how difficult it would be to
> port it to the Amiga. Then I started thinking along the lines of
> creating a "lisp.library," which would have all of the Lisp stuff and
> allow you to run Lisp "executables" without the use of the interpreted Lisp
> environment. 
>
> Ali Ozer, ali@rocky.stanford.edu

Maybe great minds really do think alike :-).  It seems many moons ago I was
involved in a lengthy discussion about just this on Compuserve.  Someone
was even able to produce a very preliminary version of a c.library, which
was limited and a little buggy, but worked otherwise.  The hardest part
(once you master the linking bits to create a proper library, something
I haven't really tried yet myself) seems to be insuring that everything in
library functions is allocated on a per-call basis (I guess dynamic
allocation passed via calls or maybe stack allocation would work OK) or
a single, global value attached to the library base structure for that
particular library.

On a similar note, I've been very gradually bringing up a LISP environment,
which is currently a very remote decendent of a thing I've been fiddling
around with since I started in on a DEC-20 (in Pascal) back in school.  I
considered the idea of a lisp.library, not so much to make a stand-alone
LISP interpreter that much better, but because a reasonable LISP-like
language can function as a general purpose macro language for many different
applications.  Some Emacs (Gosling's, GNU) have imbedded LISPish languages
used for extending the basic command set, as do various other tools like
some CAD packages.  Most LISP implementations count on a global symbol
table, but since everything's in this table, a simple descriptor could be
passed to a general lisp library, allowing the actual functions to be
independently accessable.  All global information could exist as LISP
objects in the individual environments; all the functions might need is a
bit of stack space for local variables.  I really haven't had time to
follow up this idea that far, but I've been interested in it, and its good
to hear others thinking the same things.
-- 
Dave Haynie     Commodore-Amiga    Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh
"The A2000 Guy"                    BIX   : hazy
"That's all she wrote"  -J. Strapp