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 <brantley(a)coraid.com> 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.