bryce@COGSCI.BERKELEY.EDU.UUCP (06/02/87)
[] in article <> page@ulowell.cs.ulowell.edu (Bob Page) insinuated: >---- > ...etc. First, Dan, you should not be condoning (directly or indirectly) > the use of RESIDENT > ..Bob (Committee to Stamp Out Public RESIDENT Usage) WOAHH!!!! Don't abuse my goldfish!!! :-) :-). I use and LOVE resident (more on that later) >---- > you should not be condoning (directly or indirectly) > the use of RESIDENT, as it is broken. > PS Or do you CBM'ers have a new RESIDENT command that actually works? RESIDENT is limited, but NOT broken. It works *wonderfully* for what it was designed for, BCPL. It is true that it cannot make BSS hunks and it is true that the code must be REUSABLE and REENTRANT; but these are irrelevant to the commands that need to be made RESIDENT. Limit yourself to the commands in c: and you will be fine. (The standard C: directory, that is. Mine is very nearly 100% foreign. With one exception they all are fully RESIDENT compatible) Or, get the version of RESIDENT that KNOWS if a program is going to work. (more on THAT later) RESIDENT, for those with "enquiring" minds, is a command and associated CLI that can load a executable, like "LIST" once and leave it in memory. When it is executed is is run IN PLACE. When the command is used multiple times the SAME code segment is used, in place. This is superior even to a RAM disk. Since no copying is done, it's faster and takes up less memory. (only one copy is needed at a time) -> RESIDENT is the best thing since sliced bread (with goldfish garnish) :-) <- Novice users especially should use RESIDENT, so they get addicted to how fast it is. >---- >Second, regallar (sic) Amiga owners don't >have the RESIDENT command. Not legally, anyway. Well, gosh, I'm one of those 'irregular' Amiga owners who got it legal-like. Perhaps C-A could say something official-like for the rest of the world's conscience. BTW: resident was initially released on a disk with no distribution restrictions printed on it, and it does not contain a copyright notice. For reasons other that the one above I have been working on a "RESIDENT". Beat on me hard enough and I will finish and release it. Via the heavy use of AI and Magic it can determine if a program is suitable to be made RESIDENT and give a warning if not. Some programs can even TELL my RESIDENT about themselves with the aid of a hunk-extension that I have toyed with. A programmer can define the minimum stack and preferred stack sizes for an executable. A flags long provides bits for "REENTRANT" and "REUSABLE". However; This really skirts the issue, as the "RESIDENT" command needs the "cli-resident" file to be meaningful. That is probably imbedded heavily with BCPL magic, not really possible to recreate without knowing what it does. (Scott, break out the MCC dissassembler...) ------------- Ack! (NAK,EOT,SOH) |\ /| . {o O} . bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce ( " ) U Single tasking? Just say *NO!*
page@ulowell.cs.ulowell.edu (Bob Page) (06/03/87)
This is about 100 lines long, but I really did cut where I could. Back in November I wrote an expose on the dangers of RESIDENT. Here is a portion of what I posted. + Message-ID: <790@ulowell.UUCP> + Date: 27 Nov 86 17:20:22 GMT + + Ahem. The CLI-resident version of CLI doesn't make a copy of the + initialized data segments. Programs share both code AND data. If I + have any initialized data that later gets changed, the next time + it gets run you'll get the last value before exiting. And Even Worse + is that two invokations will use the same variables. Checksumming + would defeat this - the CLI should be smart enough to make a copy + of the data - or each program would have to have special startup + code that copied the data to a safe place. The first solution is + much easier and safer, except for one thing: + + The RESIDENT command essentially does a LoadSeg() allocating + BSS hunk space as well. Then the CLI-resident just USES THAT + SEGMENT LIST directly. This means the whole resident idea is + useless unless you have a program that allocates its own BSS and some + space to copy the data to. Thus, we're back to my second suggestion + of special startup code. + [...] + Now, if you have multiple data hunks, the problem is compounded. + I repeat - stay away from RESIDENT and CLI-RESIDENT. For those netters + who don't have it - you don't want it. I agree the idea is nice - + hey, it's great - but the current way of handling things is broken. bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) recently wrote: >RESIDENT is limited, but NOT broken. It works *wonderfully* for what it was >designed for, BCPL. It is true that it cannot make BSS hunks and it is true >that the code must be REUSABLE and REENTRANT; but these are irrelevant to the >commands that need to be made RESIDENT. I don't think it is a good idea to promote RESIDENT in its current form, since the number of things you can safely use it for is pretty small, and not many people have it anyway (which happens to be a Good Thing). > RESIDENT is the best thing since sliced bread The IDEA is. The command is not. In addition, Lattice's fork(), Manx's exec(), the RUN command, and every CLI/Shell except CLI-RESIDENT have no idea about resident commands. >Novice users especially should use RESIDENT, so they get addicted to >how fast it is. Arrghh! Then they make emacs, more and ls resident, and wonder why the machine keeps blowing up. No thanks. Besides, don't novices use WorkBench? :-) >Perhaps C-A could say something official-like for the rest of the world's >conscience. AndyF said: + From: andy@cbmvax.cbm.UUCP (Andy Finkel) + Message-ID: <1005@cbmvax.cbmvax.cbm.UUCP> + Date: 18 Nov 86 21:29:15 GMT + >>Some more thought is going to have to be put into the concept + >>before it sees the light of day again. [and...] + It was designed for BCPL programs, we put it into the developer + releases, it won't appear again until it works more generally. Seems solid enough advice, even if implied. Of course, he also put at the end: + "Never make anything simple and efficient + when it can be complex and wonderful." But back to Bryce: >BTW: resident was initially released on a disk with no distribution >restrictions printed on it, and it does not contain a copyright notice. Wasn't it released to developers only, under the terms of the non-disclosure agreement? >For reasons other that the one above I have been working on a "RESIDENT". >Beat on me hard enough and I will finish and release it. Yay. Do it. >This really skirts the issue, as the "RESIDENT" command needs >the "cli-resident" file to be meaningful. It needs a CLI/Shell that understands "sticky" text segments. You might want to hack it into Matt's shell ... you'll need a command to make it resident and modify the exec code to look in the resident list, then do something like checksum the segments to make sure nothing's changed while you weren't looking. Or have the exec code allocate data space for each invokation. In other words, I don't think a RESIDENT command in and of itself will do the trick. But you knew that. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/04/87)
>>------- >>For reasons other that the one above I have been working on a "RESIDENT". >>Beat on me hard enough and I will finish and release it. > >Yay. Do it. The snag I ran into while writting my new hyper-fancy RESIDENT was that to do it "right" I needed a new segment loader. That turned out to be just a little bit too hairy a problem without "official" support. UnLoadSeg() was much easier... :-) Naturally BSS hunks are supported. Shared or exclusive TEXT is supported along with shared or exclusive DATA. The "Magic" mentioned along with several hyper-kludges related to the segment loader work as planned, but the overall picture is far from complete: In addition to the segment loader there is a need for the ability to write a true compatible CLI [complete with BCPL-dirty Exec()] that can then understand the new resident segments properly. CLI-Resident is just the thing but... but... * With the BCPL compatible Exec(), and segment loader modifications, that will wrap up what's needed for the CLI. I still need a leap of insight to do this seamlessly from the Workbench. (When in doubt, plagiarize! Where are those BSD 4.3 docs?) --> short of that, ideas? comments? <-- >>------- >>Back in November I wrote an expose on the dangers of RESIDENT. I still maintain that the old RESIDENT is *NOT* defective. Taking a look at what's in mine right now: run x (execute, really) cd list type hex All those are 100% compatible. (BTW: nearly all of the RESIDENT compatible BCPL commands in my C: directory have been replaced with 68000 eqivalents, written with RESIDENT compatibility in mind.) (No flames about C programs not working with the old RESIDENT. That's what the new one is all about, ok?) > It needs a CLI/Shell that understands "sticky" text segments. > In other words, I don't think a RESIDENT command > in and of itself will do the trick. But you knew that. (Yup, that's in the plan...) >> BTW: resident was initially released on a disk with no distribution >> restrictions printed on it, and it does not contain a copyright notice. > > Wasn't it released to developers only, under the terms of the > non-disclosure agreement? What non-disclosure agreement? ------------- Ack! (NAK,EOT,SOH) |\ /| . {o O} . bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce ( " ) U Single tasking? Just say *NO!*
scotty@l5comp.UUCP (Scott Turner) (06/06/87)
In article <8706020852.AA18103@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >WOAHH!!!! Don't abuse my goldfish!!! :-) :-). Yeah, between myself and CATS there are already enough wounded goldfish. (I HAVE wondered about Andy's picking the term "goldfish" vis-a-vis "CATS", we all know how cats like to abuse goldfish... ;) [I'm kidding Andy, please no flames, just chuckles OK?] >>Second, regallar (sic) Amiga owners don't >>have the RESIDENT command. Not legally, anyway. >conscience. BTW: resident was initially released on a disk with no >distribution restrictions printed on it, and it does not contain a >copyright notice. I seem to have this note buried in my mind that we agreed NOT to re-distribute items sent to us under the 1.2 beta test. Of course my memory could be playing tricks with me... And to throw more fuel on the "Big Bad MCC" fire, the MCC Shell has RESIDENT and get this, UNRESIDENT(!) built in!!! I've NEVER seen an UNRESIDENT anywhere else. >This really skirts the issue, as the "RESIDENT" command needs the "cli-resident" >file to be meaningful. That is probably imbedded heavily with BCPL magic, >not really possible to recreate without knowing what it does. >(Scott, break out the MCC dissassembler...) Aye aye Capt'n! ;-) You want a new cli-resident or just the "magic"? If it's just the magic I think the trick is that the cli/shell/whatever just uses the seglist hung off the nethandler entry in dosinfo(???) to find the segment list for the program it wants and then does the same thing with it that it does with LoadSeg's returned seglist. But I'll be happy to dig if the CATS don't want to hop in and explain. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/nulltt
OHA101%URIACC.BITNET@mitvma.mit.edu (F. Michael Theilig) (06/05/89)
I've heard a lot of people talk about using 1.3's (And ARP 1.3's)
resident command. I toyed with it myself once.
Quite frankly, I can't understand what the attraction is. What's
wrong with copying it to a RAM disk? Then you don't have to worry about
the Pure bit. I would immagine that both ways take the same amount of
memory and time at bootup.
There was some discussion about the possibility of making the resident
commands stay in memory upon reboot. VD0: or RAD: will do that just fine.
(RAD. What a silly name for a ram disk. I use Commodore's driver, but
call it VD0: in my mount list ;-). Or if you don't want them on reboot,
send them to RAM:. Could someone enlighten me to the advantages to
resident?
/*
F. Michael Theilig OHA101 at URIACC.Bitnet
"There is no Dark Side of the Moon...
in fact it is all dark."
*/gilham@polya.Stanford.EDU (Fred Gilham) (06/06/89)
In article <16912@louie.udel.EDU> OHA101%URIACC.BITNET@mitvma.mit.edu (F. Michael Theilig) writes: > > Could someone enlighten me to the advantages to > resident? > The main advantage is that you execute the program "in place". If you use a ram disk, you copy the program into memory (from memory) then execute it. Thus while executing the program, you have two copies of it in memory. If the program is resident, there is never more than one copy in memory. You can perform the trick in 1) when multiple instances of the program. Imagine that you are "more"ing several files at the same time. You can be using a single copy of the code to do all this, with each execution instance creating its own windows, buffers etc. In spite of this, I run most of the little programs from c: out of rad: so they are there when I reboot. I use `rez' for larger programs, but note that `rez' does not ensure that you can run a single program more than once (I think I tried it with `less' and it screwed up). -Fred Gilham
elg@killer.DALLAS.TX.US (Eric Green) (06/06/89)
in article <16912@louie.udel.EDU>, OHA101%URIACC.BITNET@mitvma.mit.edu (F. Michael Theilig) says: > Quite frankly, I can't understand what the attraction is. What's > wrong with copying it to a RAM disk? Then you don't have to worry about > the Pure bit. I would immagine that both ways take the same amount of > memory and time at bootup. You imagine wrong. If you put a program into RAM: then later run it, AmigaDOS copies the program out of RAM:, into memory somewhere, and executes it. If you Resident a program then later run it, AmigaDOS runs it "as is". In other words, when you run a program from RAM:, it's taking up twice as much memory. Of course, now that I have a hard drive, I don't even have CD and LS Ares'ed :-). -- Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849