Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: comp.sys.atari.st Subject: Re: Forwarded message Message-ID: <7487@utzoo.UUCP> Date: Tue, 6-Jan-87 20:27:29 EST Article-I.D.: utzoo.7487 Posted: Tue Jan 6 20:27:29 1987 Date-Received: Tue, 6-Jan-87 20:27:29 EST References: <8701022135.AA07189@ucbvax.Berkeley.EDU> <7472@utzoo.UUCP> <539@eneevax.UUCP>, <10979@sun.uucp> Organization: U of Toronto Zoology Lines: 40 > 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