[TUHS] Re: Porting Unix v6 to i386

[TUHS] Re: Porting Unix v6 to i386

[Warren Toomey]

In article by Sven Dehmlow:
> Hi Warren,
> I can't find the port [of V6 to the 286] in the archives.
> Am I'm too stupid to search or haven't you added it yet?
> Sven

My apologies, I had forgotten to import it. It's now available
at http://www.tuhs.org/Archive/Other/V6on286

with the mirror sites to follow soon.

Cheers,
	Warren

[TUHS] Re: Porting Unix v6 to i386

[Sven Dehmlow]

On Mon, Jul 08, 2002 at 11:09:03AM +1000, Warren Toomey wrote:

> > [...]

> In article by Sven Dehmlow:
> My apologies, I had forgotten to import it. It's now available
> at http://www.tuhs.org/Archive/Other/V6on286
> 
> with the mirror sites to follow soon.

Great!
Now it's time to figure out how to compile this stuff.

Thank you!

Sven

[TUHS] Re: Porting Unix v6 to i386

[SZIGETI Szabolcs]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3160 bytes --]

> > My apologies, I had forgotten to import it. It's now available
> > at http://www.tuhs.org/Archive/Other/V6on286
> >
> > with the mirror sites to follow soon.
>
> Great!
> Now it's time to figure out how to compile this stuff.

Hi,


Some hints:

First of all, the code is currently broken. Something is wrong, and it will
not be able to mount the root fs or something, but shouldn't be hard to fix,
because it used to work, and i did something wrong when playing with the
code some years ago, with no backup to revert to.

Originally, I used the commnad line tools of Borland C++ 3.0 to compile. You
need Turbo Assembler, so the Borland C++ 1.0, which is freely available from
Borland as "antique software" is not enough, you'll need the professional
version at least, because it has the command line assembler.

There is a top level makefile, which will create UN.EXE, this is the unix
kernel. You run it under plain MSDOS, it will switch to protected mode, and
with shift-esc it will return to DOS (do a sync before !). Probably it
wouldn't be hard to make it work without DOS as a boot loader :-), but i
never did it.

If compiled with -DSTANDSH, the kernel will be built with a built-in shell
(see KEN/UPROC.C for the command), that can be used to do some basic setup.
It will for example create the /dev/tty entries on a blank root disk. (You
still need the mkfs utility under dos to make a blank disk). I suggest to
use a floppy as a root disk for initial trials.
If you omit STANDSH, it will look for /etc/init to run.


On the directory layout:
CONF contains c.c, the device switch table
DMR contains most of the device drivers
H contains the kernel header files
INCLUDE - the user header files
KEN - rest of the kernel

The low level kernel code is very ugly, as it evolved from experimenting
with protected mode. There are lots of things, that i'm not proud of :-)

SRC/CLIB0 - the C library
SRC/SYSC - the syscall user side interface
SRC/UTIL - the utilities and such, most should work
UTIL - MSDOS utils to compile

In the UTIL directory, there are the following utlities:

c2a - used to compile the kernel, it search-and-replaces some stuff in the
assemlby code, i donát exactly remember why, but it has to do something with
the segmenent names.

exe2v6 - utility to convert MSDOS exe program to a.out. See
SRC/UTIL/Makefile for how to make such an exe. The programs have a built in,
fixed size stack, because Borland C had problems separating code and stack
segment. It could brobably be fixed, but i didn't do it, instead opted for
fixed size stack, adjustable at compile time.

exetr - it can transfer a file to unix via a floppy drive, i donát remember
how it works, i think you put one file to a floppy, and use the kernel-shell
to write it to a file-system. It is a really ugly idea :-)

dumpfs - it is broken, it was intended to back-up a filesystem

mkfs - MSDOS mode mkfs, answer the questions, you'll get the filesystem.
There is no sanity check whatsoever, so be careful, it can screw your
harddrive, if given wrong sector numbers.


Have fun with it, and if you have questions, feel free to write me.

Regards,

    Szabolcs

[TUHS] Re: Porting Unix v6 to i386

[Warren Toomey]

In article by SZIGETI Szabolcs:
> Some hints:

I've added your hints to the README at Other/V6on286 in the Unix Archive.

	Warren

[TUHS] RE: Porting Unix v6 to i386

[russ]

It seems as though there was considerable interest in Porting Unix v6 to i386 some months ago. This is a project that appeals to me also. I was wondering if anyone has made any headway in the project and would like to share their experience.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20020822/12dced38/attachment.html>

[TUHS] RE: Porting Unix v6 to i386

[Peter Jeremy]

On 2002-Aug-22 14:52:23 -0600, russ <russell283 at attbi.com> wrote:
>It seems as though there was considerable interest in Porting  Unix v6 to
>i386 some months ago. This is a project that appeals to me also. I  was
>wondering if anyone has made any headway in the project and would like to
>share their experience.

I've been mulling over something like this for some time.  I haven't
actually gotten very far because:
1) I hadn't found an open-source, 16-bit x86 C compiler that could run
   in 64K+64K.  It looks like there may be some suitable candidates now.
2) My planned target system succumbed to old age.  (The HDD failed and
   the bios only provides a choice of specific 80 or 120MB sizes).

Peter

[TUHS] RE: Porting Unix v6 to i386

[Warren Toomey]

In article by Peter Jeremy:
> On 2002-Aug-22 14:52:23 -0600, russ <russell283 at attbi.com> wrote:
> >It seems as though there was considerable interest in Porting  Unix v6 to
> >i386 some months ago.

Firstly, see http://www.tuhs.org/Archive/Other/V6on286/
for someone who has already done this.

Then see http://www.tuhs.org/Archive/Applications/Portable_CC/
for ports of pcc to 8086 and 80286. Note that these are now
covered by Caldera's BSD-style Ancient UNIX license.

> I've been mulling over something like this for some time.  I haven't
> actually gotten very far because:
> 1) I hadn't found an open-source, 16-bit x86 C compiler that could run
>    in 64K+64K.  It looks like there may be some suitable candidates now.

pcc? What about Bruce Evan's bcc? If the planned architecture is a 286,
what about C68?

> 2) My planned target system succumbed to old age.  (The HDD failed and
>    the bios only provides a choice of specific 80 or 120MB sizes).
> Peter

8-)
	Warren

[TUHS] Re: Porting Unix v6 to i386

[Mike Haertel]

>I'll upload it soon. Meanwhile, instead of a DOS C compiler, people
>should be able Bruce Evans' bcc or C86 as the compiler, which would
>eventually allow the system to compile itself.

The source code to the Watcom compilers has also finally
been released.

[TUHS] Re: Porting Unix v6 to i386

[Peter Jeremy]

On 2002-Jun-06 10:02:57 -0700, Mike Haertel <mike at ducky.net> wrote:
>The source code to the Watcom compilers has also finally
>been released.

Where?  http://www.openwatcom.com/ is still only talking about the
binary patch kit.  The "current status" indicates (mid-May) "Sybase
has decided on an Open Source License and is currently awaiting OSI
approval".

Peter

[TUHS] Re: Porting Unix v6 to i386

[Mike Haertel]

>On 2002-Jun-06 10:02:57 -0700, Mike Haertel <mike at ducky.net> wrote:
>>The source code to the Watcom compilers has also finally
>>been released.
>
>Where?  http://www.openwatcom.com/ is still only talking about the
>binary patch kit.

