9 Nov
2005
9 Nov
'05
11:26 p.m.
I've thought, since there doesn't seem to be a working "V6on286",
maybe I
should try porting it myself though I'm not very familiar with the Ancient
Unix sources or with the ancient C used. The oldest compiler I've got
that will compile is Turbo C++ 1.01 from 1990 and it's an ANSI C compiler.
(I do think it'll compile late K&R, but there's weirdnesses in the C used
by V6.)
Having an emulator like QEMU handy is a nice plus. I could prolly build
everything onto a 1.44 MB disk image and boot it in emulation. I'm
thinking I'd want to create tools for transferring files into and out of
disk images, and a bootloader to put on the first sector of the disk
(though, 512 bytes is awful small...)
Any ideas?
-uso.
10 Nov
10 Nov
3:54 a.m.
: disk images, and a bootloader to put on the first sector of the disk
: (though, 512 bytes is awful small...)
It is a very useful excersize to concentrate on the small. 512 bytes
is plenty to play with... Although many boot loaders are boring and
just load the next boot stage or two and jump to that.
Warner
4:03 a.m.
my suggestions are as follows (i assume you really mean 8086 mode):
use a pdp emulator to run a donor system and do the port from there.
using a floppy to boot is a great idea. i've written several boot
straps to boot from the floppy that configure the serial port, and put
the processor in 32-bit mode. it's tight, but not too hard. you have
a great advantage in that you're going to stick to 16 bit so you can
use the bios. 512 bytes in that case is tons of space.
first job is to get an assembler and compiler for the 8086. i would
use the mit's compilers/assembler from the 1980's. if you can't find
a copy, i have one.
next, figure out how you are going to manage memory. avoiding
protected memory would make things much easier. just have each
process use a full 64K of memory for the data segment. for text you
don't have to worry about stepping on anything, so they don't have to
be a full 64k. that'll give you 10 processes worth of processes. you
can just swap if you want any more.
the routines you'll need to fix are in /usr/sys/ken/main.c.
then you need to rewrite the trap code to use the pc's interrupts.
this is very straight forward. you'll have to write some small
assembler code to setup the stack frames to get into trap.c.
next you'll need to write device drivers for the screen/keyboard, the
clock, and the floppy. later you can write an ATA driver and get a
mbr and hard disk boot strap.
if you want to do a 32-bit version, then things are a little
different. but this should give you the v6 in about as little
work as can be.
Brantley Coile
12 Nov
12 Nov
12:13 p.m.
On 11/9/05, Brantley Coile <brantley(a)coraid.com> wrote:
my suggestions are as follows (i assume you really
mean 8086 mode):
That wouldn't be a good match. I believe you want this:
* 16-bit
* protected mode
* no paging
* 8 or 16 segments
* 128 kB of the memory
* no FPU
using a floppy to boot is a great idea. i've
written several boot
straps to boot from the floppy that configure the serial port, and put
the processor in 32-bit mode. it's tight, but not too hard. you have
a great advantage in that you're going to stick to 16 bit so you can
use the bios. 512 bytes in that case is tons of space.
512 is easy until you try to handle more than one machine. :-(
next you'll need to write device drivers for the
screen/keyboard, the
clock, and the floppy. later you can write an ATA driver and get a
mbr and hard disk boot strap.
I think you need a 4 MB disk and a 10 MB disk. :-)
if you want to do a 32-bit version, then things are a
little
different. but this should give you the v6 in about as little
work as can be.
You might use a 32-bit CPU in 16-bit mode. Then you could use
a 32-bit limit on the FS or GS segment for easier physical memory
access from the kernel. (use an opcode prefix as needed)
7:18 p.m.
I believe you want this:
* 16-bit
* protected mode
* no paging
* 8 or 16 segments
* 128 kB of the memory
* no FPU
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.
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.
there's not really any reason not to use the whole 640K.
using a floppy to boot is a great idea.
i've written several boot
straps to boot from the floppy that configure the serial port, and put
the processor in 32-bit mode. it's tight, but not too hard. you have
a great advantage in that you're going to stick to 16 bit so you can
use the bios. 512 bytes in that case is tons of space.
512 is easy until you try to handle more than one machine. :-( next you'll need to write device drivers for
the screen/keyboard, the
clock, and the floppy. later you can write an ATA driver and get a
mbr and hard disk boot strap.
I think you need a 4 MB disk and a 10 MB disk. :-) if you want to do a 32-bit version, then things
are a little
different. but this should give you the v6 in about as little
work as can be.
You might use a 32-bit CPU in 16-bit mode. Then you could use
a 32-bit limit on the FS or GS segment for easier physical memory
access from the kernel. (use an opcode prefix as needed) 
14 Nov
14 Nov
2:16 a.m.
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.
3:38 p.m.
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(a)coraid.com> wrote:
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.
Wesley Parish
--
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.
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.
9:45 p.m.
this is a nice conversation. you're observations are all correct.
see my additional comments below.
true, but your numbers are a bit off. 640k / 64k = 10 not 6. the kernel
will take only 2, so you should have 8. the shared segment for the shell
is about 32k, so maybe you're not that far of.
if the objective is to have a system that is real and has the feel of what
it was like to use a 6th Edition Unix system, this isn't a big deal. you
and edit, compile and run programs on it.
i wouldn't bother with a swap device on the floopy version. you'd just
just use this version to get the disk driver working so you could
have real swap. swaping to modern disks is pretty fast. i can swap
an entire 64k segment in less than a millisecond, so it would seem
much faster than the original.
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.
absolutely correct. in fact, i've never really figured out
what intel was thinking with the stack segment in protect mode.
you can't use it in C, you can't even use it in a Pascal like language,
or any other language that uses call-by-reference procedure
parameters.
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).
ture enough. but that's the case if you use the 286 segmens as well.
either that or you make the data==stack segment a little short,
then set the stack to a fixed size near the bottom of the data segment.
if you run off the end or grow the stack too deep, you wrap around
and hit the limit of the segment.
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.
the mit x86 stuff would be where i'd start. i haven't looked to see
if you need to tweak the assignment operators to avoid having
to s/=+/+=/, but it might already be done.
it's all 16 bit stuff: port of PCC, assembler and loader.
an enjoyable discussion. wish i had time to work on it.
bc
15 Nov
15 Nov
9:08 a.m.
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.
I don't understand this. If SS is set to DS, in any 16 bit mode,
then doesn't this accomplish the accurate reproduction? I realize
that a 32-bit mode would be required for limit checking.
Regards,
Greg
9:40 a.m.
On 2005-Nov-14 19:08:52 -0800, Greg Haerr <greg(a)censoft.com> wrote:
You can make SS and DS the same but this means that there's nothing
stopping the stack growing down into the heap or vice versa. This
makes the stack accessible from the data space but gives no protection
(note that I was referring to reproducing Unix protection).
--
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.
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.
I don't understand this. If SS is set to DS, in any 16 bit mode,
then doesn't this accomplish the accurate reproduction? I realize
that a 32-bit mode would be required for limit checking.
7:30 p.m.
On 2005-Nov-14 19:08:52 -0800, Greg Haerr
<greg(a)censoft.com> wrote:
You can make SS and DS the same but this means that there's nothing
stopping the stack growing down into the heap or vice versa. This
makes the stack accessible from the data space but gives no protection
(note that I was referring to reproducing Unix protection).
sorry this message is so long. i wish it was better written, but at
least it's early in the day, and i've had my diet co-cola (as we say
here in the south).
this mess is why i made the suggestion just to use a full 64k for the
data segments. but there is a way to get protection of a sort.
Peter's right. setting ss==ds will work but it leaves the data
segment unprotected. in protect mode, data segments can be configured
to be valid above a limit or below. for stacks you can make them
valid above a limit and move the limit down as the stack grows. (by
above i mean address with larger values and by down i mean addresses
with smaller values.) but one can't easily use this when implementing
C.
when the processor does a stack operation, a push, pop, call, return
and so on, it uses the stack segment. when the processor feteches or
stores an operand or a result, it uses the data segment. even if the
data segment and stack segments had the same base register, you
couldn't use the grow-down feature to protect the data from the stack
growing into it. the problem is local varibles and call by reference.
local varibles live on the stack, but if you tried to access them with
using the data segment selector, you would get a protection violation
because you're doing a data fetch above the data limit. since it's a
data fetch it's using the data segment. you might think that the
compiler could know where the variable is and use an instruction
prefix to override the data segment and use the stack segment instead.
that would work for the simple case, but what do you do when you take
the address of the variable? you loose the information that it's a
local variable on the stack and don't know which segment to use
when dereferencing the pointer.
when the protect mode was designed in intel, Pascal was all the rage
in schools of higher learning. C had yet to become the ubiquitous
notation. since Pascal didn't allow addresses to be taken of
arbitrary varibles, for years i just assumed the intel design was an
arifact of designing hardware to run Pascal. (intel indeed includes a
feature that is only useful for Algol like languages that have nested
procedures. look at the definition of the `enter' instruction.) but i
was wrong.
Pascal, (and Modula, and Oberon) allow procedure parameters to be
either call by value or call by reference. a call by reference
parameter is a kind of pointer. there is no way to know if you've
been called with a pointer to a global variable, a variable allocated
on the heap or a local variable, without including more information
than just the address.
so, what were they thinking? i've no idea. all other segmented
architectures include the segment selector in the high bits of the
virtual address, as does the pdp-11, as did Multics. in fact, what
intel calls a page directory is called a segment table in many other
systems. but of course the word segment was already taken.
in the mid 1980's we used intel compilers with different memory models.
the small model did much as i'm suggesting. just give'm 64k and
have at it. there was also a middle model with 64k data and more than
one code segment. large model allowed more than 64k of data, but
a single array was limited to 64k. there was also a huge model.
as you went from small to huge, the code generated by the compiler
would include more and more load segment selector instructions. while
this looks bad, it's really quite worse than it looks. when one loads
a selector, a 16-bit value, into the segment register it causes the
processor to load a 64 bit segment descriptor. and it does this for
every varible access in large and huge models. yuck!
all that is why i suggest just giving the process 64k and be done with
it. it's 6th edition after all. but last night i thought of a couple
of reasons to turn on protect mode. first, there is a way to use it to limit
the stack growth and stop it from growing into the data.
you must decide how large a stack you want to allow. then put the
base of your static data just above the stack and have the stack grow
down to the bottom of your data segment. you use protect mode to
allow 64k-N, so you can't just wrap around the data segment. if the
stack grow down and wraps around to the top of the data segment, it
will touch the area that isn't allowed in the segment. there some
issues with the value of N, but i won't go into that.
like so:
+----------+
| heap |
+----------+
| data/bss |
+----------+
| stack |
+----------+
this has the disadvantage of having to set the stack limit when
you link the load module, but it will keep one from crashing into the
heap.
i don't think this is worth the effort.
the second reason to turn on the segment protection is to make use of
more of the memory in the system. you can have more than the six to
eight processes. again, i don't think it's worth it, even thought is
hard to `waste' that other 512M.
anyway, again i'm sorry for the long message. if anyone has a better
answer as to WHY intel designed the segments the way they did in
protect mode, if you know what language they were thinking of, please
let me know.
bc
1011 1100
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.
I don't understand this. If SS is set to DS, in any 16 bit mode,
then doesn't this accomplish the accurate reproduction? I realize
that a 32-bit mode would be required for limit checking.
6976
days inactive
6982
days old
10 comments
7 participants
participants (7)
-
Albert Cahalan -
Brantley Coile -
Greg Haerr -
Lyrical Nanoha -
M. Warner Losh -
Peter Jeremy -
Wesley Parish