[TUHS] Redoing "V6on286" or porting V7...?

[peter.jeremy@alcatel.com.au (Peter Jeremy)]

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 at 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.