Argh.  I already replied to this privately before noticing it had
been sent to the list.  I sent Peter a longer reply, but the quick
version is that http://www.openwatcom.org/download_lic.html will
get you to the source code.

Although their compiler will generate 8086 code, it seems reasonably
unlikely that the compiler itself can be made to fit on an 8086.

[TUHS] Re: Porting Unix v6 to i386

[Ian King]

I think this would be a great addition to the archive!  I'm glad I
didn't throw out that old 286 motherboard yet.  :-)  -- Ian 

-----Original Message-----
From: Warren Toomey [mailto:wkt@minnie.tuhs.org] 
Sent: Tuesday, June 04, 2002 4:35 PM
To: Szigeti Szabolcs
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Re: Porting Unix v6 to i386


In article by Szigeti Szabolcs:
> I don't know if i can now legally give out parts of the original code,

> if anyone wants to experiment with it (some parts are pretty ugly, 
> because i intedned to rewrite it, but never did, and the parts of the 
> comments are in Hungarian), drop me an email (though i'm now doing my 
> MBA thesis, so might not answer immediatey). If there is interest, I 
> can summarize my experiences.

Hi, yes it's now legal to distribute your code, as Caldera's license
allows for distribution of changes, see
http://www.tuhs.org/Archive/Caldera-license.pdf

I'm the guy who runs the Unix Archive, so I'd be very happy to take a
copy of your work and add it to the archive.

Cheers,
	Warren
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] Re: Porting Unix v6 to i386

[Szigeti Szabolcs]

> I think this would be a great addition to the archive!  I'm glad I
> didn't throw out that old 286 motherboard yet.  :-)  -- Ian

Hi,

I've sent the stuff to Warren, so it should get to the archives. Mind you,
it needs some hacking to get it running, but it isn't impossible.


Cheers,

    Szabolcs

[TUHS] Re: Porting Unix v6 to i386

[Warren Toomey]

In article by Szigeti Szabolcs:
> I've sent the stuff to Warren, so it should get to the archives. Mind you,
> it needs some hacking to get it running, but it isn't impossible.
> Cheers,
>     Szabolcs

I'll upload it soon. Meanwhile, instead of a DOS C compiler, people
should be able Bruce Evans' bcc or C86 as the compiler, which would
eventually allow the system to compile itself.

	[ Um, maybe once V7 gets ported, as I'd bet these compilers
	  will require the stdio library. ]

Just a thought.

	Warren

[TUHS] Re: Porting Unix v6 to i386

[John Chung]

 Where can I obtain the program nowadays? It is going
to be fun playing it using my x86 machine. :)

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[TUHS] Re: Porting Unix v6 to i386

[Szigeti Szabolcs]

Hi folks!

I've just joined your mailing list, and while looking at the archives, i saw
this discussion on porting V6 to Intel.
Well, back in '92, in a university scinence students' competition, I ported
v6 to intel286 in protected mode. (I got second place, the winner was a 3D
animation prog, which is more spectacular, than a # prompt :-)

I used Borland C to compile, with some extra mungling the assembly code ( i
can't remember why).

The hard part was to understand the protected mode, and to write the low
level stuff. Other things, like filesystem, etc. compiled with hardly any
modification. (Had to change =+ to =+, introduce long insted of int[2],
etc.). It has floppy, ide, kbd, parallel, serial and vga drivers.

It got to full multiuser operation, but there are bugs and stupid codings
certainly. The C compiler, nroff, and some other parts were not ported.
(Yes, I used Borland C to compile the programs, and a tool to convert it to
a.out :-)

I don't know if i can now legally give out parts of the original code, if
anyone wants to experiment with it (some parts are pretty ugly, because i
intedned to rewrite it, but never did, and the parts of the comments are in
Hungarian), drop me an email (though i'm now doing my MBA thesis, so might
not answer immediatey). If there is interest, I can summarize my
experiences.

I've not looked it since several years, so i might not remember every
detail, but there are some interesting point, and it was great fun to do.

Regards,

    Szabolcs Szigeti

[TUHS] Re: Porting Unix v6 to i386

[Warren Toomey]

In article by Szigeti Szabolcs:
> I don't know if i can now legally give out parts of the original code, if
> anyone wants to experiment with it (some parts are pretty ugly, because i
> intedned to rewrite it, but never did, and the parts of the comments are in
> Hungarian), drop me an email (though i'm now doing my MBA thesis, so might
> not answer immediatey). If there is interest, I can summarize my
> experiences.

Hi, yes it's now legal to distribute your code, as Caldera's license
allows for distribution of changes, see
http://www.tuhs.org/Archive/Caldera-license.pdf

I'm the guy who runs the Unix Archive, so I'd be very happy to take a copy
of your work and add it to the archive.

Cheers,
	Warren

[TUHS] Re: Porting Unix v6 to i386

[John Holden]

Aaron J. Grier wrote :-

> support for PDP-11 was added to gcc a few months ago. 

It's been around since 1991 as a patch, but it didn't keep up with the newer
versions of gcc

[TUHS] Re: Porting Unix v6 to i386

[Aaron J. Grier]

On Mon, Jan 28, 2002 at 10:03:45PM +0100, Jonathan Naylor wrote:

> With so much open source code out there, it'd be a relatively simple
> task to find C code for IDE disc access and such like. I would even
> suggest getting older Linux code from the 2.0.x days as its likely to
> be a little less complex, while still being stable.

Linux!?  why not one of the three BSD-licensed BSD-derived Net/Free/Open
BSDs?  keep it "in the family" so to speak.  :)

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com
      "[...] I generally haven't found IDM guys to be very good
       live acts, most of them just sit down at their laptop and
       tweak reaktor."  -- Brandon Daniel

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Tue, Jan 29, 2002 at 05:57:58PM -0800, Aaron J. Grier wrote:
> > With so much open source code out there, it'd be a relatively simple
> > task to find C code for IDE disc access and such like. I would even
> > suggest getting older Linux code from the 2.0.x days as its likely to
> > be a little less complex, while still being stable.
> 
> Linux!?  why not one of the three BSD-licensed BSD-derived Net/Free/Open
> BSDs?  keep it "in the family" so to speak.  :)

Well that is what I intended,  certainly as a starting reference for
floppy, console drivers etc - IDE can wait till later.  Initially I 
would like to get v6 or 7 (probably 6 as the Lions commentary is
available) booting a kernel.   

Anyhow I have started gathering the tools (Watcom C compiler now
open source and free!  www.openwatcom.org),  nasm etc etc so I should
now have enough bits and bobs to compile 16 bit code - as gcc doesnt.

Of course if someone wants to rewrite the version of cc that comes
with V6 so it generates x86 binaries rather than pdp binaries, that
would be the utimate aim I guess.  That way you could run V6 on a
PC and get it to compile its own kernel....

Having had a rummage and a chat with acolleague here at
UKC - it seems that V6 will be easier than V7,  partially because
of the Lions commentary - but mainly because 286 protected mode 
gives a very similar handling on memory management as the PDP did.

Paul

[TUHS] Re: Porting Unix v6 to i386

[Sven Dehmlow]

On Wednesday 30 January 2002 10:18, P.A.Osborne wrote:
> On Tue, Jan 29, 2002 at 05:57:58PM -0800, Aaron J. Grier wrote:

