spencer@well.UUCP (Randal Spencer) (11/17/86)
A lot of people been asking about the Resident command. Now I am sure
that this command was written for people like me who have the Alegra
board (or some of those early developers) who only have 1 meg. If you
have 512K you don't have enough room to be playing around like this.
And if you have 2 or more meg you should be using Perry's Ram-Disk.
Here then, is a spoon feeding for the curious. A sure fire way to get
the resident command to work for you. Make a Workbench disk with the
following 3 files in the S: directory. The get out your gamma release
ToolKit disk and copy from ToolKit:L/CLI-Resident to
WorkBench:L/CLI-Resident. And put the resident command in the C:
directory. The files will set up a special CLI that knows how to use
resident commands, then it will call that CLI, but will put a wait
command before it, so that the first CLI will exit before the new
Resident-CLI starts up. That makes the New-CLI task 1, which is just
neater. You don't want the original CLI around because it don't know
about resident commands. I use the "from" command when calling NewCLI
so that the Resident-CLI will take commands from it's own startup
file. I use that window size on the Resident-CLI so that when I LoadWB
I can see the disks (another advantage of more memory, using both user
interfaces), also so that I can move the WorkBench screen around with
the mouse. Here are the files for S:
s:startup-sequence
resident CLI l/cli-resident replace
run wait 3+
newcli con:0/8/540/192/Resident-CLI from s:startup-cli
endcli > nil:
s:startup-cli
Execute res
; whole bunch of commands go here! If you run PopCLI after executing res
; then all the CLI's generated from PopCLI will have the resident structure!
LoadWb
s:res
resident type c:type
resident run c:run
resident rm c:delete
resident res c:resident
res path c:path
res newcli c:newcli
res mv c:rename
res mkdir c:makedir
res list c:list
res info c:info
res ex c:execute
res endcli c:endcli
res ed c:ed
res dir c:dir
res copy c:copy
res cd c:cd
res assign c:assign
echo "Done building Resident structure"
date > sys:now
The order the commands are listed in sets them up for my prefered names.
MV is much easier to type then RENAME. I like the reasoning behind the
command names under Unix. Short but not single letter, not confusable
with other words of different meaning.
To see the commands that you have in residence type "res". If you
accidently enter the resident command twice on the same command it
will enter the same named command twice. Wasteful. Also the res
command will tell you the "use count". Type newcli and watch the CLI
use count increase by one. You cannot delete an command with a use
count and you cannot call a command with a use count of -1 under the
gamma release, but you sure can under beta 4. So don't try to execute
FileHandler or Restart or even CLI, I get a real fast Guru when I do.
Enjoy, and if you have any easy questions, I will be glad to try my hand,
if nothing else, I do use the command alot.
I am currently working on a command file to put all the Startup-Sequence
commands on the disk first. I have one that did it in the way I thought
the Amiga would read the disk, but there is no speed up over just
"copy all"ing the files all to a new disk. So I am playing around. I am
glad Matt has taken an interest in this topic. He might know what need
be where, I am just stabing in the dark right now.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 ...well!spencer
I N F I N I T Y spencer@USCVAXQ.bitnet
Now working for |||||||||||::::... . . spencer@usc-oberon.arpa
But in no way |||||||||||||||::::.. .. . .
Officially representing ||||||||||||:::::... ..
s o f t w a r e
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-burnette@sas.UUCP (11/23/86)
The resident cli seems to have one fatal flaw: RUN doesn't know about resident commands. For example, if you enter resident md c/makedir and then try run md the md command will not be found. This occurs even in execute files started by the run command. For example: run execute foo where foo contains an 'md' command. Other than that, resident commands work very nicely. There is a noticable speed improvement over executing the commands from ram: (instant versus a fraction of a second). Then of course there is the memory savings of not having two copies of a program in memory. Both the Lattice and Manx compilers support base register relative data addressing now so it would seem possible for us to come up with a scheme for resident commands that takes advantage of that feature. When you make a command resident the code and data sections could be loaded into memory. Then, when someone executes the command, a copy of the data section could be made; the bss part could be allocated and initialized; a base register could be pointed to the top; and then the code that is already in memory could be executed. The bss section will need to be allocated at the end of the data section, I think. The only problem I see is that Lattice and Manx assume different base registers for the data. We either have to detect somehow which register to use or get the two companies to agree on a standard register (perhaps some register in between the two they use now :-).
hamilton@uiucuxc.UUCP (11/26/86)
burnette@sas says: > The only problem I see is that Lattice and Manx assume different base > registers for the data. We either have to detect somehow which register > to use or get the two companies to agree on a standard register (perhaps > some register in between the two they use now :-). it doesn't matter which register is used as the base register, since each compiler's startup code will take care of loading it. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
eric@cti.UUCP (Eric Black) (11/30/86)
In article <172200005@uiucuxc> hamilton@uiucuxc.CSO.UIUC.EDU writes: > >burnette@sas says: >> The only problem I see is that Lattice and Manx assume different base >> registers for the data. We either have to detect somehow which register >> to use or get the two companies to agree on a standard register (perhaps >> some register in between the two they use now :-). > > it doesn't matter which register is used as the base register, since >each compiler's startup code will take care of loading it. Well, yes, but since the rest of their calling conventions are so close, this might be all you need to be able to link together objects created by both compilers (modulo the object file format differences, which Manx can deal with). Only one startup routine gets run, and only at startup, not between function calls. Why would I want to do that? Example: Matt Dillon's "mylib"; I'd like to use it with Manx compiling in 32-bit mode. There are undoubtedly other gotchas in there that will preclude doing this generally, but library utilities that are distributed in object form only could then be usable by people with either compiler, if they are carefully written. I think. -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!cti!eric