14 Nov
2005
14 Nov
'05
7:49 p.m.
On 2005-Nov-14 10:45:13 -0500, Brantley Coile <brantley(a)coraid.com> wrote:
I realise that.
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.
true, but your numbers are a bit off. 640k / 64k = 10 not 6. the kernel will take only 2, so you should have 8.
I was assuming split I+D, with the data segment fixed at 64K. This
means that you have (64K + code) per process. If you have code plus
data in 64K then you can fit more, but I think that was getting to
be a squeeze even on V6. (And would definitely write off something
like 2BSD).
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.
Given an open-source compiler, it would be fairly easy to retrofit the
=+ operators into the lexer. (Probably easier than cleaning up the
code). The alternative is to start with something later (eg 2BSD) but
code quality then becomes far more of an issue (because 2BSD tends to
push the I-space limits in lots of areas).
it's all 16 bit stuff: port of PCC, assembler and
loader.
The x86 instruction set and registers are nothing like as regular and
orthogonal as the PDP-11. In particular, there are _no_ general
purpose registers - every register has has a particular purpose and
either you need to do data-flow analysis to work out what register to
load something into, or you (basically) give up and load from memory
as needed. You could port PCC but this would be much more difficult
than (say) a M68K port. You'd probably need a fairly decent peep-hole
optimiser to get good results.
Wesley Parish mentioned bcc and OpenWatcom. I looked into the former
and it's probably the best starting point (though, with due respect to
BDE, the code it generates could be better). Assuming that Unix fits
into the C subset implemented by bcc, you'd be better off spending the
effort on improving bcc than porting PCC. At the time I looked,
OpenWatcom was either still vapourware or not self-hosting.
an enjoyable discussion. wish i had time to work on
it.
Agreed.
--
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.
14 Nov
14 Nov
8:31 p.m.
New subject: Redoing "V6on286" or porting V7...?
On 2005-Nov-14 10:45:13 -0500, Brantley Coile
<brantley(a)coraid.com> wrote:
I was assuming split I+D, with the data segment fixed at 64K. This
means that you have (64K + code) per process. If you have code plus
data in 64K then you can fit more, but I think that was getting to
be a squeeze even on V6. (And would definitely write off something
like 2BSD).
i don't know that it's a squese. a version of v6 ran on an lsi-11
with very little ram. there is only two process required to run in
v6, init and the shell. sched doesn't count; it has no user 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.
Given an open-source compiler, it would be fairly easy to retrofit the
=+ operators into the lexer. (Probably easier than cleaning up the
code). The alternative is to start with something later (eg 2BSD) but
code quality then becomes far more of an issue (because 2BSD tends to
push the I-space limits in lots of areas). it's all 16 bit stuff: port of PCC, assembler
and loader.
The x86 instruction set and registers are nothing like as regular and
orthogonal as the PDP-11. In particular, there are _no_ general
purpose registers - every register has has a particular purpose and
either you need to do data-flow analysis to work out what register to
load something into, or you (basically) give up and load from memory
as needed. You could port PCC but this would be much more difficult
than (say) a M68K port. You'd probably need a fairly decent peep-hole
optimiser to get good results.
Wesley Parish mentioned bcc and OpenWatcom. I looked into the former
and it's probably the best starting point (though, with due respect to
BDE, the code it generates could be better). Assuming that Unix fits
into the C subset implemented by bcc, you'd be better off spending the
effort on improving bcc than porting PCC. At the time I looked,
OpenWatcom was either still vapourware or not self-hosting.
again, no port required. the mit x86 stuff has already done that.
i have code with the following readme.
---
Directory setup:
c86, lib86: for 8087-equiped systems.
nc86,nlib86: for non-8087 systems.
You should install the following files into some directory on your
search path (on our system we use /usr/local):
cc86 ; shell script implements "cc" but for 8086
a86/a86 ; the assembler
a86/ld86 ; the loader
a86/cvt86 ; .ld output to .com file (a la IBM DOS) conversion
c86/c86 ; the C compiler
Regular 4.1BSD programs used:
ar ; used for preparing loader libraries
/lib/cpp ; C preprocessor
The cc86 script expects to find the libc.a and crt files in
/projects/compilers/8086/lib86 -- if you don't put them there, you'll
have to update cc86...
The compiler produces assembly language output suitable for a86.
It is a 16-bit compiler; output code does not touch the segment
regs, so it is possible to have separate instruction and data
segments (see lib86/csu/crt0.a86 for the start up routine we use
on our IBM Personal computer to set up the segment regs, etc. from
info in the .com file). Currently floating point and long arithmetic
is implemented using 8087 instructions.
Although the assembler produces ".b" files, they have exactly the
same format as ".o" files under 4.1BSD -- things like nm and size will
work, and, most importantly, ld. Using ld with the -N, -X and -r
options (see cc86 for an example) will produce a file that cvt86 can
convert into an IBM DOS format .com file for the IBM Personal Computer.
---
looking at the source files, it's definitly PCC.
(and it already does the =+ stuff.)
you keep tempting me! (get behind me, Satan!)
an enjoyable discussion. wish i had time to work
on it.
Agreed.
--
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. 
16 Nov
16 Nov
9:41 p.m.
New subject: Redoing "V6on286" or porting V7...?
I'm the original poster of this thread.
On Tue, 15 Nov 2005, Peter Jeremy wrote:
Wesley Parish mentioned bcc and OpenWatcom. I looked
into the former
and it's probably the best starting point (though, with due respect to
BDE, the code it generates could be better). Assuming that Unix fits
into the C subset implemented by bcc, you'd be better off spending the
effort on improving bcc than porting PCC. At the time I looked,
OpenWatcom was either still vapourware or not self-hosting.
I don't think everything needs to be bootstrapped with an open-source
compiler. I have Turbo C++ 1.01 which is a more than adequate C compiler
for anything I've done with it (ranging from clones of Unix tools to a
COMMAND.COM to an Apple //e emulator). Whatever does the job is fine for
me.
So getting the kernel up and getting files in and out of the image until a
native C compiler is ready (pcc?) can be done with anything, practically.
QEMU is a good enough testbed, and gives you well-defined hardware. Once
everything is up and running, then maybe one can migrate on to newer
systems (V7, 2BSD), though V6 should be simple enough as a starting point,
provided most of it is in C (I haven't really looked).
-uso.
7128
days inactive
7130
days old
2 comments
3 participants
participants (3)
-
Brantley Coile -
Lyrical Nanoha -
Peter Jeremy