> Well that is what I intended,  certainly as a starting reference
> for floppy, console drivers etc - IDE can wait till later. 
> Initially I would like to get v6 or 7 (probably 6 as the Lions
> commentary is available) booting a kernel.
>
> Anyhow I have started gathering the tools (Watcom C compiler now
> open source and free!  www.openwatcom.org),  nasm etc etc so I
> should now have enough bits and bobs to compile 16 bit code - as
> gcc doesnt.
>
> Of course if someone wants to rewrite the version of cc that comes
> with V6 so it generates x86 binaries rather than pdp binaries, that
> would be the utimate aim I guess.  That way you could run V6 on a
> PC and get it to compile its own kernel....

Getting the ported kernel compiled while running itself will not be a 
serious problem independent from the compiler as long as it's source 
code is available and it is written for the machine to compile on. 
Porting a compiler from one operating system to another is a fool 
compared with porting an operating system from one machine to 
another. Give me the port of Unix and I'll give you the ported x86 C 
compiler... ;-)

>
> Having had a rummage and a chat with acolleague here at
> UKC - it seems that V6 will be easier than V7,  partially because
> of the Lions commentary - but mainly because 286 protected mode
> gives a very similar handling on memory management as the PDP did.

Yes, and I think that v7 was a further development from v6. 
Developing something further is always more fun and by this more easy 
than developing something back.

Sven

[TUHS] Re: Porting Unix v6 to i386

[Johnny Billquist]

On Wednesday 30 January 2002 10:18, P.A.Osborne wrote:
> Having had a rummage and a chat with acolleague here at
> UKC - it seems that V6 will be easier than V7,  partially because
> of the Lions commentary - but mainly because 286 protected mode
> gives a very similar handling on memory management as the PDP did.

What a silly argument. V6 and V7 both run on the PDP-11, so the memory
management hardware used by them both are the same.

And while I'm not familiar with the 286 protected mode, I have heard
people before claim that it is horrendous compared to the MMU on the
PDP-11.

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt at update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Re: Porting Unix v6 to i386

[Michael Davidson]

Johnny Billquist wrote:
> 
> On Wednesday 30 January 2002 10:18, P.A.Osborne wrote:
> > Having had a rummage and a chat with acolleague here at
> > UKC - it seems that V6 will be easier than V7,  partially because
> > of the Lions commentary - but mainly because 286 protected mode
> > gives a very similar handling on memory management as the PDP did.
> 
> What a silly argument. V6 and V7 both run on the PDP-11, so the memory
> management hardware used by them both are the same.
> 
> And while I'm not familiar with the 286 protected mode, I have heard
> people before claim that it is horrendous compared to the MMU on the
> PDP-11.
> 

Well, I tend to agree that there probably isn't really much difference
in the difficulty of porting either V6 or V7 to an Intel x86 processor.

The real deciding factor will (and should) be which version you *want*
to port and why you want to port it in the first place.

While the Intel architecture is very different from that of the PDP-11
it is possible to set up an IA-32 processor in such a way as to give
you an environment which is quite similar to the one in which V7
expected to run.

16 bit protected mode can effectively give you a 64k+64k split i&d
address space for both user and kernel mode and if you enable paging
then you can map the underlying physical memory in 4096 byte pages
wherever you want it to be. Once it's all set up correctly, most of
the Intel MMU architecture can be ignored and pretty much all the 
kernel has to do is to manipulate 64 entries in a page table (16+16
for user i+d and 16+16 for kernel i+d).

Rather than hack all of the code to build with a modern C compiler
I would look seriously at the possibility of getting either pcc or
the original Ritchie C compiler to generate x86 code. 

(This has, of course, been done before as anyone who ever used
Xenix version 2.x on Intel machines will know - right down to
32 bit longs with PDP-11 word ordering ...)

One possibility which actually isn't as bad as it sounds is to
treat the pdp-11 assembler output of the C compiler as an intermediate 
language and have an additional compiler pass that effectively
converted from pdp11 assembler to x86 assembler.

A good convertor would do enough basic block analysis to be
able to keep track of live registers and condition codes and
would essentially recompile from pdp11 to x86 assembler.
My guess is that with a little care it should be possible to
keep the code expansion resulting from such a translation
process to a minimum.

Even a fairly simple minded conversion probably wouldn't be
too bad.

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Wed, Jan 30, 2002 at 08:50:31PM +0100, Johnny Billquist wrote:
> On Wednesday 30 January 2002 10:18, P.A.Osborne wrote:
> > Having had a rummage and a chat with acolleague here at
> > UKC - it seems that V6 will be easier than V7,  partially because
> > of the Lions commentary - but mainly because 286 protected mode
> > gives a very similar handling on memory management as the PDP did.
> 
> What a silly argument. 
> V6 and V7 both run on the PDP-11, so the memory
> management hardware used by them both are the same.

Having looked through the source of v6 and v7  the comments are shall
we say minimalistic to people who are not as familiar with the PDP 
architecture as say Ritchie and Thompson - ie ME!   Hence the Lions
commentary makes life a darn site easier.

I am not disagreeing with the second point you have made.   However the
point is that V7 is a development on from V6 and the memory management 
is more complex and thus requires more work.

> And while I'm not familiar with the 286 protected mode, I have heard
> people before claim that it is horrendous compared to the MMU on the
> PDP-11.

I have heard similar,  however the point remains that attempting to
port the simpler model is going to be less work that porting the more
complex model.

At the end of the day porting V6 has been something that I have considered
for almost a couple of years now,  but time has been lacking.  Now that
I have time I am going to be able to do some work.   If someone hadn't 
raised the question of porting on this mailing list then I would 
probably not mentioned what I am considering at all.

Why do I want to do this? :
1.  To improve my understanding of how OSs work
2.  To improve my very shaky intel assembler skills
3.  Because I can

If out of it I (or anyone else for that matter) produces 10 lines of
code that prove benefit to the community (on this list) then its been
worth any effort even if we dont see v6(or 7) running on a PC.

Regards

Paul

[TUHS] Re: Porting Unix v6 to i386

[Johnny Billquist]

On Thu, 31 Jan 2002, P.A.Osborne wrote:

> On Wed, Jan 30, 2002 at 08:50:31PM +0100, Johnny Billquist wrote:
> > On Wednesday 30 January 2002 10:18, P.A.Osborne wrote:
> > > Having had a rummage and a chat with acolleague here at
> > > UKC - it seems that V6 will be easier than V7,  partially because
> > > of the Lions commentary - but mainly because 286 protected mode
> > > gives a very similar handling on memory management as the PDP did.
> > 
> > What a silly argument. 
> > V6 and V7 both run on the PDP-11, so the memory
> > management hardware used by them both are the same.
> 
> Having looked through the source of v6 and v7  the comments are shall
> we say minimalistic to people who are not as familiar with the PDP 
> architecture as say Ritchie and Thompson - ie ME!   Hence the Lions
> commentary makes life a darn site easier.
> 
> I am not disagreeing with the second point you have made.   However the
> point is that V7 is a development on from V6 and the memory management 
> is more complex and thus requires more work.

I thought I only made one point, and that was that the argument for V6
being easier to port because "286 protected mode gives a very similar
handling on memory management as the PDP did".

Since V6 and V7 both run on the PDP-11 it can absolutely not be an
argument for preferring V6 to V7.

Thus I think it is a silly argument.

