Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!cbmvax!andy From: andy@cbmvax.cbm.UUCP (Andy Finkel) Newsgroups: comp.sys.amiga Subject: Re: 1.2 resident query Message-ID: <1045@cbmvax.cbmvax.cbm.UUCP> Date: Wed, 3-Dec-86 11:16:59 EST Article-I.D.: cbmvax.1045 Posted: Wed Dec 3 11:16:59 1986 Date-Received: Thu, 4-Dec-86 09:02:38 EST References: <1017@husc2.UUCP> <1607@amiga.amiga.UUCP> <760@ulowell.UUCP> <1005@cbmvax.cbmvax.cbm.UUCP> <790@ulowell.UUCP> Reply-To: andy@cbmvax.UUCP (Andy Finkel) Organization: Commodore Technology, West Chester, PA Lines: 88 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."