Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!harvard!ut-sally!pyramid!chronon!eric
From: eric@chronon.UUCP (Eric Black)
Newsgroups: net.micro.amiga
Subject: Re: Locking LC1  {was Kermit, also Workbench Suggestion}
Message-ID: <309@chronon.chronon.UUCP>
Date: Thu, 26-Jun-86 20:07:27 EDT
Article-I.D.: chronon.309
Posted: Thu Jun 26 20:07:27 1986
Date-Received: Sat, 28-Jun-86 01:41:26 EDT
References: <469@batcomputer.TN.CORNELL.EDU> <415@cbmvax.cbmvax.cbm.UUCP> <416@usc-oberon.UUCP>
Reply-To: eric@chronon.UUCP (Eric Black)
Organization: Chronon Computer Corp., Mtn. View, CA
Lines: 36

In article <416@usc-oberon.UUCP> spencer@usc-oberon.UUCP (Randy Spencer) writes:
>[ somebody said ]:
>> [ Dan Green said ]:
>> > The dream is whether these could be "locked" in so that they would never
>> > have to be read from disk again, but could be memory resident.  I have
>> > noticed that the Amiga *does* do this to some extent - If you do a lot
>> > of copies, for example, it only reads the copy program in once.  It appears
>> > that the "locking" only exists for the last file read...
>
>> If the time of loading becomes a critical factor, and you don't want to store
>> anything in the RAM disk, you could first run the LC1 pass on everything,
>> producing ".q" files, then run the LC2 pass, which will remove the ".q" and
>> create ".o" files.  This way, each of the compiler passes would remain in
>> memory as long as needed.
>
>Trying to write a simple batch file to do this proved unfruitful.  It seems
>to load lc1 in everytime, though copy will stay locked in the machine...

Is this not actually a case of buffering in the trackdisk device?  The
copy command is small enough to fit in the buffers allocated, so running
it a second time does not require actually going to the disk.  LCn are
much bigger, and reading the first part of them clobbers the end of them
which might otherwise not have required re-reading.

Given enough memory, with 1.2 you can change the number of track buffers
so that LC might fit.  

This still does not address the problem of having two copies of the
compiler in memory, one in "hunk" load module format, and one in
68000-code format.  Sure would be nice on a multitasking machine to
be able to share text segments...  It does, however, offer a practical
improvement in load speed.

-- 
Eric Black   "Garbage In, Gospel Out"
UUCP:        {sun,pyramid,hplabs,amdcad}!chronon!eric