The rest is purely speculative on my behalf, and I really don't want to
debate wether V6 or V7 would be better to port.
I have a proper PDP-11 at home, and in addition, I run RSX, not Unix on
it. :-)

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt at update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Thu, Jan 31, 2002 at 07:51:41PM +0100, Johnny Billquist wrote:
> I thought I only made one point, and that was that the argument for V6
> being easier to port because "286 protected mode gives a very similar
> handling on memory management as the PDP did".

Rereading the mail - you did.  

Sorry for getting the wrong end of the stick.

> Since V6 and V7 both run on the PDP-11 it can absolutely not be an
> argument for preferring V6 to V7.
> 
> Thus I think it is a silly argument.

OK fair point - I respect your view.

> The rest is purely speculative on my behalf, and I really don't want to
> debate wether V6 or V7 would be better to port.
> I have a proper PDP-11 at home, and in addition, I run RSX, not Unix on
> it. :-)

If I acquired a PDP-11 and wanted to take it home I suspect that the
missus would not be too pleased.  Hence the PDP emulator and a bizarre
need to port to x86...

Paul

[TUHS] Re: Porting Unix v6 to i386

[Mike Haertel]

>Having looked through the source of v6 and v7  the comments are shall
>we say minimalistic to people who are not as familiar with the PDP 
>architecture as say Ritchie and Thompson - ie ME!   Hence the Lions
>commentary makes life a darn site easier.
>
>I am not disagreeing with the second point you have made.   However the
>point is that V7 is a development on from V6 and the memory management 
>is more complex and thus requires more work.

V6 is much more difficult to port.  Reason: it had never been ported.

By contrast V7 source code contains numerous cleanups that were
made for the Interdata 8/32 port.  (One of those cleanups included
the deletion of the famous "You are not expected to understand this"
comment in the kernel--because that C code for context switching 
could not be made to work on other architectures.  Whereas you can
port V7 context switch just by rewriting the supporting asm routines.)

Another problem with V6 is that a significant number of the user level
utility programs were still written in asm.  E.g. cat, strip, sum,
and even nroff.

You can still use the Lions book pretty well as a reference for
understanding the V7 kernel.  The code may not be identical but the
concepts are mostly the same.

[TUHS] Re: Porting Unix v6 to i386

[Mike Haertel]

>Anyhow I have started gathering the tools (Watcom C compiler now
>open source and free!  www.openwatcom.org)

They have announced that it *will be* open source and free,
but so far as far as I can tell there is nothing available
at openwatcom.org except a binary-only patch to upgrade 
the last commercial version 11 to 11.0c.

So, it isn't yet.  Right now it's just vaporware.

[TUHS] Re: Porting Unix v6 to i386

[M. Warner Losh]

In message: <200201301952.g0UJq0E39966 at ducky.net>
            Mike Haertel <mike at ducky.net> writes:
: >Anyhow I have started gathering the tools (Watcom C compiler now
: >open source and free!  www.openwatcom.org)
: 
: They have announced that it *will be* open source and free,
: but so far as far as I can tell there is nothing available
: at openwatcom.org except a binary-only patch to upgrade 
: the last commercial version 11 to 11.0c.
: 
: So, it isn't yet.  Right now it's just vaporware.

The only compiler I know of that deals properly with generating 16-bit
x86 code is bcc, which the Elks folks use to build their kernel.  This
is Bruce Evan's compiler with support for prototypes bolted on, iirc.

	http://www.cix.co.uk/~mayday/

It is a tad Linux centric, but I was able to get it to build with only
a few tweaks on FreeBSD.  It is sufficient to build the elks tree, but
I've not tried it on anything else.

Warner

[TUHS] Re: Porting Unix v6 to i386

[Greg Lehey]

On Wednesday, 30 January 2002 at 13:54:03 -0700, Warner Losh wrote:
> In message: <200201301952.g0UJq0E39966 at ducky.net>
>             Mike Haertel <mike at ducky.net> writes:
>>> Anyhow I have started gathering the tools (Watcom C compiler now
>>> open source and free!  www.openwatcom.org)
>>
>> They have announced that it *will be* open source and free,
>> but so far as far as I can tell there is nothing available
>> at openwatcom.org except a binary-only patch to upgrade
>> the last commercial version 11 to 11.0c.
>>
>> So, it isn't yet.  Right now it's just vaporware.
>
> The only compiler I know of that deals properly with generating 16-bit
> x86 code is bcc, which the Elks folks use to build their kernel.  This
> is Bruce Evan's compiler with support for prototypes bolted on, iirc.
>
> 	http://www.cix.co.uk/~mayday/
>
> It is a tad Linux centric, but I was able to get it to build with only
> a few tweaks on FreeBSD.  It is sufficient to build the elks tree, but
> I've not tried it on anything else.

Both the Sixth and Seventh editions contain code which doesn't compile
with modern compilers (the dreaded =-, for example).  What do you want
to do with that?  Of course you can fix it, but then you can go
further and further and end up with 4.4BSD.  I think that if you're
going to do this, you'll want to do it with as few code changes as
possible.  This would really suggest modifying the compiler to
generate i86 code.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers

[TUHS] Re: Porting Unix v6 to i386

[Cyrille Lefevre]

Mike Haertel wrote:
> >Anyhow I have started gathering the tools (Watcom C compiler now
> >open source and free!  www.openwatcom.org)
> 
> They have announced that it *will be* open source and free,
> but so far as far as I can tell there is nothing available
> at openwatcom.org except a binary-only patch to upgrade 
> the last commercial version 11 to 11.0c.
> 
> So, it isn't yet.  Right now it's just vaporware.

as of march 2002, try the download page to get the "binary" compiler.

	http://www.openwatcom.com/download.html

Cyrille.
-- 
Cyrille Lefevre                 mailto:cyrille.lefevre at laposte.net

[TUHS] Re: Porting Unix v6 to i386

[Peter Jeremy]

On 2002-Mar-03 13:51:25 +0100, Cyrille Lefevre <cyrille.lefevre at laposte.net> wrote:
>Mike Haertel wrote:
>> >Anyhow I have started gathering the tools (Watcom C compiler now
>> >open source and free!  www.openwatcom.org)
>> 
>> They have announced that it *will be* open source and free,
>> but so far as far as I can tell there is nothing available
>> at openwatcom.org except a binary-only patch to upgrade 
>> the last commercial version 11 to 11.0c.
>> 
>> So, it isn't yet.  Right now it's just vaporware.
>
>as of march 2002, try the download page to get the "binary" compiler.
>
>	http://www.openwatcom.com/download.html

For several years now, Sybase has been announcing that it will release
the source code to its C/C++ and FORTRAN compilers.  This is _still_
vaporware.  Their latest press release suggests that they have decided
on a License - but won't even make that public at present.

You can download a Windoze executable, but that is not of much use for
Unix.  And the size of the download suggests that there will need to
be a fair bit of work to make it run natively in a 16-bit environment.

At this time, the only open-source 16-bit x86 C compiler I know of is
Bruce Evans' C compiler (bcc).

Peter

[TUHS] Re: Porting Unix v6 to i386

[Tim Shoppa]

> At this time, the only open-source 16-bit x86 C compiler I know of is
> Bruce Evans' C compiler (bcc).

Don't forget James Hendrix's "Small C", which has been around since
what feels like forever.  80x86 and many other ports are available.

  http://www.ddjembedded.com/languages/smallc/

The sources are available and widely distributed, though the license
is certainly not a carbon-copy of the GPL (i.e. some will call it
"not open" for one reason or another).

