From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter.jeremy@alcatel.com.au (Peter Jeremy) Date: Mon, 14 Nov 2005 07:16:09 +1100 Subject: [TUHS] Redoing "V6on286" or porting V7...? In-Reply-To: References: <787b0d920511112213q7156614cv2fe3c5d00852f45c@mail.gmail.com> Message-ID: <20051113201609.GW6574@gsmx07.alcatel.com.au> I've also looked at this in the past. I lost interest when my intended target box died (and I realised I didn't have the free time). On 2005-Nov-12 08:18:50 -0500, Brantley Coile wrote: >i may be wrong, but i don't think you want the segments. pdp-11 >segments divided the address space into eight, well, segments. each >could be grow up or grow down and had a physical base and a limit. >intel segments don't work that way. the major difference is that the >segment selector, instead of being the upper most three bits of the >virtual address, is not even in the address space at all. Actually the 286 MMU is very primitive compared to the PDP-11. One crucial difference is that Unix has the implicit assumption that the stack is in the data space - which is not true on the 286. This difference is fairly critical to Unix and makes it impossible to accurately reproduce the traditional Unix memory protection. >so the eight, for a pdp-11/40 say, or the sixteen for the 11/70 don't >really apply. instead just give each data segment the whole 64k >address space and it'll not klobber anybody else. just itself. This is fairly wasteful of RAM. Keep in mind that V6 cannot page - a process is either entirely in memory or entirely on disk. If you limit yourself to 640K RAM, you are probably restricting yourself to about 6 resident processes. And swapping means moving 64K of data to/from disk. This approach also makes brk(2) a no-op. There's nothing to prevent a process using as much heap as it wants (or crashing into the stack). (No SIGSEGV or SIGBUS errors). >you're correct to imply that v6 takes up MUCH less space than other >systems. it's amazing how small you can run this. the root in the >6th edition system is only 1.4MB. and that includes the normal >binaries, libraries and the source to the kernel. it'll run great on >a floopy. You will need to have a swap partition. And if each process has a 64K data segment, you'll need a comparatively large amount of swap. The biggest disadvantage of a floppy will be performance - latency of about 80msec, I/O of about 40KB/sec. Have you identified a suitable C compiler? There aren't many open source 16-bit x86 compilers, especially ones that can run in 16-bit mode. None of the ones I found generated particularly good code. This may impact you ability to get the larger utilities (and maybe the kernel) to fit into 64K I-space. -- Peter Jeremy This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer. This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission.