UD138985@NDSUVM1.BITNET (02/23/88)
What is the current status of the Minix port to the ST, ie when
is it going to be compleated? Also, I would like to know exactly who
owns the rights to Minix. Does a company have a copyright on it and
if so, who? Or is it shareware/freeware user supported stuff?
Thanks in advance for any replies.
Bob
BITNET: UD138985 at NDSUVM1johan@nlgvax.UUCP (Johan Stevenson) (02/25/88)
Two questions were asked about MINIX-ST recently on the net: 1) >Will the C compiler generate executables larger than 64K? If not then its >crippled and pretty useless in the ST world. On the other hand, if it is, >then it seems that the IBM will rapidly fall behind as more and more Unix >software is ported to the ST (but because of size can't be ported to the IBM). Yes, the C compiler uses 32 bit addresses (and 16 bit ints), and can generate large programs. You can run programs as large as physical memory allows. It is a good UNIX tradition to avoid large programs, although lately this tradition seems to fade away. 2) > What is the current status of the Minix port to the ST, ie when >is it going to be compleated? Also, I would like to know exactly who >owns the rights to Minix. Does a company have a copyright on it and >if so, who? Or is it shareware/freeware user supported stuff? MINIX-ST will be copyrighted by Prentice-Hall, like MINIX-PC. Expect it to be available from Prentice-Hall late Spring (around June), if no further obstacles are encountered. I hope this answers most of the questions on MINIX-ST for the moment. Johan W. Stevenson, Philips Research Laboratories, Project Centre Geldrop, Building XR, Room 15, Willem Alexanderlaan 7B, 5664 AN Geldrop, The Netherlands. phone: +31 40 892205 uucp: mcvax!nlgvax!johan
david@bdt.UUCP (David Beckemeyer) (03/01/88)
In article <214@nlgvax.UUCP> johan@nlgvax.UUCP (Johan Stevenson) writes: > Yes, the C compiler uses 32 bit addresses (and 16 bit ints), and can > generate large programs. You can run programs as large as physical > memory allows. This may have been hashed around before, but I never saw the final verdict, so please excuse me if this is "old news". Just exactly how will RAM memory be managed on the ST under MINIX? On the PC I remember MINIX uses 64K offset addressing? With absoulte addressing on the Atari some things must be different no? 1) does this mean a "fixup" table a la TOS and PC-DOS? 2) what about swaping: 2a) a fixed "text" area, and a swap on each context switch? (don't laugh I've seen this proposed on the ST). 2b) no swapping 2c) the "fixups" are remembered so the program can be relocated at run-time? 2d) other 3) what about dynamic memory (e.g. malloc): 3a) Is there one heap, many, or something else? 3b) can it be swapped/relocated/shared/overlayed? 3c) sbrk causes a swap (like V7) 3d) fragmentation problems? 4) protection scheme? 4a) none 4b) software integrity/ownership tests? 4c) other -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"
johan@nlgvax.UUCP (Johan Stevenson) (03/03/88)
In article <157@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: >In article <214@nlgvax.UUCP> johan@nlgvax.UUCP (Johan Stevenson) writes: >> Yes, the C compiler uses 32 bit addresses (and 16 bit ints), and can >> generate large programs. You can run programs as large as physical >> memory allows. >This may have been hashed around before, but I never saw the final verdict, >so please excuse me if this is "old news". > >Just exactly how will RAM memory be managed on the ST under MINIX? On the >PC I remember MINIX uses 64K offset addressing? With absoulte addressing >on the Atari some things must be different no? Indeed, 32 bit addresses and offsets. Inside the kernel and MM clicks of 256 bytes are counted in 16 bit ints, so 24MB address space. Physical and virtual addresses are identical. > 1) does this mean a "fixup" table a la TOS and PC-DOS? The GEMDOS-style relocation info is appended to the loadfile and used during exec() to get the initial process image right. > 2) what about swaping: > 2a) a fixed "text" area, and a swap on each context switch? > (don't laugh I've seen this proposed on the ST). Indeed, an in-core process image swap, but not often. In 99% of all cases this leads to 2 copies of the process image per fork(), instead of 1 for a machine with hardware relocation. Really! In pathological cases (look at the MINIX test programs) it takes many in-core swaps, but works. In practice, I only foresee problems with terminal emulators. Slight modifications to the code will be necessary for good performance. > 2b) no swapping Then no fork(). > 2c) the "fixups" are remembered so the program can be > relocated at run-time? Only works for text and read-only data. > 2d) other > 3) what about dynamic memory (e.g. malloc): > 3a) Is there one heap, many, or something else? Fixed allocated area for stack and heap combined, like for MINIX-PC. However, you can choose this area as big as you like, as long as it fits in memory. > 3b) can it be swapped/relocated/shared/overlayed? I do not fully understand the question. > 3c) sbrk causes a swap (like V7) No. > 3d) fragmentation problems? Like MINIX-PC. > > 4) protection scheme? > 4a) none None, except that low core is protected in user mode. (MM, FS, INIT and all user programs run in user mode). This, and the many faults detected by the 68000 as comapred to the 8088, give a reasonable protection against programming errors, NULL pointers, stack overflow and the like. So far I haven't seen a user process crash the system, although it is rather easy to create such a program on purpose. > 4b) software integrity/ownership tests? No. > 4c) other On process restart (when it is scheduled to run) a test is made for orange or red stack violation. >-- In the documentation that comes with MINIX-ST a more extensive explanation of the implementation details is given, including a description of the technique called 'shadowing' that is used to implement fork() and exec() with full UNIX semantics. Johan W. Stevenson, Philips Research Laboratories, Project Centre Geldrop, Building XR, Room 15, Willem Alexanderlaan 7B, 5664 AN Geldrop, The Netherlands. phone: +31 40 892205 uucp: mcvax!nlgvax!johan
exodus@uop.edu (G.Onufer) (03/05/88)
Will it be realtively easy to use pipes with MINIX? Open pipes, etc?? G. Onufer