Tim.

[TUHS] Re: Porting Unix v6 to i386

[Peter Jeremy]

On 2002-Mar-03 15:46:23 -0500, Tim Shoppa <shoppa at trailing-edge.com> wrote:
>> At this time, the only open-source 16-bit x86 C compiler I know of is
>> Bruce Evans' C compiler (bcc).
>
>Don't forget James Hendrix's "Small C", which has been around since
>what feels like forever.  80x86 and many other ports are available.
>
>  http://www.ddjembedded.com/languages/smallc/

I remember when that came out...  I hadn't considered it because as I
recall, it was a fairly small subset - I though it was too small to be
useful for Unix porting.  Looking at v2.2 for x86, it doesn't support
floating point, short, long, unsigned, sizeof, casts, non-automatic
locals, arrays of pointers, structs or unions.  This makes it too
restrictive for porting Unix.

Peter

[TUHS] Re: Porting Unix v6 to i386

[Lauri Aarnio]

In message <20020130091842.A12653 at apple.ukc.ac.uk>, "P.A.Osborne" writes:
>Well that is what I intended,  certainly as a starting reference for
>floppy, console drivers etc - IDE can wait till later.  Initially I 
>would like to get v6 or 7 (probably 6 as the Lions commentary is
>available) booting a kernel.   

Have you considered using Tanenbaum's Minix as a reference ?
Earlier versions were made for 8086, version 2.0 (which seems
to be te latest?) has been ported to 286/386 (= 16 / 32-bit
protected mode code depending on a flag). And it has a C-compiler,
too. See http://www.cs.vu.nl/~ast/minix.html for more.
(I haven't been following Minix development since 1990 or 1991 -
around that time we ported the original minix to the 386 (minix 
2.0 is a different thing, not based on our port). Anyway,
the biggest part of that project was related to protected mode
memory management.
It wasn't as simple as it sounds, mostly because the original 
documents (Intel databooks) were misleading, contained lots of
errors and also otherwise hard to read (bits of information evenly
distributed around the book...). The books may or may not be better
now, but in any case, get a working reference implementation.

	Lauri

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Thu, Jan 31, 2002 at 11:18:06AM +0200, Lauri Aarnio wrote:
> Have you considered using Tanenbaum's Minix as a reference ?

Funnily enough - no.  Which was a tad daft as I have a copy
of the original Tanenbaum book on a shelf about 2 feet above
the monitor....  :-)   sheepish grin


<snipped relevant Minix stuff>

> It wasn't as simple as it sounds, mostly because the original 
> documents (Intel databooks) were misleading, contained lots of
> errors and also otherwise hard to read (bits of information evenly
> distributed around the book...). The books may or may not be better
> now, but in any case, get a working reference implementation.


I was caught out on the Intel databooks a few years ago,  I dread
returning...

:-)

Paul

[TUHS] Re: Porting Unix v6 to i386

[Sven Dehmlow]

On Thursday 31 January 2002 12:00, P.A.Osborne wrote:
> On Thu, Jan 31, 2002 at 11:18:06AM +0200, Lauri Aarnio wrote:
> > Have you considered using Tanenbaum's Minix as a reference ?
>
> Funnily enough - no.  Which was a tad daft as I have a copy
> of the original Tanenbaum book on a shelf about 2 feet above
> the monitor....  :-)   sheepish grin
>

Good than it will be easy for you to take a look into this book and 
to find out that Minix is a microkernel. You want to code a 
monolithic kernel.

Any questions? ;-)


[snip]

Sven

[TUHS] Re: Porting Unix v6 to i386

[Lauri Aarnio]

In message <02013117091301.00697 at linux>, Sven Dehmlow writes:
>On Thursday 31 January 2002 12:00, P.A.Osborne wrote:
>> On Thu, Jan 31, 2002 at 11:18:06AM +0200, Lauri Aarnio wrote:
>> > Have you considered using Tanenbaum's Minix as a reference ?
>>
>> Funnily enough - no.  Which was a tad daft as I have a copy
>> of the original Tanenbaum book on a shelf about 2 feet above
>> the monitor....  :-)   sheepish grin
>>
>
>Good than it will be easy for you to take a look into this book and 
>to find out that Minix is a microkernel. You want to code a 
>monolithic kernel.

It doesn't matter at all if it is a microkernel or not, if somebody
just needs a reference implementation; How device drivers work or how
the '286 memory management needs to be set up is practically the same;
what matters is that Minix runs in 16-bit protected mode whereas 
Linux and *BSD don't.

	Lauri

[TUHS] Re: Porting Unix v6 to i386

[Greg Lehey]

On Thursday, 31 January 2002 at 20:45:03 +0200, Lauri Aarnio wrote:
> In message <02013117091301.00697 at linux>, Sven Dehmlow writes:
>> On Thursday 31 January 2002 12:00, P.A.Osborne wrote:
>>> On Thu, Jan 31, 2002 at 11:18:06AM +0200, Lauri Aarnio wrote:
>>>> Have you considered using Tanenbaum's Minix as a reference ?
>>>
>>> Funnily enough - no.  Which was a tad daft as I have a copy
>>> of the original Tanenbaum book on a shelf about 2 feet above
>>> the monitor....  :-)   sheepish grin
>>>
>>
>> Good than it will be easy for you to take a look into this book and
>> to find out that Minix is a microkernel. You want to code a
>> monolithic kernel.
>
> It doesn't matter at all if it is a microkernel or not, if somebody
> just needs a reference implementation; How device drivers work or how
> the '286 memory management needs to be set up is practically the same;
> what matters is that Minix runs in 16-bit protected mode whereas
> Linux and *BSD don't.

To repeat what I said earlier: the hardware-dependent code isn't very
interesting, it's the kernel interfaces.  Minix is not UNIX; BSD is.
You'll find it easier to adapt a BSD driver to the Sixth or Seventh
Edition than you will a Minix or Linux driver.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers

[TUHS] Re: Porting Unix v6 to i386

[Michael Davidson]

Greg Lehey wrote:

>
>To repeat what I said earlier: the hardware-dependent code isn't very
>interesting, it's the kernel interfaces.  Minix is not UNIX; BSD is.
>You'll find it easier to adapt a BSD driver to the Sixth or Seventh
>Edition than you will a Minix or Linux driver.
>
The bits that are "interesting" or "useful" to any particular person are 
the bits which
help to fill in the gaps in their knowledge and are therefore likely to 
be different for
different people. 

I am inclined to think that *none* of the other operating systems that 
have been mentioned
- Linux, Minix, BSD UNIX etc - are of much use *except* as a reference 
for how to do
certain things with the hardware (and they probably aren't even very 
good for that purpose)

UNIX has come a *long* way since V6 and V7, and a modern BSD device 
driver with
support for disk partitioning schemes, bad block mapping and 
who-knows-what-else is a
very different beast from the V6 rk11 driver.

To me, at least, the "obvious" way to get a V6 or V7 disk driver working 
is to do exactly
what almost everyone used to do when faced with this problem - you start 
with
something like the rk11 driver, study it until you understand how it 
works (or at least
think that you do ...) and then modify it to talk to your particular 
piece of hardware.

 From that perspective, what you *really* need is good documentation for 
