spencer@usc-oberon.UUCP (Randy Spencer) (06/17/86)
> > 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... > > Dan Green ARPA: hsgj%vax2.ccs.cornell.edu@cu-arpa.cs.cornell.edu > 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... Sigh! I had such dreams of Fred's CC running without all the grinding... -- ============================================================================== ....I disclaim everything, I had nothing to do with it, it's not my fault!.... Randal Spencer - DEC, {amiga} Consulting - University of Southern California phone: (213) 743-5363 Arpa:Spencer@USC-ECL,USC-Oberon Bitnet:Spencer@USCVAXQ UUCP:...up to you!{{decvax,ucbvax}!sdcrdcf,scgvaxd,smeagol}!usc-oberon!spencer Home: 937 N. Beverly Glen Bl. Bel Air California 90077 (213) 470-0428 ------------------------------------------------------------------------------
dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/19/86)
Ya, either put LC1 and LC2 in ram (makes them extremely fast since most of the compile time is taken loading the executable anyway), or give yourself a huge number of buffers (but only if you have the ram for it). Q to amiga: Care to comment on the buffering scheme you'all are using? -Matt
cc100jr@gitpyr.UUCP (Joel M. Rives) (06/20/86)
In article <8606191919.AA13745@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > Ya, either put LC1 and LC2 in ram (makes them extremely fast since >most of the compile time is taken loading the executable anyway), or give >yourself a huge number of buffers (but only if you have the ram for it). > I have tried placing LC1 and LC2 in ram. It works fine and fast (assuming 512K). However, there is one problem down the road to be aware of. Should you decide to link the newly created object module while LC1 and LC2 are still in ram, you will find that the system crashes due to a lack of memory. Because of this, I use two different methods depending upon whether I wish to do a straight compile and link or will be compiling a number of object modules and linking them together later. In either case, I load LC1 into ram when my C disk boots. Since a large portion of error detection occurs in the first phase of the compiler, LC1 is used more often than either LC2 or the linker. As an aside, I was not aware - until a couple of days ago - that any- thing loaded in ram via copy <fileid> to ram:<fileid> can be invoked without the ram: path extension. Joel Joel Rives USMAIL: Georgia Insitute of Technology, Atlanta Georgia, 30332 USENET: gatech!gitpyr!cc100jr BITNET: gatech!gitvm1!cc100jr "Remember, no matter where you go, there you are!" << Buckaroo Banzai >> -- Joel Rives USMAIL: Georgia Insitute of Technology, Atlanta Georgia, 30332 USENET: gatech!gitpyr!cc100jr BITNET: gatech!gitvm1!cc100jr "Remember, no matter where you go, there you are!" << Buckaroo Banzai >>
daveh@cbmvax.UUCP (06/24/86)
> As an aside, I was not aware - until a couple of days ago - that any- > thing loaded in ram via copy <fileid> to ram:<fileid> can be invoked without > the ram: path extension. If you do what you mentioned above, you won't need the RAM: name because you'll be executing the version of the program in your current directory, not in the RAM: device. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh A quote usually goes here, but its currently being rennovated. These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
acs@amdahl.UUCP (Tony Sumrall) (06/25/86)
In article <1884@gitpyr.UUCP> cc100jr@gitpyr.UUCP (Joel M. Rives) writes: > As an aside, I was not aware - until a couple of days ago - that any- > thing loaded in ram via copy <fileid> to ram:<fileid> can be invoked without > the ram: path extension. > > Joel > Joel Rives > > USMAIL: Georgia Insitute of Technology, Atlanta Georgia, 30332 > USENET: gatech!gitpyr!cc100jr > BITNET: gatech!gitvm1!cc100jr > To the best of my knowledge this is not true under 1.1. What *is* true is that the current directory is searched prior to C:. Could this be your situation? -- Tony Sumrall ...!{ihnp4,hplabs,seismo,sun}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
cc100jr@gitpyr.UUCP (Joel Rives) (06/25/86)
In article <3402@amdahl.UUCP> acs@amdahl.UUCP (Tony Sumrall) writes: >In article <1884@gitpyr.UUCP> cc100jr@gitpyr.UUCP (Joel M. Rives) writes: > >> As an aside, I was not aware - until a couple of days ago - that any- >> thing loaded in ram via copy <fileid> to ram:<fileid> can be invoked without >> the ram: path extension. >> >To the best of my knowledge this is not true under 1.1. What *is* true is >that the current directory is searched prior to C:. Could this be your >situation? >-- Nope. My current directory at the time is a subdirectory on df1:. I have an Execute file called make which is located in ram:. I can type execute make and it works! Ya got me!?! -- Joel Rives USMAIL: Georgia Insitute of Technology, Atlanta Georgia, 30332 USENET: gatech!gitpyr!cc100jr BITNET: gatech!gitvm1!cc100jr "Remember, no matter where you go, there you are!" << Buckaroo Banzai >>
eric@chronon.UUCP (Eric Black) (06/27/86)
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
mykes@3comvax.UUCP (06/27/86)
A friend at Amiga kept telling me "you gotta use 1.2, it's got the 'RESIDENT' command! Resident is a command that makes the CLI keep any commands you want resident in LoadSeg() form, and the CLI simply jumps to it to run it..." Oh boy, I thought, this is what we really need, I would love to keep the whole Manx system in Ram that way... So my friend at Amiga tells me it's on the 1.2 beta 2 disk, on the SW Tools disk in the c: directory. Sure enough, it is not there, but it does exist and soon we will all have it! Now the kicker: it is not known whether RESIDENT works with any programs other than the CLI "companions" like CD and DIR and LIST, et al. So here's a suggestion for Matt Dillon, who's the current keeper of the shell: Modify your shell so that it keeps any program resident in LoadSeg() form. The only things that need a little bit of work are how to pass command line arguments to the program when you want to run it (should be quite simple), and the initialized data hunks need to be copied and restored every time the program is run, in case the program mashes its initialized data. Doing this would allow for the compiler, assembler, and linker to all be resident in RAM on a 512K machine comfortably (remember, you don't need a copy in RAM disk plus the one that's running anymore), as well as c.lib or c32.lib. Sorry you Lattice users, but you would only be able to fit LC1 in RAM because it is such a memory/disk pig.