m5d@bobkat.UUCP (Mike McNally ) (01/21/87)
What a happy newsgroup this seems to be.
Mr. Tanenbaum recently mentioned that MINIX is being ported to the
Atari ST. This has made me curious about the implementation. I can
easily understand how memory management is accomplished on the iAPX 86
processors: code is all small model, and pointers are sixteen bits
long. No real addresses need be floating around; everything is
dynamically relocatable.
The 68000, on the other hand, might pose a problem. Will pointers be
sixteen bits long? It seems to me that there will be some nasty code
involved in taking addresses of "auto" variables.
--
**** ****
**** At Digital Lynx, we're almost in Garland, but not quite ****
**** ****
Mike McNally Digital Lynx Inc.
Software (not hardware) Person Dallas TX 75243
uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474jsm@vax1.UUCP (01/24/87)
In article <454@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (dlsh)) writes: >What a happy newsgroup this seems to be. > I'm certainly happy to get a microcomputer U**X, with source, for $80 ...
m5d@bobkat.UUCP (01/28/87)
In article <253@vax1.ccs.cornell.edu> jsm@vax1.UUCP (Jon Meltzer) writes: >In article <454@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (dlsh)) writes: >>[ this is me ] >>What a happy newsgroup this seems to be. >> >I'm certainly happy to get a microcomputer U**X, with source, for $80 ... Gee, I wasn't trying to be nasty. I think it's a good idea too. Nobody has responded to my original query: how does the compiler (ACK?) simulate the *complete* relocatability provided by the 8088 (small model, of course) on the 68000? How does the OS copy my data segment when my process does a fork()? What about the pointers; they're all wrong! I just don't get it. I don't mean to sound like I'm down on the project; I'm just curious. -- **** **** **** At Digital Lynx, we're almost in Garland, but not quite **** **** **** Mike McNally Digital Lynx Inc. Software (not hardware) Person Dallas TX 75243 uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474
jpn@teddy.UUCP (01/29/87)
>Nobody has responded to my original query: how does the compiler (ACK?) >simulate the *complete* relocatability provided by the 8088 (small >model, of course) on the 68000? How does the OS copy my data segment >when my process does a fork()? What about the pointers; they're all >wrong! I just don't get it. Interestingly, the 68000 also has a "small" model, if all data operations are be done with 16bit offsets off some address register! All it takes is for the operating system to set up some data base register (or as many base registers as you can afford), and for the compiler to avoid changing this register(s). Actually, since "pointers" are really only offsets (integers), nearly all the address registers could be used for base pointers. Also, the compiler can only use certain addressing modes, but that way, a fork can be accomplished by the OS by changing the base register(s). This limits you to 64K(*n) data, of course. Note that the PROGRAM text does not need to be limited to 64K, unless you need the text to be relocatable as well. You are right though, with both 8086 and 68000 architectures: If the large memory model is used, it takes hardware support (virtual memory) to provide true relocatable code.
shap@sfsup.UUCP (02/01/87)
In article <486@bobkat.UUCP>, m5d@bobkat.UUCP (Mike McNally ) writes: > > Nobody has responded to my original query: how does the compiler (ACK?) > simulate the *complete* relocatability provided by the 8088 (small > model, of course) on the 68000? How does the OS copy my data segment > when my process does a fork()? What about the pointers; they're all > wrong! I just don't get it. First statement: I haven't done it, this is only conjecture. It might be done (at some cost) by coding as follows: 1. All jmp instructions and the like as relative jumps (for text relocatability). 2. Absolute addresses can be dealt with by implementing pointers as offsets, much like an 8086, and having the compiler generate the absolute address by doing in software the equivalent of what a segment register does. If you know where the user's user-info-block is, it might hold a pointer to the start of data space, which gets bumped when data space is moved. Then the code generator can generate code which does the pointer arithmetic whenever you dereference a pointer. So long as data space is contiguous, pointer arithmetic is still cheap. The only cost comes in dereferencing. *** end of conjecture: It would be slow, awkward, and difficult, but there are compilers which generate relocatable code for flat architectures. The principles (even though I don't know them) therefore have to be well understood. Jon Shapiro
ADMIN@spectrix.UUCP (ADMIN) (07/01/87)
I asked about Minix on the ST. I have the answer ...
Unfortunately, due to a file system crash, I cannot directly copy the
response, but here is a precis of it:
From Andy Tanenbaum:
1) Minix itself is roughly 80% done; utilities yet to be done (depending
on modifying the existing compiler to 68000/Atari
2) The book from Prentice Hall (Operating Systems: Design and Implementation)
will not be updated until 1992.
3) No firm date yet for when Minix on the ST will be available.
One further question ... what sort of disk resources are required to
reasonably run Minix? 10 Mb? 20MB+ ? And what sort of hard drives are
available for the ST (all I have seen is 20 Mb).
Russell Crook (...!seismo!{mnetor,utzoo}!spectrix!rmc)dragon@oliveb.UUCP (Give me a quarter or I'll touch you) (07/02/87)
in article <296@spectrix.UUCP>, ADMIN@spectrix.UUCP (ADMIN) says: > > One further question ... what sort of disk resources are required to > reasonably run Minix? 10 Mb? 20MB+ ? And what sort of hard drives are > available for the ST (all I have seen is 20 Mb). > > Russell Crook (...!seismo!{mnetor,utzoo}!spectrix!rmc) Supra makes large model hard disks. At the recent World Of Atari expo in Santa Clara, Supra showed a 250mb (!) hard disk. Berkeley Micro Systems has an interface board (set) that will allow one to connect just about any ST506/412 or SCSI interfaced hard disk. I don't know much about them, but BTL apparently offers the same sort of setup as well as ready to run units. -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ |_____
zemon@felix.UUCP (Art Zemon) (07/02/87)
In article <296@spectrix.UUCP> rmc@spectrix.UUCP (Russell Crook) writes: > >One further question ... what sort of disk resources are required to >reasonably run Minix? 10 Mb? 20MB+ ? I'm running Minix comfortably in two megabytes. I have all of the file system and kernel sources and .s files on line, all of the binaries from /bin and /usr/bin and all of the stuff in /lib, etc., since I don't use any RAM disk at all. And I still have gobs of room to play. -- -- Art Zemon FileNet Corporation Costa Mesa, California ...!hplabs!felix!zemon
braner@batcomputer.tn.cornell.edu (braner) (07/03/87)
[in response to question whether 20Meg HD is enough for MINIX] If MINIX on the ST will be similar to the IBM-PC version, it won't require much in terms of disk space. MINIX is designed to be usable off a FLOPPY. It is compact and so are the utilities (about 1K each) and the commonly used utilities are kept in a RAMdisk. If it can run on a 640K RAM / 360K disk machine I'm sure it will run on a 1 (2?4?) Meg RAM / 720K disk machine. The compactness of MINIX is its major advantage over other UNIX lookalikes and other multi-tasking schemes. Now if it was just completed... - Moshe Braner PS: don't worry, you'll need those 20 Megs for TeX 71 P