the PC
hardware that you are going to be dealing with - ie interrupt 
controller, dma controller,
floppy controller, ide interface etc.

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Mon, Feb 04, 2002 at 02:12:27PM -0800, Michael Davidson wrote:
> I am inclined to think that *none* of the other operating systems that 
> have been mentioned
> - Linux, Minix, BSD UNIX etc - are of much use *except* as a reference 
> for how to do
> certain things with the hardware (and they probably aren't even very 
> good for that purpose)


I feel that Linux and *BSD are possibly overkill for reference as
a device driver model.  Mainly because they have evolved so far on
from what Vx is and they were even in the earliest days.  

I DO feel however that the source of a current PC system could be a 
good example of how to talk to the floppy, keyboard etc etc at the
lowest level ie performing the read, write etc etc.  So because of
its small size and the fact that it doesn't have hundreds of people
editing the code then say MINIX could be very usefull as a "how did
they read from the floppy drive";  NOT how did they do process 
scheduling.

So for example taking the source for the RK driver from V6  rk.c:
If we were say in a PC version to call the floppy drive RK (why not?),
then the aim would surely be to rewrite the appropriate functions
so they are specific to the PC floppy drive.


> UNIX has come a *long* way since V6 and V7, and a modern BSD device 
> driver with
> support for disk partitioning schemes, bad block mapping and 
> who-knows-what-else is a
> very different beast from the V6 rk11 driver.

Of course it is.  Otherwise I would still be using a magnet to edit
the hard disk the hard way.  I don't think for one minute we should
provide that level of sophistication.  

Instead we should aim at getting a "1970s version of Unix" running on 
a PC.  So initially  the teletype becomes the screen and the keyboard
and the disk unit becomes say the floppy drive.   

Later things can be expanded to talk IDE/SCSI whatever - but at that 
point you are evolving the "1970s version of Unix" on a stage further - 
which at present is not what I (at least) consider a goal of any 
potential porting project to be.   It becomes part of a wish list.

At present I would be extremely happy with being able to put a 1.44MB
floppy disk in a PC and watch the PC boot an early Unix,  provide a shell
and be able to use a few tools.  

I don't think that initially we should aim for any more than that.

My apologies if I am raining on anyones parade or this mail has gone
out of context to the one I am replying to,  or is even turning into
a rant.  Sorry if I am irritating anyone.

> To me, at least, the "obvious" way to get a V6 or V7 disk driver working 
> is to do exactly
> what almost everyone used to do when faced with this problem - you start 
> with
> something like the rk11 driver, study it until you understand how it 
> works (or at least
> think that you do ...) and then modify it to talk to your particular 
> piece of hardware.

Exactly.  That way you waste less time mucking around.

>  From that perspective, what you *really* need is good documentation for 
> the PC
> hardware that you are going to be dealing with - ie interrupt 
> controller, dma controller,
> floppy controller, ide interface etc.

The PC Indispensible Hardware Book ISBN: 0201596164   is dead good for this.
A quick look at Amazon reveals that there is a new edition - which is 
going to cover hardware we are unlikely to use - so an earlier edition may
be found fairly cheaply.  Besides I am not forking out for another copy
just yet - the wifes course books are crippling my bank account as it is.  :-)

Regards

Paul

[TUHS] Re: Porting Unix v6 to i386

[Jeffrey S. Sharp]

On Tue, 5 Feb 2002, P.A.Osborne wrote:

> Instead we should aim at getting a "1970s version of Unix" running on a
> PC.  So initially the teletype becomes the screen and the keyboard and
> the disk unit becomes say the floppy drive.
>
> Later things can be expanded to talk IDE/SCSI whatever - but at that
> point you are evolving the "1970s version of Unix" on a stage further -

Screen => console tty is obvious.  But why do you insist on the floppy
drive as the storage medium?

The floppy drive subsystem has drives and a controller with a certain
programatic interface.  The IDE/SCSI subsystem has drives and a controller
with a certain programatic interface.  They're the same kind of thing.
Why is one more guilty of evolving the 1970s version of UNXI?

I think that a floppy might make a good RK03/05 (capacity differences
aside), but why not implement some RP drives with hard drives of even zip
drives?

--
Jeffrey S. Sharp
jss at subatomix.com

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Wed, Feb 06, 2002 at 10:36:42AM -0600, Jeffrey S. Sharp wrote:
> > Instead we should aim at getting a "1970s version of Unix" running on a
> > PC.  So initially the teletype becomes the screen and the keyboard and
> > the disk unit becomes say the floppy drive.
> >
> > Later things can be expanded to talk IDE/SCSI whatever - but at that
> > point you are evolving the "1970s version of Unix" on a stage further -
> 
> Screen => console tty is obvious.  But why do you insist on the floppy
> drive as the storage medium?

I don't insist on it.  It was just my reckoning to get things going,  that
a floppy as an RK would be enough.

> The floppy drive subsystem has drives and a controller with a certain
> programatic interface.  The IDE/SCSI subsystem has drives and a controller
> with a certain programatic interface.  They're the same kind of thing.
> Why is one more guilty of evolving the 1970s version of UNXI?

Re-reading that last mail of mine,  I see that my mind kind of meandered.
So to be honest - I think you could well be right.

> I think that a floppy might make a good RK03/05 (capacity differences
> aside), but why not implement some RP drives with hard drives of even zip
> drives?

I don't see any particular reason not to do so.  I was attempting to
openly straighten my own thoughts out (perhaps thinking out loud is not
the best plan) and suggest that initially an RK - floppy would be a start,
and that RP - hard disk could be done later.

Paul

[TUHS] Re: Porting Unix v6 to i386

[Greg Lehey]

On Tuesday, 29 January 2002 at 17:57:58 -0800, Aaron J. Grier wrote:
> On Mon, Jan 28, 2002 at 10:03:45PM +0100, Jonathan Naylor wrote:
>
>> With so much open source code out there, it'd be a relatively simple
>> task to find C code for IDE disc access and such like. I would even
>> suggest getting older Linux code from the 2.0.x days as its likely to
>> be a little less complex, while still being stable.
>
> Linux!?  why not one of the three BSD-licensed BSD-derived Net/Free/Open
> BSDs?  keep it "in the family" so to speak.  :)

An obvious reason to prefer the BSD code is that the kernel interfaces
are pretty much the same.  There are some significant differences in
Linux.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers

[TUHS] Re: Porting Unix v6 to i386

[Aaron J. Grier]

On Fri, Feb 01, 2002 at 10:24:30AM +0000, P.A.Osborne wrote:

> The reason I want the compiler is that it will generate standalone 16
> bit code on a sensible platform.    GCC doesnt produce 16 bit code as
> far as I am aware - so personally I thought it would be amusing (I
> must be mad) to use tools that run under DOS (well OS/2).

support for PDP-11 was added to gcc a few months ago.  I don't think
it's been well tested, but support exists in current versions of
binutils and gcc.

http://pdp11.nocrew.org/

there's also support for the m68hc11/12 which are 16-bit.

it seems like support for 80{,1,2}86 in gcc should be possible; it just
hasn't been done yet.

another compiler that might be worth looking at is SDCC
http://sdcc.sourceforge.net/ which is currently targeted towards 8-bit
MCUs.

of course bootstrapping via the original K&R compiler would be the
"classic" way to do it, though.  ;)

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com
      "[...] I generally haven't found IDM guys to be very good
       live acts, most of them just sit down at their laptop and
       tweak reaktor."  -- Brandon Daniel

[TUHS] Re: Porting Unix v6 to i386

[Peter Jeremy]

