[TUHS] Redoing "V6on286" or porting V7...?
wes.parish at paradise.net.nz
Mon Nov 14 19:38:31 AEST 2005
On Mon, 14 Nov 2005 09:16, Peter Jeremy wrote:
> 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.
Would it be possible to use some of the DOS ones? At least to bootstrap a
more true-to-Unix one?
I'm thinking of the likes of bcc, available plus source at the FreeDOS web
archive. Or OpenWatcom's DOS 16-bit.
Clinersterton beademung, with all of love - RIP James Blish
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
More information about the TUHS