carpent@SRC.Honeywell.COM (Todd Carpenter) (11/03/89)
In article <1989Nov2.164612.7101@welch.jhu.edu> mjr@welch.jhu.edu (Marcus J. Ranum) writes: > In article <8388@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > > > >Now, my machine at home crashes constantly, but I'm actually writing the > >software there and causing the crashes, so that's to be expected under any > >OS without hardware memory protection. > [misc deleted] > That's basically what I meant: I simply can't take a machine > without hardware memory protection very seriously. For a machine that > doesn't have it, the Amiga is my favorite, but I'll never consider it a > serious development platform. > [misc deleted] > --mjr(); > -- Oh, gimme a break. How many embedded systems have you played with? SBC's? A good number of them neither have memory protection nor virtual memory. They are the same critters that fly your airplanes, run your CT and MRI scanners, and a plethora of other things. They run the world about you. Is that serious enough for you? Yes, I'll admit Guru's are annoying. As a neophyte amiga programmer I've seen more than my share. Big deal. I reboot, and merrily continue (with a fast hard disk, and the 2620, I barely have time to grab another coke). One thing I can say for sure - it certainly is an obvious way of discovering bugs! -Todd C.
bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) (11/04/89)
In article <37410@srcsip.UUCP>, Todd Carpenter writes: >> In article <8388@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >> > >> >Now, my machine at home crashes constantly, but I'm actually writing the >> [misc deleted] > >> That's basically what I meant: I simply can't take a machine >> without hardware memory protection very seriously. For a machine that >> doesn't have it, the Amiga is my favorite, but I'll never consider it a >> serious development platform. >> [misc deleted] >> --mjr(); Actually, it would be *very* nice if we didn't need to worry as much about system crashes as we do. But what are we running here? We don't have a hundred users online at once who'd be mortified when the machine went down; This is a single-user machine. For its price range, it's hard to justify the memory protection... Not to say that it shouldn't be an option... +--------------------------------+--------------------------------------------+ | Jeff Bevis | "But I don't like spam!" | | bevis@en.ecn.purdue.edu | Give me Amiga or nothing at all. | +--------------------------------+--------------------------------------------+
mjr@welch.jhu.edu (Marcus J. Ranum) (11/04/89)
In article <8911040008.AA13445@en.ecn.purdue.edu> bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) writes: >system crashes as we do. But what are we running here? We don't have a >hundred users online at once who'd be mortified when the machine went down; >This is a single-user machine. [...] That's true, but it IS a multitasking machine. If you can't rely on the machine not to crash while you do real work (like compiling code and testing it) then you can't rely on it to be doing anything else at the same time. That gives away 8/10 of the usefulness of multitasking and if you're going to follow that kind of logic, why multitask at all ? On my Sun, I like to edit several source modules at once, while compiling and debugging in another window. If I knew I was going to have to redo my edits each time I wrote bad code (I did, once, in 1986, I think it was :-) ) I'd never be able to do that, and then what is the use of multitasking ? I got really beefed when I would be downloading files in the background on my Amy, and have to restart a 500K download because some package didn't get all the memory it wanted. Let's get real, here. The computer is better suited for doing the scut work like memory management - and a damn sight more patient - than I am - so why should I have to waste what little brains I got to do it's job ? That's what I bought the computer FOR ! --mjr(); -- He was in his room half awake, half asleep. The walls of the room seemed to alter angles, elongating and shrinking alternately, then twisting around completely so that he was in the opposite side of the room. "A trick of the light and too much caffeine," he thought. -Bauhaus
bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (11/04/89)
In article <1989Nov4.031121.5495@welch.jhu.edu> mjr@welchlab.welch.jhu.edu (Marcus J. Ranum) writes:
=-
=- Let's get real, here. The computer is better suited for doing
=-the scut work like memory management - and a damn sight more patient -
=-than I am - so why should I have to waste what little brains I got to
=-do it's job ? That's what I bought the computer FOR !
=-
Resource tracking and memory protection aren't free. Part of the
reason they don't exist in the Amiga is to improve performance. This is the
same reason several "new" OS explicitly support multiple lightweight tasks within the address space of a single process. And how do you propose to do message
passing in the presence of memory protection, hmm? Either the kernel copies
messages between address spaces, or you have to have shared segments that can
be read-only for arbitrary groups of processes. Either way, it's a performance
hit.
So quit bitching, and quit ending your sentences with prepositions. :-)w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) (11/07/89)
In article <410@mohawk.cs.utexas.edu> bryan@cs.utexas.edu writes: > Resource tracking and memory protection aren't free. Part of the >reason they don't exist in the Amiga is to improve performance. This is the >same reason several "new" OS explicitly support multiple lightweight tasks within the address space of a single process. And how do you propose to do message >passing in the presence of memory protection, hmm? Either the kernel copies >messages between address spaces, or you have to have shared segments that can >be read-only for arbitrary groups of processes. Either way, it's a >performance hit. Resource tracking: I'd like to see ARP do more than just memory. How about an ArpOpenLibrary() and an ArpOpenDevice(), and such. Then, when your program is finished, have an ArpCloseEveryFamousThing(). This way, you can have resource tracking, but only if you need it. I really like the idea someone mentioned a while back of an ExitHandler() routine. When a task starts up, you set a field of the task structure to point to a function in your code that will clean up the mess you have created. This setting would be done, of course, via a SetExitHandler(int (*)())) function or some such abstraction. When the task is finished, the ExitHandler is called, which could do the aforementioned ARP call, and everything would be rosy. I guess that would be a 1.5 wish... (or is it already "in there?" 8-) Message passing: I believe the MEMF_PUBLIC flag to AllocMem() was Commodore's thinking ahead to an OS with protected memory. Message passing could be done the same way it is now, but all messages would have to be allocated as public, for everyone to read. Unrelated questions: When is Manx 5 due? How does one get to be a beta tester for either Manx or Lattice? Edwin
bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (11/07/89)
In article <8638@microsoft.UUCP> w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: =-In article <410@mohawk.cs.utexas.edu> bryan@cs.utexas.edu writes: =-> Resource tracking and memory protection aren't free. Part of the =- =-Resource tracking: I'd like to see ARP do more than just memory. How =- =-I really like the idea someone mentioned a while back of an =-ExitHandler() routine. When a task starts up, you set a field of the =- These are noble ideas, but only help significantly if everyone uses them. It does little good to have resource tracking for only 10% of your tasks. Plus, your exit routines could have bugs, or your buggy tasks could stomp them. This kind of code belongs in the kernel, not in user tasks. I'm afraid that this idea, if implemented, would go the way of Commodities Exchange (remember?) --- it's the way things should be done, but no one will do it, because it wasn't required from the start. =- =-Message passing: I believe the MEMF_PUBLIC flag to AllocMem() was =-Commodore's thinking ahead to an OS with protected memory. Message passing =-could be done the same way it is now, but all messages would have to be =-allocated as public, for everyone to read. =- ^^^^--and write. So much for protection.
aduncan@rhea.trl.oz.au (Allan Duncan) (11/13/89)
From article <410@mohawk.cs.utexas.edu>, by bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End): > And how do you propose to do message > passing in the presence of memory protection, hmm? Either the kernel copies > messages between address spaces, or you have to have shared segments that can > be read-only for arbitrary groups of processes. Either way, it's a performance > hit. What is MEMF_PUBLIC for then? Allan Duncan ACSnet aduncan@rhea.trl.oz.au ARPA aduncan%rhea.trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!rhea.trl.oz.au!aduncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (11/13/89)
In article <807@trlluna.trl.oz> aduncan@rhea.trl.oz.au (Allan Duncan) writes:
=-From article <410@mohawk.cs.utexas.edu>, by bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End):
=-
=-> And how do you propose to do message
=-> passing in the presence of memory protection, hmm? Either the kernel copies
=-> messages between address spaces, or you have to have shared segments that can
=-> be read-only for arbitrary groups of processes. Either way, it's a performance
=-> hit.
=-
=-What is MEMF_PUBLIC for then?
=-
For being writeable by everyone, so that your buggy program can still
interfere with other tasks.hcobb@walt.cc.utexas.edu (Henry J. Cobb) (11/14/89)
The problem has already been solved, Unix for the Amiga will be available RSN, and offers all of the system protection features anybody should ask for. (If its not "in there", you shouldn't ask for it ;-). So programers will have a fairly secure system to write programs under, while the users will continue to enjoy powerful proformance with inexpensive systems. Henry J. Cobb hcobb@walt.cc.utexas.edu
bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) (11/18/89)
In article <807@trlluna.trl.oz>, aduncan@rhea.trl.oz.au (Allan Duncan) writes: >From article <410@mohawk.cs.utexas.edu>, by bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End): > >What is MEMF_PUBLIC for then? > This flag specifies that you want memory (chip or fast) which is guaranteed not to be swapped out or become unavailable to all processes all the time. You will want this type of memory for I/O operations (buffers, things the OS will look at). It's not of any consequence to ignore this flag NOW. But when Amiga/VM arrives -- oh, the software that will break! So be sure to use it when appropriate. +--------------------------------+--------------------------------------------+ | Jeff Bevis | "But I don't like spam!" | | bevis@en.ecn.purdue.edu | Give me Amiga or nothing at all. | +--------------------------------+--------------------------------------------+
ckp@grebyn.com (Checkpoint Technologies) (11/20/89)
In article <8911180206.AA22553@en.ecn.purdue.edu> bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) writes: >In article <807@trlluna.trl.oz>, aduncan@rhea.trl.oz.au (Allan Duncan) writes: >>From article <410@mohawk.cs.utexas.edu>, by bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End): >> >>What is MEMF_PUBLIC for then? >> >This flag specifies that you want memory (chip or fast) which is >guaranteed not to be swapped out or become unavailable to all processes all >the time. You will want this type of memory for I/O operations (buffers, >things the OS will look at). It's not of any consequence to ignore this >flag NOW. But when Amiga/VM arrives -- oh, the software that will break! >So be sure to use it when appropriate. > If Commodore's VM AmigaDOS actually broke programs that don't properly use MEMF_PUBLIC, then almost nothing would work. MEMF_PUBLIC supposedly means that the memory so alloced can be shared; and conversely, any memory which is not so allocated cannot be shared. There are many many programs which allocate structures which must be shared, but don't. See, there has been no way to enforce MEMF_PUBLIC's proper use. Enforcing MEMF_CHIP was impossible until fast RAM become available (at which point some programs broke; most notable, perhaps, Deluxe Paint). The only way to enforce MEMF_PUBLIC's proper use is with an MMU, and most Amigas don't have one, and all Amiga's don't use it. So now that MEMF_PUBLIC's had all this time to be abused, to begin enforcing MEMF_PUBLIC would cause a disaster. In my own humble opinion, I think Commodore needs to support VM with two different approaches: first, the one they took, by defining the MEMF_VIRTUAL bit and publishing the rules for it's use. Not using it is not a crime (punishable by breaking), but mis-using it will be. The second approach should be to define a new, protected-mode environment in which protected programs will run. Both environments should be able to cohabit under Exec. When a protected program crashes, it's resources would be reclaimed and it would be removed cleanly from the system. Of course, when an unprotected program crashes it must still result in a guru (oh, sorry; System Message) and reboot, because that's the nature of an unprotected system; and protected mode programs would come down with it. Richard Krehbiel, with Checkpoint Technologies (Working on a new .sig! Be patient.)
icsu8212@caesar.cs.montana.edu (Stone) (03/13/90)
[ reams of stuff deleted ]
> MOST amiga owners don't want memory protection.
[ more stuff deleted ]
Be careful who you include in MOST, I for one would VERY MUCH appreciate
memory protection. I love the multi-tasking, but for the programmer,
it can be a REAL pain in the a.. to chat with GURU everytime you forget
to pass a LONG integer or some such. Core dump, segmentation faults, and
access violation messages are much preferred in my book.
--
===============================================================================
//X\\ | {uunet|relay} icsu8212@caesar.cs.montana.edu
/// \\\ AMIGA HACKER | Murphy's First Law: (un-amended)
/// Mike Stone | Nothing can possibly go wrong.donw@zehntel.zehntel.com (Don White) (03/17/90)
In article <3507@caesar.cs.montana.edu> icsu8212@caesar.cs.montana.edu (Stone) writes(IN RESPONSE TO SOMEONE WHOSE NAME WAS REMOVED TO PROTECT THE STUPID): >> MOST amiga owners don't want memory protection. > >Be careful who you include in MOST, I for one would VERY MUCH appreciate >memory protection. I love the multi-tasking, but for the programmer, I very much agree that memory protection would be helpful. I believe this lack is the main thing wrong with the Amiga. ex. Q: Does the Amiga Multitask? A: Yes... But, if you use up CHIP memory or one program barfs, your WHOLE house of cards falls down. Of course, the Amiga has so much else going for it that I won't complain TOO much. BUT, I consider the idea that we don't want memory protection to be a DANGEROUS RUMOR!!! ( One forty billionth smiley) Don White Box 271177 Concord, CA. 94527-1177 zehntel!donw
A_HINDS%HVRFORD.BITNET@cornellc.cit.cornell.edu (03/27/90)
Ok, I know that this topic of discussion is getting old, but
I don't want it to die when I think we had a useful thread going.
The most interesting possibility mentioned so far (and it would
certainly shut me up for a while) would be using the MMU to writeprotect
all LoadSeg()'d code. This would also be easier than writing a "runprotected"
command. I would do it myself, but I don't really know how to do it.
(No 68030 manual, and wasn't there a problem with SetFunction()ing the
dos.library?)
Anyway, is there some ambitious hacker out there who wants to
write this pup? Please?
Alexander Hinds
A_HINDS@HVRFORD