On 2002-Feb-14 14:30:50 -0800, "Aaron J. Grier" <agrier at poofygoof.com> wrote:
>support for PDP-11 was added to gcc a few months ago.  I don't think
>it's been well tested, but support exists in current versions of
>binutils and gcc.
>
>http://pdp11.nocrew.org/
>
>there's also support for the m68hc11/12 which are 16-bit.

This is only cross-compilation support.  gcc was never designed to be
hosted in a 16-bit environment.  An i386 gcc is:
   text    data     bss     dec     hex filename
1660236   22836   97104 1780176  1b29d0 /usr/libexec/cc1

Even taking into account the savings with 16-bit int's and pointers,
you won't get the data segment below 64k - and most of gcc's structures
are dynamically allocated.

>it seems like support for 80{,1,2}86 in gcc should be possible; it just
>hasn't been done yet.

Given that i386 is already supported, adding support for 16-bit x86
would be fairly easy.  The only major work would be handling the
16-bit addressing modes.

>another compiler that might be worth looking at is SDCC
>http://sdcc.sourceforge.net/ which is currently targeted towards 8-bit
>MCUs.

Again, no x86 support and I don't believe the code generation is
that good.

>of course bootstrapping via the original K&R compiler would be the
>"classic" way to do it, though.  ;)

The PDP-11 is orthogonal and so PCC doesn't have to worry about
getting particular operands into particular registers.  I suspect
that supporting the i386's idiosyncracies would be non-trivial.

Peter

[TUHS] Re: Porting Unix v6 to i386

[Lars Brinkhoff]

"Aaron J. Grier" <agrier at poofygoof.com> writes:
> support for PDP-11 was added to gcc a few months ago.  I don't think
> it's been well tested, but support exists in current versions of
> binutils and gcc.

You are confusing gcc and binutils.  PDP-11 support as added to
binutils recently.  However, it's not well tested, and is likely
to need more work to be usable.

John Holden <johnh at psych.usyd.edu.au> writes:
> > support for PDP-11 was added to gcc a few months ago. 
> It's been around since 1991 as a patch, but it didn't keep up with
> the newer versions of gcc

It's still there, and some people are looking after it from time to
time, but it's probably too broken to be useful.  However, there has
been some interest in building a complete GNU cross tool chain for the
PDP-11.

-- 
Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10,
Brinkhoff Consulting    http://www.brinkhoff.se/    HTTP programming

[TUHS] Re: Porting Unix v6 to i386

[norman]

Greg Lehey:

  To repeat what I said earlier: the hardware-dependent code isn't very
  interesting, it's the kernel interfaces.  Minix is not UNIX; BSD is.
  You'll find it easier to adapt a BSD driver to the Sixth or Seventh
  Edition than you will a Minix or Linux driver.

It depends on approach, which depends in turn on intent.

If the intent is to get a system up and running as quickly as possible,
it would probably be best to shoehorn existing code into the existing
old UNIX framework, and code from a current BSD system is probably easier
to do that with than code from Minix (says someone who has looked at
neither within living memory).

If the intent is to learn about the innards of operating systems and
how they interact with hardware, or about the specifics of old UNIXes
or the OS aspects of Intel hardware, it is better to compare different
descriptions of the hardware (whether abstract descriptions in books
or pragmatic ones in code), write your own small test programs to be
run on bare hardware or as special cases within some system that
already runs there, and eventually write your own code or adopt code
that you now understand thoroughly.

Which of these you consider fun depends both on your goals and on your
personal taste.  Both are worthy of respect.

In days long past, when I did a lot of work to make a research version
of UNIX as robust as possible against hardware flaws (recover if possible,
at least explain clearly what broke if not) and to port it to a few new
VAXes of the time, I found the best hardware information to lie in the
VAX/VMS source fiche.  The UNIXes of the day tended either to crash on
the slightest hardware error or to ignore the error and just misbehave
until rebooted.  Stealing code from them would have been easier, but it
wouldn't have done what I wanted.  Reading the VMS sources and treating
them as a hardware reference manual did.  Modern UNIXes doubtless do
better, but the point is that different systems do different things
with the hardware, and if your goal is understanding and not just
function, you will gain more by looking in many places.

An irrelevant but fun anecdote:  it could be argued that the resulting
code recovered too smoothly from errors.  One day I discovered that
one of our systems was running more slowly than usual, though it was
otherwise OK; checking back on the paper console log, I discovered
that several weeks earlier it had had a hard cache error, reported it
and cheerfully turned off the bad half of the cache, and continued on
its way.  So I called Field Service and we scheduled a convenient time
to run diagnostics--yes, the hardware really had failed--and replace
the bad CPU board; but it would have been better to have noticed
earlier.  I watched the console logs more carefully after that.

Norman Wilson
Toronto ON

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Fri, Feb 01, 2002 at 02:43:53PM -0500, bwc at borf.com wrote:
> Regarding the few comments in Ken's kernel--I always found the great--you
> can get the Lyons' commentary which may be another reason for doing Sixth.

My thoughts exactly funnily enough.

Pondering just this over the weekend has left me wondering whether 
MiniUnix would be a better initial place to start - as its essentially 
V6, but without memory management or pipes.   Which as a starting point 
for the experiment may be an easier place to start.

Thoughts anyone?


Also as a sideline,  I don't know how the list owner of this list
feels about this discussion potentially swamping the list.  If this
is an issue or other readers of the list are sick and tired of the
current ruminations please feel free to let me know and I will create
a mailing list on the list manager here at UKC.  That way those of 
us who are regarded as sad, mad or just plain losers can take our
mutterings somewhere else.

:-)

Paul

[TUHS] Re: Porting Unix v6 to i386

[Warren Toomey]

In article by P.A.Osborne:
> [V6 is well described in the Lions Commentary]
> My thoughts exactly funnily enough.

Well, seeing as though Paul referred to me (see below), I'll throw my
own $0.02 in. I'd recommend V7 for several reasons:

	- it's more portable
	- the flavour of C used is more modern
	- it's got more useful applications (yacc etc.)
	- you get the stdio library
	- one last thing, there were some awful race conditions and
	  bogosities in V6 that just had to be fixed. See the
	  `50 bugs' tape, and also Dennis' own admission about
	  6th Edition savu/retu at
	  http://cm.bell-labs.com/cm/cs/who/dmr/odd.html
 
> Pondering just this over the weekend has left me wondering whether 
> MiniUnix would be a better initial place to start - as its essentially 
> V6, but without memory management or pipes.   Which as a starting point 
> for the experiment may be an easier place to start.

You could port that in a short amount of time, and treat it as a
warming-up exercise!
 
> Also as a sideline,  I don't know how the list owner of this list
> feels about this discussion potentially swamping the list.

I think the list needs some traffic :-) It might be worth setting up
a list for the e-mails between co-developers, but also to have periodic
status reports and questions sent to this list.

> That way those of 
> us who are regarded as sad, mad or just plain losers can take our
> mutterings somewhere else.

Why do you think I set this list up in the first place ;-) ??!

Cheers,
	Warren

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

On Mon, Feb 04, 2002 at 08:57:28PM +1000, Warren Toomey wrote:
> Well, seeing as though Paul referred to me (see below), I'll throw my
> own $0.02 in. I'd recommend V7 for several reasons:
> 
> 	- it's more portable
> 	- the flavour of C used is more modern
> 	- it's got more useful applications (yacc etc.)
> 	- you get the stdio library
> 	- one last thing, there were some awful race conditions and
> 	  bogosities in V6 that just had to be fixed. See the
> 	  `50 bugs' tape, and also Dennis' own admission about
> 	  6th Edition savu/retu at
> 	  http://cm.bell-labs.com/cm/cs/who/dmr/odd.html

