KJBSF@slacvm.BITNET (01/03/87)
Date: 2 January 87 12:56-PST
From: KJBSF@SLACVM
To: INFO-ATARI16@SCORE
Subject: Forwarded message
Date: 2 January 1987, 12:52:23 PST
From: Kevin J. Burnett x3330 <KJBSF@SLACVM>
To: <INFO-ATARI16@SCORE.STANFORD>
Subject: Forwarded message
I got this off a different newsgroup, and although it pertains in particular
to the IBM PC, it should be of interest to people who have an ST. It's about
a clone of V7 Unix WITH source code, and I'd think some clever person could
port it to the ST..
Received: from prep.ai.mit.edu by wiscvm.wisc.edu on 12/30/86 at 14:59:46 CST
Received: by prep.ai.mit.edu; Tue, 30 Dec 86 15:59:49 EST
Message-Id: <8612302059.AA17910@prep.ai.mit.edu>
To: rms@prep.ai.mit.edu
Cc: info-gnu@prep.ai.mit.edu
Subject: not free, but almost
Date: 30 Dec 86 15:03:04 EST (Tue)
From: dm@bfly-vax.bbn.com
------- Forwarded Message
From: The News System <mcvax!bottercs.vu.nl!usenet@seismo.CSS.GOV>
From: ast@bottercs.vu.nl (Andy Tanenbaum)
Subject: UNIX Clone With Source Code Available
Date: 22 Dec 86 09:33:07 GMT
Organization: VU Informatica, Amsterdam
I have recently finished rewriting UNIX from scratch. This system, called
MINIX, does not contain even a single line of AT&T code, so it can be
distributed with source code. It runs on the IBM PC, XT, and AT and
those clones that are 100% hardware compatible (not all, unfortunately).
To the average, unsophisticated user, using MINIX is indistinguishable
from using V7 UNIX. Experts will notice that some relatively less
commonly used programs and features are missing.
MINIX FEATURES:
- System call compatible with V7 UNIX (except for a couple of minor calls)
- Kernighan and Ritchie compatible C compiler is included
- Shell that is functionally identical to the Bourne shell is included
- Full multiprogramming (fork+exec; background jobs in shell: cc file.c & )
- Full screen editor vaguely inspired by emacs (modeless, autoinsert, etc.)
- Over 60 utilities (cat, cp, grep, ls, make, mount, sort, etc.)
- Over 100 library procedures (atoi, fork, malloc, stdio, strcmp, etc.)
- Supports a hard disk, but also works quite well with just floppies
- Contains programs to read and write MS-DOS diskettes
- Full operating system source code is included
- Source code for all the utilities (except C compiler) is included
- System will recompile itself (requires 640K and 2 floppies or 1 hard disk)
- C compiler source is available as a separate package
- Kernel organization radically different from UNIX and much more modular
- Software is not copy protected
Furthermore, I have written a 719 page book telling you everything
you ever wanted to know about operating systems in general and this
one in particular. The book contains the manual pages, an appendix
describing how to recompile the system from the sources supplied, a
full source code listing of the operating system (253 pages), and a
cross reference map.
The software is available in 4 packages (book is separate):
- Box of eight 360K diskettes for 640K IBM PCs (512K is sort of ok too)
- Box of eight 360K diskettes for 256K IBM PCs (no C compiler)
- Box of five 1.2M diskettes for the IBM PC-AT
- 9 track industry standard tape (1600 bpi, tar format)
All four distributions contain the full source code, about 54,000 lines,
(kernel + utilities, except the compiler), virtually all of it in C. The
source code for the C compiler is also available separately (as described
in the book). The C compiler is NOT based on pcc at all. It is based on
ACK (see Communications of the ACM, Sept. 1983, pp. 654-660). The following
programs are included, among others. Like the kernel, these have all been
rewritten from scratch by me, my students, people I paid to write them or in
a small number of cases, were donated by other people to whom I am grateful:
ar basename cat cc chmod chown cmp comm cp date dd df dosread echo
grep gres head kill ln login lpr ls make mkdir mkfs mknod mount mv
od passwd pr pwd rev rm rmdir roff sh shar size sleep sort split stty
su sum sync tail tar tee time touch tr true umount uniq update wc
The book and software are being sold by Prentice-Hall. They are NOT
public domain. However, the publisher does not object to people making a
limited number of copies of the software for noncommercial use. For
example professors may make copies of the software for their students.
Universities may exchange modified versions. You may make a few copies
for your friends etc. If you want to port the software to other CPUs and
sell it, you need permission from Prentice-Hall, but they will not be
unreasonable. To acquire the software, go to any bookstore and ask them
to order the book for you:
Title: Operating Systems: Design and Implementation
Author: Andrew S. Tanenbaum
Publisher: Prentice-Hall (Jan. 1987)
ISBN: 0-13-637406-9
In the book you will find a postcard that you can use to order the
software. Please don't ask me for the software. I have already spent
approximately 8000 hours over the past 5 years writing it; I don't want
to spend the next 5 years duplicating floppy disks. The book costs about
$35. The software is $79.95 per set, including the source code. I hope
most people will consider $79.95 for the binaries and sources of
something almost functionally equivalent to UNIX as being reasonable. I
know of no other software package where you get 54,000 lines of source
code for this price. As bugs are reported, I will send Prentice Hall new
disks, so that the version they sell will remain up to date. (This also
provides some incentive to buy rather than copy.)
For those of you going to USENIX or UNIFORUM in Washington, D.C.
January 20-23, Prentice-Hall will have a stand at the show where you can
play with the software. You can also buy the stuff there, but since the P-H
people drive to Washington in their own cars, they have a limited carrying
capacity and they are only taking 50 copies, so get there early the first day.
If anyone is interested, we could set up a newsgroup
comp.os.minix to discuss minix, report bug fixes, distribute updates
of individual files etc. This letter is being multiply posted to
several newsgroups. I propose that the initial discussion take place
in comp.sys.ibm.pc (subject: MINIX) to avoid having it spread all
over the place. Besides, the only other newsgroup I read is
mod.recipes. I don't think the moderator will go for floppy disk
with Hollandaise sauce.
Andy Tanenbaum, Vrije Universiteit, Amsterdam
(mail to minix@cs.vu.nl; if your machine doesn't know where nl is
[The Netherlands], try minix@vu44.uucp, but that will vanish soon)
- -----
Thought you might find this interesting; true software publishing has
come to the UNIX world.
Carl
------- End of Forwarded Message
I, of course, have no connection to any of the organizations mentioned above.
I just thought it might be of interest.phr@mit-hermes.AI.MIT.EDU (Paul Rubin) (01/03/87)
In article <8701022135.AA07189@ucbvax.Berkeley.EDU> KJBSF%SLACVM.BITNET@forsythe.stanford.edu writes: >I got this off a different newsgroup, and although it pertains in >particular to the IBM PC, it should be of interest to people who have >an ST. It's about a clone of V7 Unix WITH source code, and I'd think >some clever person could port it to the ST.. Sadly, if someone ports it to the ST, Prentice Hall still claims to own the sources. >From: ast@bottercs.vu.nl (Andy Tanenbaum) >Date: 22 Dec 86 09:33:07 GMT >Organization: VU Informatica, Amsterdam > > ... I know of no other software package where you get 54,000 lines >of source code for this price. I know of at least one. Paul Rubin Free Software Foundation (sometimes)
sci@kestrel.ARPA (Mike Liveright) (01/04/87)
I talked to the publisher of MINIX {Prentice Hall} about the porting
of the software to other CPU's. Yes -- they do have some rights on the
source code... On the other hand, he person I talked to said that they want to
be reasonable.
After some friendly discussion, it was my impression that they
were feeling their way, and would be willing to:
1) Ask NO MORE than the $80.00 that they are asking for the
source code to have the source code and/or run MINIX or a derived system
on a CPU. {I felt that this was reasonable since thay, and the author, have
done a lot of work} Thus if someone ports MINIX to a CPU, then other people
could use it, and the utilities after paying this royality. P.S. they seem
to be willing to permit a person to make a few copies at no charge for
"educational" purposes.
2) Discuss "volume" arrangements to possibly reduce this
royality further under the "right" conditions.
As I understand it, the book will be out "real soon now" and it
will be possible to get the source code in a few months. If it is good
code, and can be ported to other CPU's, than I believe i might well be
the basis of a Share-Ware UNIX type system.henry@utzoo.UUCP (Henry Spencer) (01/04/87)
> ...a clone of V7 Unix WITH source code, and I'd think some clever person > could port it to the ST.. Doing any form of Unix on the ST is hard because of the lack of MMU. The IBM PC, revolting though it is, does have the half-baked excuse for an MMU that the 8086 itself supplies. Unix on the ST is not impossible, just a lot of work and rather awkward -- fork() is the bad part on a system with no relocation hardware. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
phr@mit-hermes.AI.MIT.EDU (Paul Rubin) (01/04/87)
In article <16065@kestrel.ARPA> sci@kestrel.UUCP (Mike Liveright) writes: > I talked to the publisher of MINIX {Prentice Hall} about the porting >of the software to other CPU's... it was my impression that they >were feeling their way, and would be willing to: > > 1) Ask NO MORE than the $80.00 that they are asking for the >source code to have the source code and/or run MINIX or a derived system >on a CPU.... > 2) Discuss "volume" arrangements to possibly reduce this >royality further under the "right" conditions... > > As I understand it, the book will be out "real soon now" and it >will be possible to get the source code in a few months. If it is good >code, and can be ported to other CPU's, than I believe i might well be >the basis of a Share-Ware UNIX type system. How can something be "Share-ware" if you have to pay someone for the privilege of having a copy? Wake up, people.
iarocci@eneevax.UUCP (Bill Dorsey) (01/04/87)
In article <7472@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Doing any form of Unix on the ST is hard because of the lack of MMU. The >IBM PC, revolting though it is, does have the half-baked excuse for an MMU >that the 8086 itself supplies. Unix on the ST is not impossible, just a >lot of work and rather awkward -- fork() is the bad part on a system with >no relocation hardware. >-- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,decvax,pyramid}!utzoo!henry I beg to differ. If mimix runs on an 8086 system, it could be ported to a 68000 system with little difficulty. If, as I gather you believe, mimix were to use segments for processes, it would require that 64k be the minimum and the maximum limit for all processes. That would be ridiculous! Contrary to popular belief, an MMU is not critical for all multi-tasking oper- ating systems. If the operating system doesn't implement virtual memory, it can function quite well without an MMU. There are quite a few examples of operating systems falling into this category. In summary, if you are willing to put up with processes being able to read each others address space as well as write to it, and virtual memory isn't needed, then an MMU isn't all that critical. Properly functioning processes wouldn't access memory outside of their address range, anyway. The practical effect might be more frequent crashes during the debugging stage of programs as opposed to core dumps. But under normal use, you wouldn't notice the difference!
grr@cbmvax.cbm.UUCP (George Robbins) (01/04/87)
In article <2772@mit-hermes.AI.MIT.EDU> phr@hermes.UUCP (Paul Rubin) writes: >> As I understand it, the book will be out "real soon now" and it >>will be possible to get the source code in a few months. If it is good >>code, and can be ported to other CPU's, than I believe i might well be >>the basis of a Share-Ware UNIX type system. > > >How can something be "Share-ware" if you have to pay someone for the >privilege of having a copy? Wake up, people. Gee, are you GNU guys so dazed by your own rhetoric that you can't distinguish between a <$100 minix license and a > $50K unix license? Or is it just that it's less then the "nominal" GNU "distribution fee"? 1/2 8-) -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jsgray@watmath.UUCP (Jan Gray) (01/04/87)
In article <539@eneevax.UUCP> iarocci@eneevax.UUCP (Bill Dorsey) writes: >In article <7472@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>Doing any form of Unix on the ST is hard because of the lack of MMU. The >>IBM PC, revolting though it is, does have the half-baked excuse for an MMU >>that the 8086 itself supplies. Unix on the ST is not impossible, just a >>lot of work and rather awkward -- fork() is the bad part on a system with >>no relocation hardware. >> Henry Spencer @ U of Toronto Zoology > >I beg to differ. If mimix runs on an 8086 system, it could be ported to a >68000 system with little difficulty. If, as I gather you believe, mimix were >to use segments for processes, it would require that 64k be the minimum and >the maximum limit for all processes. That would be ridiculous! Actually, I rather suspect that minix does use "segments for processes", and since the system runs on 8086s it almost certainly limits processes to 64K. >Contrary to popular belief, an MMU is not critical for all multi-tasking oper- >ating systems. If the operating system doesn't implement virtual memory, it >can function quite well without an MMU. There are quite a few examples of >operating systems falling into this category. I don't think you read all of Henry's "hit-the-nail-on-the-head" posting. An MMU (for address translation, not protection or virtual memory) *is* critical to implement *fork()*. Remember the fork() system call returns two identical processes (except for fork() return value). Think how you might accomplish this without an MMU. (You can't simply copy the process image to another address, it probably contains direct pointers to addresses in the original image.) The two schemes I can think of are: 1. Change the C compiler so all global references are relative to a base register (is this what Megamax C does now?). Now we can fork() by copying the image and moving the base pointer in the copy. Since the 68000's X(An) addressing mode has a 16 bit displacement, you'll be stuck with 64K processes (unless you access globals in some even less efficient scheme). Remember that pointers also have to be base pointer relative! 2. Both (all?) images will share the same address space, by alternately swapping them in and out of that space. Even if you keep the "backing store" elsewhere in RAM, this is unattractive, but probably easier to do than (1). I believe this scheme was used to run some sort of minimal UNIX on MMU-less pdp-11s. "Too bad the 68070 isn't going to be pin compatible with the 68000", Jan Gray jsgray@watmath University of Waterloo (519) 885-1211 x3870 [NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode, foo] [CSIS food: supermailbox, tuna, fiberglass coffins, Mirabel, microfiche]
jmc@ptsfa.UUCP (Jerry Carlin) (01/04/87)
In article <539@eneevax.UUCP> iarocci@eneevax.UUCP (Bill Dorsey) writes: >In article <7472@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>Doing any form of Unix on the ST is hard because of the lack of MMU. >Contrary to popular belief, an MMU is not critical for all multi-tasking oper- >ating systems. Beckemeyer's MT-CSHELL is a multi-user, multi-tasking operating system with a UNIX "flavor" and runs on the ST and therefore forms an existance proof that others are possible. -- voice= 415 823-2441 uucp={ihnp4,dual,qantel}!ptsfa!jmc
cmcmanis@sun.uucp (Chuck McManis) (01/06/87)
What Henry was probably referring to is the segment registers that the
80x86 family has. They offer a certain amount of code relocatability
that is unavailable on vanilla 68K machines. (Yes you can use "small
model" on the 68000 but you still have problems with the dynamic
loading of tasks) When properly written 8086 segments can be swapped
into and out of memory without the program knowing about it.
But I agree, multitasking doesn't imply an MMU. Look at either the Amiga
or OS-9 on the ST for examples.
The biggest problem of porting MINIX would be porting the C compiler,
since compiler design breaks down into two camps, the parser and the
code generator. You would literally have to rewrite half of the compiler
to port it.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.jec@iuvax.indiana.EDU (01/06/87)
Okay, I give up. How in the world do you do a fork() without some
sort of MMU. Let me review how I think fork() works just in case I'm wrong.
Fork() takes a process image-- text, bss, data, and stack and makes
a new process image.
Two alternatives:
(1) Allowing the process to be moved after loading:
Okay, now, you can share the text, that is no problem. This is
even a good idea since programs may have absolute addresses in them. The
bss, well, no you can't share that. So you have to make a separate copy
of it. Ditto for data and stack. But wait! What do you do about all of
those nasty absolute addresses on the stack!?!
Well, obviously you have to make those addresses relative.
Okay, what do you make them relative too: simple, the start of the
text segment. We can just decide that all of our addresses are going to be
relative to the start of the text segment and we'll just load that in one
of the A registers and address off that. Uh, wait a minute, that gives us
a 32K address space! A slight deficiency of the 68000. Okay, we'll bite
the bullet and do the arithmetic of adding it. That won't be too bad,
only >TWO< instructions per memory address:
MOVEA.L <TEXTSTART>,A5 ; the OS could do this, but then again, we
; don't have a three pronged ADD anyway so
; we might as well load it.
ADDA.L <RELADDR>,A5 ; plus the relative address
MOVEA.L (A5),D0 ; the thing we want
Now we have another problem: what happens when we get swapped out!
This needs to be an atomic operation! Well, another few instructions:
CLR.B SWAPPABLE ; don't swap
.
.
ADDQ.B #1,SWAPPABLE ; okay, it's cool
And we just don't swap when it says we can't. If we were really
ingenious we could steal the single step interrupt vector and walk through
instructions until we can swap.
But the obvious response to this is...YYUUUCCCCCK! >FIVE<
instructions per memory access, not to mention the C compiler would need to
be drastically changed to support this.
(2) STATIC LOADING
Okay, now for the alternative: the running process gets put in a
FIXED memory location. We can swap to memory most of the time if we have
enough of it and we don't have to screw around with weird addresses. This
is the only solution that I can think of and it makes context switches VERY
expensive.
Okay, now for an 'optimization': we dynamically allocate the process'
load address when it is exec()'ed. This wins in that we don't have to move
a process on EVERY context switch. The problem is, of course, fragmentation
and an extremely complex process scheduler/exec(). Also, a forked() process
will have to share the same load address. This is bad, but unavoidable--
especially when you consider /etc/init which forks for every tty that has a
getty on it.
An MMU is a >BIG HUGH ENORMOUS< win when it comes to multi-tasking,
by the way, because it allows you to do offset addressing in hardware. You
don't have to worry about moving processes in memory, you diddle the pointers
to make it look right to the program-- the OS does with with probably about
30 machine language instructions.
The Amiga manages to multi-task by using the static loading method.
From experience let me tell you that fragmentation is a real problem with
this method. You can have 300K free and not be able to load a 50K program.
The Amiga also does not do swapping and so fork() is probably impossible.
I don't know how the Atari does it with MT Shell, but I imagine it isn't
much better.
Okay, there you have it. How I think MINIX would have to work on a
68000 w/o an MMU. I've actually given this some serious thought having tried
to port a V7 kernel to the 68000. Our solution was to modify the hardware and
put in an MMU (the sleazy 68451 at that-- better than nothing). Another time
I was looking into a kernel for the 68000 that would allow relocation of the
executable objects. It is possible, but is very expensive and puts serious
limits on the programmer (especially the assembly language program that has
to deal with all the weirdness of SWAP/CANTSWAP).
III Usenet: iuvax!jec
UUU I UUU jec@indiana.csnet
U I U
U I U Phone: (812) 335-5561
U I U U.S. Mail: Indiana University
UUUIUUU Dept. of Computer Science
I 021-C Lindley Hall
III Bloomington, IN. 47405
dalem@hpfcph.HP.COM ( Dale McCluskey) (01/06/87)
/ hpfcph:comp.sys.atari.st / jmc@ptsfa.UUCP (Jerry Carlin) / 9:59 am Jan 4, 1987 / > > Beckemeyer's MT-CSHELL is a multi-user, multi-tasking operating system > with a UNIX "flavor" and runs on the ST and therefore forms an > existance proof that others are possible. Are you saying that MT-CSHELL is a complete operating system, as opposed to a command interpreter? Dale McCluskey
phr@mit-hermes.AI.MIT.EDU (Paul Rubin) (01/06/87)
In article <10979@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: > >The biggest problem of porting MINIX would be porting the C compiler, >since compiler design breaks down into two camps, the parser and the >code generator. You would literally have to rewrite half of the compiler >to port it. > No, you'd have to rewrite the whole compiler, since the compiler sources don't come with MINIX. You can get them but you have to pay big $$$. (Anything good enough for Tanenbaum to charge lots of money for, you don't get for $79.95). The GNU C compiler will be released soon and it generates better 68000 code than any commercial compiler we've compared it with. Maybe someone can make it work on an Atari. (Note: actually, parsing and generating machine code are each much less than 1/2 of a compiler. Between them, there are a lot of machine-invariant translation and optimization phases before instructions actually get written out.)
henkp@nikhefk.UUCP (Henk Peek) (01/07/87)
In article <10979@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes:
=What Henry was probably referring to is the segment registers that the
=80x86 family has. They offer a certain amount of code relocatability
=
=The biggest problem of porting MINIX would be porting the C compiler,
=since compiler design breaks down into two camps, the parser and the
=code generator. You would literally have to rewrite half of the compiler
=to port it.
=--Chuck McManis
=uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
Some information for who want to start .....
The MINIX C compiler is the ACK (Amsterdam Compiler Kit). This is a
portable C (and Pascal) compiler with backends for the most types
of micros including 68K. An educatiomal licence for all systems
is not expensive. (You get about 4 MB of source code).
henk peek HIKHEF-K Amsterdam Holland
henkp@nihefk.UUCP !seismo!mcvax!nikhefk!henkp.UUCPhenry@utzoo.UUCP (Henry Spencer) (01/07/87)
> What Henry was probably referring to is the segment registers that the > 80x86 family has. They offer a certain amount of code relocatability... Right. It's relocation, not protection or virtual memory, that is crucial to implementing Unix fork() without serious performance trouble. Virtual memory is nice but not important for many things (the Unix I am typing this on doesn't have it). Protection isn't vital if you tread carefully when/if doing program development. On a 68000 without an MMU, like the ST, the only way to do relocation is with extensive cooperation from the compiler. And the resulting code will be more complicated and slower than normal 68000 code for the same program. Possible, but not wonderful. You can do fork() without relocation if you are willing to have only one of the two (or more!) processes "swapped in" -- in memory at the location they expect to be running at -- at once. This is a performance hassle no matter how you slice it, and making it run quickly requires either a *fast* disk (I'm talking Fujitsu Eagle, not $500-20MB-microcomputer-junkbox, and *most* *certainly* not microcomputer floppy!) or else a lot of spare memory. It might be viable on a 1040ST if you keep program size down, although I'd still be a bit worried about all that memory copying. If you're willing to admit that you are *not* implementing Unix proper, you can get away without fork for a lot of purposes. Berkeley's awful "vfork" kludge will suffice for the more common requirements, particularly if you are willing to rewrite occasional bits of code to make them work in the new environment. And if you aren't going to implement anything resembling fork, then of course it's possible, as witness many multitasking systems running on unprotected machines. > The biggest problem of porting MINIX would be porting the C compiler, > since compiler design breaks down into two camps, the parser and the > code generator. You would literally have to rewrite half of the compiler > to port it. Note also that MINIX does not include compiler source, as I recall. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jdg@elmgate.UUCP (Jeff Gortatowsky) (01/07/87)
In article <2773@mit-hermes.AI.MIT.EDU> phr@hermes.UUCP (Paul Rubin) writes: > >The GNU C compiler will be released soon and it generates better >68000 code than any commercial compiler we've compared it with. >Maybe someone can make it work on an Atari. You made a mistake letting this one out as you'll most likly see lots(!) of these.... How? When? And where? I'm ready to start attemping the port NOW. Maybe I could get a head start? Oh yes, port to the Amiga as well (I have both). Have you compared it to GreenHill's $1200 68000 UNIX CrossCompiler? -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company <Kodak won't be responsible for the above comments, only those below>
bzs@bu-cs.BU.EDU (Barry Shein) (01/08/87)
> Okay, I give up. How in the world do you do a fork() without some >sort of MMU. Let me review how I think fork() works just in case I'm wrong. Am I missing something or is it just that no one on this list ever heard of mini-unix which certainly ran on PDP-11/10s and other PDP-11s w/o MMUs. Is that sufficient for an existence proof? We ran it around 10 years ago when I was at Harvard and it did the job fine, thank you. What about the old PIXEL 68K based UNIX systems with no MMU, no memory protection etc. Hey, it ain't ideal, but it is doable which is what a comment like the above seems to doubt. Reminds me of those old physics jokes proving that a bee cannot fly... -Barry Shein, Boston University
jmc@ptsfa.UUCP (Jerry Carlin) (01/09/87)
>Are you saying that MT-CSHELL is a complete operating system, as opposed >to a command interpreter? It is close to an OS - multi-user and multi-tasking but it relies on GEM/TOS for fundamental services. It also relies on a real-time executive which Beckemeyer also wrote. If its not an "operating system" its really close to one. -- voice= 415 823-2441 uucp={ihnp4,dual,qantel}!ptsfa!jmc
wsr@lmi-angel.UUCP (Wolfgang Rupprecht) (01/09/87)
In article <> jec@iuvax.indiana.EDU writes: > Okay, I give up. How in the world do you do a fork() without >some sort of MMU. Running without an MMU is clearly a loser. I believe that you can still have a fork(), however, it you don't mind running at a snail's pace. What you can do is take a snapshot of the process at fork time, and send this copy off to swap space. In this manner you never end up having more than one process on core at any time. All non-running processes will be swapped out. No address translation is required since no two processes will ever be co-resident. Now, if only one could protect kernal address space from corruption... -- Wolfgang Rupprecht {harvard|decvax!cca|mit-eddie}!lmi-angel!wsr
iarocci@eneevax.UUCP (Bill Dorsey) (01/11/87)
There has been much discussion about porting MIMIX over to the ST. The biggest problem people have been complaining about is the difficulty of implementing fork(). The two approaches that have been discussed are using a compiler which generates relocatable code, and swapping a program into and out of a fixed area of memory. The discussion so far seems to indicate that it would be more feasible to swap a program into and out of the memory location it was loaded into than to write a compiler that generates relocatable code. The argument, if I recall, is that such a compiler would generate slow and inefficient code, not to mention would require the effort of writing such a compiler. Then, the discussion goes on to point out that such memory swapping is highly inefficient, to the point that it wouldn't be worth porting MIMIX. Well, I was all ready to give up on the idea as too much effort, when I was told that the Megamax C compiler generates fully relocatable code. All code is either PC relative, or referenced through an address register which contains the location of the base of the code/data area. While I'm not real familiar with the compiler (I have Mark Williams), I am aware the the comp- iler generates fast and efficient code, and is considered one of the better C compilers for the ST. So, using the Megamax C compiler, where is the difficulty in implementing the fork() function? It's rather trivial to make an image of a running program in another area of memory, and change the address register used for variable references, etc. All of this could be done at the time the fork() function was invoked, no more painful swapping or writing compilers!
henry@utzoo.UUCP (Henry Spencer) (01/11/87)
> Am I missing something or is it just that no one on this list ever > heard of mini-unix which certainly ran on PDP-11/10s and other PDP-11s > w/o MMUs. ... Try running mini-unix on floppies (we did) and you'll know why there's still a problem. Mini-unix generally ran on machine with no MMUs, yes, but those machines generally had relatively fast hard disks. So mini-unix kept one program in memory at a time and swapped every time it did a context switch. Even with good hard disks, mini-unix performance didn't sparkle. > ...Reminds me of those old physics jokes proving that a bee cannot fly... Considered as a fixed-wing aircraft (which it isn't) a bee can't fly; there's nothing wrong with that proof except the initial assumption. Same situation. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (01/11/87)
> ...implementing fork(). The two approaches that have been discussed are > using a compiler which generates relocatable code, and swapping a program > into and out of a fixed area of memory. ... > Well, I was all ready to give up on the idea as too much effort, when I was > told that the Megamax C compiler generates fully relocatable code. All > code is either PC relative, or referenced through an address register which > contains the location of the base of the code/data area. ... Relocatable code is one thing; relocatable data is quite another. Modern machines generally make it fairly easy to generate code which is not tied to specific assumptions about its own location or the location of its data areas, but avoiding absolute addresses in the data is another story. I would be very surprised if a Megamax C pointer variable did not contain an absolute address. Absolute addresses also show up in things like return addresses on the stack. Fixing this is a lot of work and costs a lot in speed. Better to copy chunks of memory around; that will not be too bad *IF* the programs stay small. (Most of the MINIX utilities are small.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
bzs@bu-cs.BU.EDU (Barry Shein) (01/11/87)
Yes, we had a system which swapped to floppies also (MINC-11/RX02, actually we had a system up which did it with non-dma RX01s but that was too painful to think about...) Hmm, if the problem is relocation how awful would swapping to memory be? That is, rather than swapping in and out of a floppy you just rearrange the processes in memory on context switch. Oh, it won't be dazzling, but certainly many times faster than a floppy. Or maybe I should just throw my hands up and suggest getting the right hardware to do the job, the law of diminishing returns slowly comes into play (especially because one strongly suspects that by the time the bugs are out of an O/S and possibly a C compiler which meets the above requirements ATARI or someone like them will have announced a 2MB systems with MMU and reasonable hard disk for under $2K [oops, I think that's here already :-]) -Barry Shein, Boston University
greg@xios.UUCP (Greg Franks) (01/15/87)
In article <7510@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ...implementing fork(). The two approaches that have been discussed are >> using a compiler which generates relocatable code, and swapping a program >> into and out of a fixed area of memory. ... >absolute address. Absolute addresses also show up in things like return >addresses on the stack. Fixing this is a lot of work and costs a lot in >speed. Better to copy chunks of memory around; that will not be too bad >*IF* the programs stay small. (Most of the MINIX utilities are small.) Worse than return addresses, are other addresses, like pointers to data. Return addresses would be easy to fix (backtrack up the stack and add offset to return PC or something; but pointers to data (pass by address) would be impossible to find. However, this discussion is mute: :From nrcaer!dciem!utzoo!mnetor!seismo!mcvax!botter!ast Tue Jan 13 12:40:15 EST 1987 (Andrew Tanenbaum) :As to the port to the Atari/Amiga/etc as far as I see, there are no technical :problems with the MMU. The trouble is as follows. When you fork, the :child has to go somewhere else in memory than where the parent was. :Unfortunately, the child's stack contains absolute addresses, such as :the return from the fork routine. If the child runs somewhere other :than where the parent was, it will crash. :There are a couple of solutions, the simplest of which is this. When the :child is created, record in the process table where the parent was. :When it is time to run the child, just swap the parent and the child, :and actually run the child where it belongs. When the parent wants to :run, swap them again. Although this sounds horrendous, it is not at all :so bad. Swapping two 10K programs in memory might take 30 millisec. :MINIX programs are small. :The only big ones are the compiler passes, cpp, cem, opt, cg, and asld. *** One other interesting note.... :I would like to see a MINIX version for the Atari/Amiga/etc. The 68000 is :clearly much better than the 8088, but the PC has a lot of software going for :it. ... A colleague of mine at Philips has :already started to port MINIX to the Atari. He is an absolutely top rate :programmer, but he is VERY busy, so he doesn't have much time. ... :What I would like to find is someone who: :(1) knows the Atari (Amiga, Macintosh, etc) hardware well :(2) knows UNIX well on the outside and moderately on the inside :(3) has a substantial amount of free time :(4) has access to an IBM PC for testing things etc. (not essential, but helps) Item 3 - Who has time? Aren't we all busy reading news all day? :-) :-) :-) This stuff is in comp.sys.ibm.pc. I suggest that all you who are interested in this topic resubscribe, and based on what I have seen, there does appear to be a lot of interest. Use some creativity in the kill file; search for MINIX - all postings are marked as such. I have directed followups to that news group. -- Greg Franks (613) 725-5411 "Vermont ain't flat" {net-land}!utzoo!dciem!nrcaer!xios!greg (Other paths will undoubtably work too - your mileage will vary)