macgreg@eng.umd.edu (Scott J. MacGregor) (05/11/91)
Scott MacGregor Department of Chemical Engineering, University of Maryland. Internet: macgreg@eng.umd.edu
Greg@AppleLink.Apple.Com (Greg Marriott) (05/11/91)
In article <1991May10.175654.812@eng.umd.edu>, macgreg@eng.umd.edu (Scott J. MacGregor) writes: > Do applications running under system 7.0 run in supervisory or user mode > ofthe 680x0 processor? If VM is turned on, then applications run in user mode. If VM is off, then applications run in supervisor mode (like they always have...) Greg Marriott Blue Meanie Apple Computer, Inc.
bskendig@phoenix.Princeton.EDU (Brian Kendig) (05/12/91)
In article <13455@goofy.Apple.COM> Greg@AppleLink.Apple.Com (Greg Marriott) writes: >In article <1991May10.175654.812@eng.umd.edu>, macgreg@eng.umd.edu (Scott J. MacGregor) writes: >> Do applications running under system 7.0 run in supervisory or user mode >> ofthe 680x0 processor? > >If VM is turned on, then applications run in user mode. If VM is off, then >applications run in supervisor mode (like they always have...) Hmm, now, let me get this straight -- is it true that the only visible difference between supervisor mode and user mode is that a process running in supervisor mode has the ability to crash in a really bad way and merrily trounce through all the rest of the machine's memory and bring the whole machine to a crash, whereas a process running in user mode is restricted to only having access to a certain range of memory that it can trash to its heart's content but it is completely unable to futz with the rest of the machine? Why do programs run in user mode under VM only? Is this because VM does something that makes user mode possible whereas user mode just isn't feasible when you don't have virtual memory active, or did the System 7.0 developers just decide for whatever reason that they didn't feel like having things run in user mode normally? What I'm getting at: If running things in user mode means my machine will be a bit more resistant to system crashes, I think it's something I'd like to have the ability to use -- but my little old SE doesn't do VM, of course, so right now I guess I have to keep using supervisor mode. How difficult a modification would it be to have my SE use user mode, too? Is this a matter of a simple INIT that would just toss my machine into user mode without worrying about VM, or am I talking about something that would require a major rewrite of the operating system here? Any clues are gladly accepted. ;) << Brian >> | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | "You gave your life to become the person you are right now. Was it worth it?"
davids@mondo.engin.umich.edu (David Snearline) (05/12/91)
Regarding Brian Kendig's questions regarding the difference between the user and supervisor modes on the Macintosh: The user and supervisor modes are internal to the MC68000 series, and are determined by a bit within the status register (SR). The operating mode has two fundamental effects. First of all, in the user mode, some of the "privileged" commands may not be executed -- they cause a privilege exception. Example of these commands are RESET, MOVE SR, and MOVES. The second effect, which for multiuser systems is probably the most important, is that the privilege bit affects how the processor classfies a data reference. There are three lines (FC0-FC2) which classify the type of data reference being made by the processor. Computer designers can then use these line to block access to certain memory address areas based on whether or not the process is in "supervisor mode". Generally, only the OS or a multiuser system will be operating in supervisor mode, and thus hardware may allow it to have unrestricted memory access. The Mac toolbox will always execute in supervisor state, because exception processing (ie. traps) will always force supervisor mode. Also, I don't believe Macs without a PMMU use the FC lines. "User mode" by itself will do nothing to avoid crashes -- it's only if the hardware is set up to utilize the FC lines to block memory write violations that anything is gained. Thus, writing an INIT to force "user mode" on old Macs would not do anything useful. Further, you would also have to re-write _Launch so that it cleared the S bit before executing a new program. The MC680X0 handbooks have a good description of how the supervisor mode works if you are interested. By the way, does anyone know to what extent the new Macs utilize FC0-FC2? --- Dave --- -- David Snearline CAEN Network Operations University of Michigan Engineering
miyazaki@bombay.NoSubdomain.NoDomain (Takeshi Miyazaki) (05/13/91)
In article <9432@idunno.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >Why do programs run in user mode under VM only? I don't remember exactly, but I heard that 68000 (not 68020, 68030) has a serious error in specfication (something like you can't access user data from supervisor mode) so programmer must use only supervisor mode for implementation. Correct me if I am wrong. Takeshi Miyazaki miyazaki@ee.princeton.edu Dept of E.E. computer engineering course.
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (05/13/91)
Brian Kendig writes in a message to All
BK> How difficult a modification would it be to have my SE use user
BK> mode, too? Is this a matter of a simple INIT that would just
BK> toss my machine into user mode without worrying about VM, or
BK> am I talking about something that would require a major rewrite
BK> of the operating system here?
Speaking sans true knowledge (as is my wont), I'd guess that "32-bit clean"
is the telling factor as to whether supervisor or user mode is to be used-if
an application is 32-bit clean, then the OS developers probably assumed that
it would be following the rest of Apple compatibility guidelines.
As to whether your SE could use it, hmmmm... I doubt it, as there would be no
easy way to determine when an OS call needed supervisor mode, and when it could
use supervisor mode. Maybe patching all traps..., but what if someone does their
own patching? And what about VBL tasks, etc? (and what about Naomi?)
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgsiegel@world.std.com (Rich Siegel) (05/15/91)
In article <10972.282FE0AB@stjhmc.fidonet.org> Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: >Brian Kendig writes in a message to All > >BK> How difficult a modification would it be to have my SE use user >BK> mode, too? Is this a matter of a simple INIT that would just >BK> toss my machine into user mode without worrying about VM, or >BK> am I talking about something that would require a major rewrite >BK> of the operating system here? It's trivial to do, since it only involves changin a single bit in the status register, and it'll only break software that depends on exception stack frames, but it's a completely useless thing to do on a Mac SE, which is neither pre-emptive nor is it capable of supporting an MMU directly. >Speaking sans true knowledge (as is my wont), I'd guess that "32-bit clean" >is the telling factor as to whether supervisor or user mode is to be used-if >an application is 32-bit clean, then the OS developers probably assumed that >it would be following the rest of Apple compatibility guidelines. Actually, the deciding factor is whether the user turns on "Virtual Memory" in his control panel. The machine still runs in supervisor mode in 32-bit mode when VM is off. R. -- ----------------------------------------------------------------------- Rich Siegel Internet: siegel@world.std.com Software Engineer Applelink: SIEGEL Symantec Languages Group
ech@cbnewsk.att.com (ned.horvath) (05/15/91)
Brian Kendig writes in a message to All BK> How difficult a modification would it be to have my SE use user BK> mode, too?... From article <1991May15.024320.9727@world.std.com>, by siegel@world.std.com (Rich Siegel): > It's trivial to do, since it only involves changin a single bit > in the status register, and it'll only break software that depends on > exception stack frames, but it's a completely useless thing to do on > a Mac SE, which is neither pre-emptive nor is it capable of supporting > an MMU directly. It's useless, unless you're testing your program to see if it MIGHT RUN on one of those high-end machines you can't afford. Now, I'm sure Rich&co. have made sure ThC and ThP won't generate privileged instructions, and that all that hand-coded library asm code is clean (right, Rich?), but not all of us know for sure...! It's also not obvious to me that "just set the bit" is valid (I haven't tried it) since the ROM on his SE may just have other ideas... -- =Ned Horvath= ehorvath@attmail.com
siegel@world.std.com (Rich Siegel) (05/16/91)
In article <1991May15.155912.23810@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes: >have made sure ThC and ThP won't generate privileged instructions, and that >all that hand-coded library asm code is clean (right, Rich?), but not all >of us know for sure...! In fact, it's not that the compilers generate or are written with privileged instructions; it's that the debuggers need to handle exceptions, and when the machine runs in user mode, there is additional work that's necessary. R. -- ----------------------------------------------------------------------- Rich Siegel Internet: siegel@world.std.com Software Engineer Applelink: SIEGEL Symantec Languages Group
rang@cs.wisc.edu (Anton Rang) (05/16/91)
In article <1991May15.024320.9727@world.std.com> siegel@world.std.com (Rich Siegel) writes: [ about running in user mode ] > It's trivial to do, since it only involves changin a single bit >in the status register, and it'll only break software that depends on >exception stack frames Well, actually it's a little messier, since you have to make sure that the user and supervisor stack frames are aligned at trap and interrupt time, and you need to interpret the "MOVE SR" and other privileged instructions that some software uses, but it's not hard. > , but it's a completely useless thing to do on >a Mac SE, which is neither pre-emptive nor is it capable of supporting >an MMU directly. Yeah, I agree completely. :-) Anton +---------------------------+------------------+-------------+----------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | "VMS Forever!" | +---------------------------+------------------+-------------+----------------+
hamilton@kickapoo.cs.iastate.edu (Jon Hamilton) (05/16/91)
siegel@world.std.com (Rich Siegel) writes: >In article <1991May15.155912.23810@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes: >>have made sure ThC and ThP won't generate privileged instructions, and that >>all that hand-coded library asm code is clean (right, Rich?), but not all >>of us know for sure...! > In fact, it's not that the compilers generate or are written with >privileged instructions; it's that the debuggers need to handle exceptions, >and when the machine runs in user mode, there is additional work that's >necessary. It's not that difficult to go from user to supervisor mode if you know what the stack looks like. I don't see what all the hubub is about - why would anyone care which mode they were in? All a debugger would have to do is put a jmp in the memory location pointed to by the exception jump table - no supervisor mode needed for that. Again, though, _who cares_? >R. >-- >----------------------------------------------------------------------- >Rich Siegel Internet: siegel@world.std.com >Software Engineer Applelink: SIEGEL >Symantec Languages Group -- Jon Hamilton hamilton@kickapoo.cs.iastate.edu " I feel a lot more like I do now that I did before I got here " - can't remember who
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (05/17/91)
Rich Siegel writes in a message to All >Speaking sans true knowledge (as is my wont), I'd guess that "32-bit clean" >is the telling factor as to whether supervisor or user mode is to be used-if >an application is 32-bit clean, then the OS developers probably assumed that >it would be following the rest of Apple compatibility guidelines. RS> Actually, the deciding factor is whether the user turns on RS> "Virtual Memory" in his control panel. The machine still runs RS> in supervisor mode in 32-bit mode when VM is off. I thot that that was what I meant... Ah me, time to go speak to an egg...(or was it a caterpillar?). Lawson -- Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English Internet: Lawson.English@p88.f15.n300.z1.fidonet.org