Hmmm.  I am starting (I have to admit) to lean towards V7 as my thoughts
continue.  I hadn't seen the "50 bugs" tape - although I believe I have
a copy archived somewhere.  Must take a gander at some point and mount
it on the emulator.

> > Pondering just this over the weekend has left me wondering whether 
> > MiniUnix would be a better initial place to start - as its essentially 
> > V6, but without memory management or pipes.   Which as a starting point 
> > for the experiment may be an easier place to start.
> 
> You could port that in a short amount of time, and treat it as a
> warming-up exercise!

Thats what I was thinking - it also alows a honing of very rusty skills,
and also allows building of tools that will be needed on the way.  

Also I dont suppose that anyone has the tarred up source for MiniUnix
they could mail me?  (It just saves me from extracting it out of
the tape/disk images the hard way).

One thing I am undecided about though is this:

Should the source be converted to from pre K&R C  to ANSI C for
the sake of updating the system to run on a newer architecture (though
not much since the PC was released in 1980 and we only need 16bits).

OR

Should we attempt to provide a new compiler (or preparser) which will
take the pre K&R C and just compile it as is?

I have to admit the above comments are straight off the top of my head,
and haven't been considered at any length and indeed should be (over
several pints of ale).  

> > Also as a sideline,  I don't know how the list owner of this list
> > feels about this discussion potentially swamping the list.
> 
> I think the list needs some traffic :-) It might be worth setting up
> a list for the e-mails between co-developers, but also to have periodic
> status reports and questions sent to this list.

OK once we get to that stage (I am still reading up and checking out
the different architectures at present - so me writing code
isnt going to happen yet until I at least have been over the printed source
with a red pen) which could be a while,  I guess either I can run 
a list here at UKC or maybe Warren would like to put one up at Minnie?

Regards

Paul

[TUHS] Re: Porting Unix v6 to i386

[P.A.Osborne]

> >http://hp.openwatcom.org/ftp/zips/    for the binaries
> >http://hp.openwatcom.org/ftp/docs/    for PDFs of the documentation
> 
> Cool!

Thanks.

> Still, no source code => not much use for porting Unix, unless you
> want to be limited to cross-compiling from DOS.  (Making the Watcom
> binaries run under v6 Unix seems very unlikely since they probably
> use fancy 32-bit extenders that know all sorts of esoterica about
> DOS memory management...)

The reason I want the compiler is that it will generate standalone
16 bit code on a sensible platform.    GCC doesnt produce 16 bit
code as far as I am aware - so personally I thought it would be
amusing (I must be mad) to use tools that run under DOS (well OS/2).

> Someone else on the mailing list suggested using old versions of
> Tanenbaum's Minix, which has a different set of compilers; again
> the problem is, no compiler source code last time I looked at Minix.
> 
> So far the only viable compiler suggestion seems to be the one
> from Warner Losh who recommended bcc.  (Or, port the PDP-11 compiler
> yourself.)

I think we are looking at this from different ends, let me try and explain:

Initially we need to be able to compile the kernel/system so it runs,
I feel that updating the code to ANSI C and using a modern compiler
will do the job for that.

Eventually it would be nice to be able to get v6-i86 (or whatever we 
call it) to boot itself and then be able to compile itself - at that
point it becomes a complete project.  

It is however essentially two projects:
1.   rewriting the OS so it boots as i86
2.   (re)writing a compiler that will run native and be able to compile 
     the OS on its own platform 

The second part is not essential by any means,  but it could by the 
purists be considered the ultimate goal.  

Paul

[TUHS] Re: Porting Unix v6 to i386

[Grant Maizels]

Actually I have 8086 C compilers on my old Altos systems (486 and 586)
running Xenix.
The OS on the 486 is a very early version of Xenix which is really a
slightly modified version of v7.

If the machine still works (has not been turned on for a few years), I may
be able to set it up so that it can be accessed through a terminal server
off the internet so that it can be used to do compiles.

I think that Microsoft may own the copyrights on these old compilers (not
sure), but it would be nice if the source was publicy available (or even
binaries).

If the machine still works (has not been turned on for a few years), I may
be able to set it up so that it can be accessed through a terminal server
off the internet so that it can be used to do compiles.

The 486 with v7 has an 8086, 512k memory, 12Meg hard disk. With the full V7
OS, including c (lex, yacc, ...) , troff, and some Microsoft add-ons
(fortran, cobol, mutimate??) fits in 7 Meg.

Grant Maizles


P.S. The 486 and 586 names refer to the number of supported users which the
machine can handle and the fact that it has a 8086 CPU. The configs were

486 5 Serial ports (1 for a printer)
586 6 Serial ports

I had a customer with a 986 which had 10 serial ports.

> -----Original Message-----
> From: M. Warner Losh [mailto:imp at village.org]
> Sent: Thursday, January 31, 2002 7:54 AM
> To: mike at ducky.net
> Cc: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] Re: Porting Unix v6 to i386
> 
> 
> In message: <200201301952.g0UJq0E39966 at ducky.net>
>             Mike Haertel <mike at ducky.net> writes:
> : >Anyhow I have started gathering the tools (Watcom C compiler now
> : >open source and free!  www.openwatcom.org)
> : 
> : They have announced that it *will be* open source and free,
> : but so far as far as I can tell there is nothing available
> : at openwatcom.org except a binary-only patch to upgrade 
> : the last commercial version 11 to 11.0c.
> : 
> : So, it isn't yet.  Right now it's just vaporware.
> 
> The only compiler I know of that deals properly with generating 16-bit
> x86 code is bcc, which the Elks folks use to build their kernel.  This
> is Bruce Evan's compiler with support for prototypes bolted on, iirc.
> 
> 	http://www.cix.co.uk/~mayday/
> 
> It is a tad Linux centric, but I was able to get it to build with only
> a few tweaks on FreeBSD.  It is sufficient to build the elks tree, but
> I've not tried it on anything else.
> 
> Warner
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs
> 

[TUHS] Re: Porting Unix v6 to i386

[John Holden]

I think that v7 would be far easier to port than v6. Although it's not much
bigger than v6, the code is a lot cleaner, and there are less machine
dependencies.  One of the reasons for a lot of the changes between v6 and v7
was a conscious effort to make it more portable . The old assignment operators
like '=+' changed to "+=".  'Unsigned' and 'long' data types are missing
from v6 (and reflected in the kernel), so all integer calculations were 16
bits. Unsigned ops were done using 'char *'. v7 was ported to the Vax and the
Interdata.

ioctl is there, and the 'standard io' library. The file seek call in v6 had
either block (512) or byte offsets, and v7 introduced lseek to replace it. Only
16 bits were used to store block numbers in inodes, so filesystem sizes were
restricted (not a real problem since both v6 and v7 could run happily on a 2.5Mb
RK05 disk, including swap space and c compiler). 'vi' ran under v7, but v6 only
offered 'ed' (or variants like 'em') and 'qed'

If you hadn't guessed, v7 is by far my favourite Unix variant. Lean, clean and
without the latter clutter of supporting networking in the kernel.