wen@husc2.UUCP (wen) (11/09/86)
Can someone tell me how the "Resident" command is used under 1.2 and what it does? I missed betas 5-7, and I assume that I missed the docs to "Resident," too. A. Wen wen@harvunxu.BITNET wen@husc4.HARVARD.EDU
andy@amiga.UUCP (Andy Finkel) (11/15/86)
In article <1017@husc2.UUCP> wen@husc2.UUCP (wen) writes: > >Can someone tell me how the "Resident" command is used under 1.2 and what it >does? I missed betas 5-7, and I assume that I missed the docs to "Resident," >too. > The resident command allowed a reentrant, sharable program to use kept in memory, and not reloaded for multiple invocations. Unfortunately, as it turns out, this seemed only to apply to many BCPL programs. And there was no way to check whether a program was residentable or not except try it, and see if it crashed. So we put in on the Developer's Tool disk, rather than the Workbench. Some more thought is going to have to be put into the concept before it sees the light of day again. andy finkel -- andy finkel Commodore(Amiga) {ihnp4|seismo|allegra}!cbmvax!andy or pyramid!amiga!andy Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors. "Remember, no matter where you grow, there you are." - Buckaroo Bonsai.
page@ulowell.UUCP (Bob Page) (11/18/86)
andy@skipper.UUCP (andy finkel) wrote in article <1607@amiga.amiga.UUCP>: >The resident command allowed a reentrant, sharable program to use kept ^^^^ note the tense here >in memory, and not reloaded for multiple invocations. Unfortunately, >as it turns out, this seemed only to apply to many BCPL programs. It didn't even work correctly for BCPL programs! Sure, it worked somewhat, but the Resident command allocated more space than it should have - including a data segment that should be allocated on startup, not when the program was installed as resident. >And there was no way to check whether a program was residentable or not This is a truly great word, Andy. ^^^^^^^^^ >Some more thought is going to have to be put into the concept >before it sees the light of day again. Even a _little_ more thought would have been nice ... like checksumming the segments to see if they had changed - if so, allocate space for new ones - in other words, take what you can and replace the dirty segments from the disk. I'm not flaming you guys, I'm flaming MCC. Hey, speaking of the Toolkit (well, you did but I trimmed out that part), what can you say about the program to allow overscanning? It's mentioned in the 1.2 release notes (poof) but the gamma 1 toolkit doesn't have it and the 1.2 release toolkit isn't out yet. > andy finkel > Commodore(Amiga) Are you still in Los Gatos or have you returned to West Chester? ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
andy@cbmvax.cbm.UUCP (Andy Finkel) (11/19/86)
In article <760@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >andy@skipper.UUCP (andy finkel) wrote in article <1607@amiga.amiga.UUCP>: >>The resident command allowed a reentrant, sharable program to use kept > ^^^^ note the tense here Right...read on and find out why I used the past tense here... >>in memory, and not reloaded for multiple invocations. Unfortunately, >>as it turns out, this seemed only to apply to many BCPL programs. > >It didn't even work correctly for BCPL programs! Sure, it worked >somewhat, but the Resident command allocated more space than it >should have - including a data segment that should be allocated on >startup, not when the program was installed as resident. Are you positive about this ? It seems like if it was done that way we'd have to have a resident and non-resident version of each BCPL program. > >>And there was no way to check whether a program was residentable or not > This is a truly great word, Andy. ^^^^^^^^^ > Hmmm, should it be spelled residentible ? It was a just shorter way of saying 'able to be properly made resident' (But I bet you figured that out. :-) ) >>Some more thought is going to have to be put into the concept >>before it sees the light of day again. > >Even a _little_ more thought would have been nice ... like checksumming >the segments to see if they had changed - if so, allocate space for >new ones - in other words, take what you can and replace the dirty >segments from the disk. I'm not flaming you guys, I'm flaming MCC. > Right. It was designed for BCPL programs, we put it into the developer releases, it won't appear again until it works more generally. BTW, checksumming segments sounds like a poor idea...it defeats the purpose of the shareable requirement...that 2 or more processes can share the same copy of a program. Were you envisioning global variables ? >Hey, speaking of the Toolkit (well, you did but I trimmed out that part), >what can you say about the program to allow overscanning? It's mentioned >in the 1.2 release notes (poof) but the gamma 1 toolkit doesn't have it >and the 1.2 release toolkit isn't out yet. > I'm going to let Dale handle this one. Dale ? >> andy finkel >> Commodore(Amiga) > >Are you still in Los Gatos or have you returned to West Chester? I'm in West Chester for now. > >..Bob >-- >Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET andy finkel -- andy finkel Commodore/Amiga {ihnp4|seismo|allegra}!cbmvax!andy or pyramid!amiga!andy Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors. "Never make anything simple and efficient when it can be complex and wonderful."
dale@amiga.UUCP (Dale Luck) (11/20/86)
In article <1005@cbmvax.cbmvax.cbm.UUCP> andy@skipper.UUCP (andy finkel) writes: >In article <760@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >>andy@skipper.UUCP (andy finkel) wrote in article <1607@amiga.amiga.UUCP>: >>>The resident command allowed a reentrant, sharable program to use kept >> ^^^^ note the tense here >> >>Even a _little_ more thought would have been nice ... like checksumming >>the segments to see if they had changed - if so, allocate space for >>new ones - in other words, take what you can and replace the dirty >>segments from the disk. I'm not flaming you guys, I'm flaming MCC. >> >Right. It was designed for BCPL programs, we put it into the >developer releases, it won't appear again until it works more generally. > >BTW, checksumming segments sounds like a poor idea...it defeats the >purpose of the shareable requirement...that 2 or more processes can share >the same copy of a program. Were you envisioning global variables ? Can we say, seperate I & D spaces? This can be implemented by using a global base register, like aztec C. Each invocation of the resident program would first checksome the 'code' area. If ok, the allocate a new 'data' area, initialize it and go. This does force a limit of 64k data space on 68000/6801x machines. But most programs can be written to deal with this, by forcing them to allocate the required data. > >>Hey, speaking of the Toolkit (well, you did but I trimmed out that part), >>what can you say about the program to allow overscanning? It's mentioned >>in the 1.2 release notes (poof) but the gamma 1 toolkit doesn't have it >>and the 1.2 release toolkit isn't out yet. >> The program you are refering to is morerows. I've got to hunt it down yet, make sure it works still and it will appear on the official toolkit release. Dale Luck officially representing duck. That's all folks.
page@ulowell.UUCP (11/27/86)
andy@skipper.UUCP (andy finkel) wrote in article <1005@cbmvax.cbmvax.cbm.UUCP>: >In article <760@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >>It didn't even work correctly for BCPL programs! Sure, it worked >>somewhat, but the Resident command allocated more space than it >>should have - including a data segment that should be allocated on >>startup, not when the program was installed as resident. > >Are you positive about this ? It seems like if it was done that >way we'd have to have a resident and non-resident version of each >BCPL program. 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. >>Even a _little_ more thought would have been nice ... like checksumming >>the segments to see if they had changed - if so, allocate space for >>new ones - in other words, take what you can and replace the dirty >>segments from the disk. I'm not flaming you guys, I'm flaming MCC. >> >BTW, checksumming segments sounds like a poor idea...it defeats the >purpose of the shareable requirement...that 2 or more processes can share >the same copy of a program. Were you envisioning global variables ? Yes - but checksumming doesn't defeat anything but unreliable data. You can't share a copy of a program when one or more segments are no longer pure - and it doesn't take long to checksum the segment, so why not do it? I don't see why it is a bad idea. 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. ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
andy@cbmvax.cbm.UUCP (Andy Finkel) (12/03/86)
In article <790@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >andy@skipper.UUCP (andy finkel) wrote in article <1005@cbmvax.cbmvax.cbm.UUCP>: >>In article <760@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >>>It didn't even work correctly for BCPL programs! Sure, it worked >>>somewhat, but the Resident command allocated more space than it >>>should have - including a data segment that should be allocated on >>>startup, not when the program was installed as resident. >> >>Are you positive about this ? It seems like if it was done that >>way we'd have to have a resident and non-resident version of each >>BCPL program. > >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 - yes, if the CLI then loaded a complete new copy and started that. >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. I think we've reached agreement here...you'd end with a version of the command that does the allocate/copy in its initialization for use with the resident CLI, and one that didn't have the overhead for use with the normal CLI, Execute, RUN, etc. > >Now, if you have multiple data hunks, the problem is compounded. No argument there. In fact, if, as some assembler programmers seem to do, put occasional variables in their CODE sections, its even worse! >>Even a _little_ more thought would have been nice ... like checksumming >>>the segments to see if they had changed - if so, allocate space for >>>new ones - in other words, take what you can and replace the dirty >>>segments from the disk. I'm not flaming you guys, I'm flaming MCC. >>> >>BTW, checksumming segments sounds like a poor idea...it defeats the >>purpose of the shareable requirement...that 2 or more processes can share >>the same copy of a program. Were you envisioning global variables ? > >Yes - but checksumming doesn't defeat anything but unreliable data. >You can't share a copy of a program when one or more segments are no >longer pure - and it doesn't take long to checksum the segment, so >why not do it? I don't see why it is a bad idea. I agree about the checksumming, but I think that if a checksum fails, one shouldn't just reload dirty segments from the disk. Rather, one should load an entire new copy, and fire that one up for the process. If we just reload dirty segments, there would be real problems if two programs were executing the same code... "hmmm, says process 1, I could swear I left a $1C there...oh well, I guess I'll just use this nice 0, instead." :-) If a program is really capable of being used as a resident command the checksum wouldn't be necessary. If the checksum fails, the program should be locked out from being resident. >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. > >..Bob I second this. It needs to be rethought out and redone. RAM expansion and commands in your RAMdisk, that's the ticket. yeah. andy finkel -- andy finkel Commodore/Amiga {ihnp4|seismo|allegra}!cbmvax!andy or pyramid!amiga!andy Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors. "Never make anything simple and efficient when it can be complex and wonderful."