bandy@amdcad.UUCP.UUCP (02/07/87)
Hi all, I'm sure that by now you've heard about Minix, and you're thinking to yourself: "why didn't he write it for a decent machine in the first place?" Well, given his constraints, he did port it to a decent machine - there isnt' a single cheap 68k system on the market that has a mmu in it, yet the 8086 family has had one since day one (well, not exactly an mmu, but it will provide some protection against run-away programs if the compiler doesn't generate instructions that twiddle the segment registers). Anyhow, in order for us to do a 68k port we could do one(?) of the following: 1) Retro-fit some sort of mmu (68451? (ugh)) onto the boxes -- those of us whose cpu card's manufacturer had a little foresight might even have space for a socket for this beastie. 2) Hack up Stallman's gnu c compiler so it will generate PIC (but what to do when you take the address of a variable on the stack?) 3) Fit all the programs together like the Amiga does. 4) Physically separate kernel memory from user memory and then move each user process to its execution location whenever it runs (ick). Given that I'm a little shy on information about #3, I'd like to ask the Amiga gurus here how the Amiga manages to do multitasking. (for that matter, how does OS9 mangage it?) Of course, we'll all have to write our own device drivers, but that shouldn't be any novelty to us now, should it? Also, I remember that AndyT. said that a friend of his was working on a port to the ST.. I'll try to find out what method he's using. andy
mwm@VIOLET.BERKELEY.EDU.UUCP (02/07/87)
>> Well, given his constraints, he did port it to a decent machine - there >> isnt' a single cheap 68k system on the market that has a mmu in it, yet the >> 8086 family has had one since day one. From what I recall, he didn't use that - he just assumes that things are well-behaved. I think the ST port is doing the same. In any case, getting in contact with those people is probably a good start, as you should be able to use their kernel (context switching code, in this case). >> 2) Hack up Stallman's gnu c compiler so it will generate PIC (but what to >> do when you take the address of a variable on the stack?) What's the problem? References to the stack go through the SP, which will be switched with the rest of the context. I'm sure one of the OS/9 people on the list can enlighten us further. That still leaves you with an unprotected multi-tasking system, but that's an improvement over an unprotected single-tasking system. <mike BTW, did you buy the book, Andy? First impressions?
mwm@VIOLET.BERKELEY.EDU.UUCP (02/09/87)
------- Forwarded Message From: Jan Gray <jsgray%watrose.waterloo.edu@RELAY.CS.NET> Subject: Re: Minix to the 68k? Newsgroups: mod.computers.68k In-Reply-To: <8702070300.AA18784@violet.berkeley.edu> Organization: U. of Waterloo, Ontario Cc: The problem is fork(), which requires making a copy of the original data image. Without memory mapping, where do you put it so that pointers don't break? Jan Gray jsgray@watrose University of Waterloo (519) 885-1211 x3870 [True. Anyone know what the 8086 version of Minix does? Force use of the small model?] ------- End of Forwarded Message Administrative note: Now that info-68K is acting like it's alive again, I should point out that it's gatewayed to usenet as mod.comuters.68K. Postings from there appear in my mailbox, where I forward them to info-68k. Until I (or someone else) gets around to fixing redist, they'll look like the above. E-mail replies should go to the author, whose address can be found in the From: line in the forwarded message. <mike
jejones@mcrware.UUCP.UUCP (02/10/87)
Hiya! I think <mike and Steve Blasingame have described stuff at least as well as I could, but I should mention also that there is hardware that lets you protect portions of the address space without mapping it. You can still fragment memory, but it's much harder for a runaway program to trash the system or other folks' memory. The ST and Amiga, as far as I know, don't have the beast, so you get to live dangerously, but (1) as <mike says, multitasking is more useful than single-tasking, and (2) there's nothing about TOS or CP/M68K that makes programmers magically write perfect code with no wild pointers. James Jones
HELLER@cs.umass.edu.UUCP (02/13/87)
Some thoughts about whether one *really* needs a MMU: First off, UNIX is not so much a multi-tasking system as a multi-*user* system: That is on a typical UNIX system, you are not the only user, and it is considered very unfriendly to clobber someone else's core image (even inadvertently). Thus UNIX needs to worry about process memory protection. If one abandons the multi-user idea (which make sense on a *small* personal-type system, like the Amiga or ST, or even some of the slightly bigger systems like Stride 420s or 440s), then there is not any real need to worry about process protection - if a program gets out of control, well you can just re-boot (i.e. reset button, power-cycling, whatever), with no great loss (well maybe in-core file buffers...). On my Stride 440 I run CP/M-68K under Stride's "Multi-user" BIOS. This BIOS is not really multi-user and does not use an MMU. Instead it assumes that each "user" (who gets his/her own copy of whatever O/S he/she is running) is carefull. This works out fine with the p-System, which is under the control of the p-code interpreter (which provides a sort of software MMU). Under CP/M-68K, you really have to be carefull, but I have not had any problems. (Main thing to worry about is disk partition sharing - only *one* user should have write access to a partition - CP/M-68K buffers disk allocation tables.) It is mostly a matter of carefull programming. Also, under CP/M-68K a runaway pointer will probably clobber the stack and very quickly get you some sort of memory access violation (missaligned work/long ref or non-existent memory ref or cause a rts instruction to return to the middle of you data area with a probable illegal instruction...). Other notes: I believe OS9 works much like Stride MU BIOS (except only one copy of the O/S kernel is in memory and the file system knows about multiple processes doing I/O). The O/S on LISP Machines also use a "single address space" model. The LISP Machines do have an MMU, but that is needed for virtual memory management, not for process context games - that is, on a LISP Machine, all of the processes all share the *same* data and program areas - the only memory which is private is the stacks and machine register sets (part of the process context). Make inter-process communication trivial: just to a SETQ to some common, special variable. Again, LISP machines are not multi-user, just multi-tasking. Given these constraints, it should be posible to implement a multi-tasking O/S without having to hassle with a MMU. Robert
mwm@VIOLET.BERKELEY.EDU.UUCP (02/14/87)
>> Given these constraints, it should be posible to implement a >> multi-tasking O/S without having to hassle with a MMU. True; it's been done (as many have pointed out). However, if you're doing C or assembler development, loose pointers, mis-typed parameters for calls, and other things will cause the system to die. This is enough of a pain that ASDG is marketing a ram-disk driver that tries to recover what was in memory before the crash when it comes up. For interpreted Pascal, or Lisp, this won't be a problem. But someone's gotta put up with porting those things (and editors, and compilers, and etc.) in the first place. Even under such conditions, the result is _still_ better than an unprotected single-tasking OS. <mike