[pups] Re: GCC

[pups] Re: GCC

[Aaron J. Grier]

On Thu, Jan 17, 2002 at 08:36:05AM +0100, Lars Brinkhoff wrote:
> Hello,
> 
> Is anyone using GCC to compile code for the PDP-11?

on the PDP or cross-compiled?  (will gcc run under 2.11?)

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com
          "Making people dance so hard their pants almost fall
                 off is kind of fun."  -- David Evans

[pups] Re: GCC

[Wilko Bulte]

On Thu, Jan 17, 2002 at 10:53:20PM -0800, Aaron J. Grier wrote:
> On Thu, Jan 17, 2002 at 08:36:05AM +0100, Lars Brinkhoff wrote:
> > Hello,
> > 
> > Is anyone using GCC to compile code for the PDP-11?
> 
> on the PDP or cross-compiled?  (will gcc run under 2.11?)

On the PDP: very unlikely. gcc is far too big to fit in even split
ID I would assume?!

-- 
|   / o / /_  _   		email: 	wilko at FreeBSD.org
|/|/ / / /(  (_)  Bulte		Arnhem, the Netherlands

[pups] Re: GCC

[Lars Brinkhoff]

Wilko Bulte <wkb at freebie.xs4all.nl> writes:
> On Thu, Jan 17, 2002 at 10:53:20PM -0800, Aaron J. Grier wrote:
> > On Thu, Jan 17, 2002 at 08:36:05AM +0100, Lars Brinkhoff wrote:
> > > Is anyone using GCC to compile code for the PDP-11?
> > on the PDP or cross-compiled?  (will gcc run under 2.11?)

Cross compilation, I assume.  Doesn't matter to me, I just want to
know if anyone's using it.

> On the PDP: very unlikely. gcc is far too big to fit in even split
> ID I would assume?!

Yes.  Dunno if it could be made to work with overlays or something,
but it'd be very slow.

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

[pups] Re: GCC

[Warren Toomey]

In article by Aaron J. Grier:
> > Is anyone using GCC to compile code for the PDP-11?
> on the PDP or cross-compiled?  (will gcc run under 2.11?)

Not until you can get a 32-bit process address space and virtual paging
on the PDP-11 :-)

	Warren

[pups] Re: GCC

[Bill Gunshannon]

Not only is size a problem, but even as a cross-compiler it is lacking.
I am pretty sure support for the PDP stopped many releases ago and even
at the peak of support I don't believe there was ever as or ld support
for the PDP.  I have considered reviving the PDP cross compiling work
and looking at writting a translator to take the output from -S (which
I am quite certain would be AT&T format) and convert it to Macro-11.
I usually end out weighing this against the work necessary to just write
a C-compiler for the PDP (using Small C as a starting point).  If only
I could retire so I'ld have the free time.  :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill at cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

[pups] Re: GCC

[Lars Brinkhoff]

Bill Gunshannon <bill at cs.scranton.edu> writes:
> I don't believe there was ever as or ld support for the PDP.

I added PDP-11 support to GNU binutils last year.  It's not well
tested, though.

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

[pups] Re: GCC

[Aaron J. Grier]

On Fri, Jan 18, 2002 at 10:44:17PM +1000, Warren Toomey wrote:
> In article by Aaron J. Grier:
> > > Is anyone using GCC to compile code for the PDP-11?
> > on the PDP or cross-compiled?  (will gcc run under 2.11?)
> 
> Not until you can get a 32-bit process address space and virtual paging
> on the PDP-11 :-)

isn't that what VAX is all about?  ;)

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com
          "Making people dance so hard their pants almost fall
                 off is kind of fun."  -- David Evans

[pups] Re: GCC

[Johnny Billquist]

On Fri, 18 Jan 2002, Bill Gunshannon wrote:

> Not only is size a problem, but even as a cross-compiler it is lacking.
> I am pretty sure support for the PDP stopped many releases ago and even
> at the peak of support I don't believe there was ever as or ld support
> for the PDP.  I have considered reviving the PDP cross compiling work
> and looking at writting a translator to take the output from -S (which
> I am quite certain would be AT&T format) and convert it to Macro-11.
> I usually end out weighing this against the work necessary to just write
> a C-compiler for the PDP (using Small C as a starting point).  If only
> I could retire so I'ld have the free time.  :-)

Two things.
1. DECUS C might be a better starting point.
2. With DECUS C, you also have an as, which might fit the bill without
having to convert stuff to Macro-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

[pups] Re: GCC

[Jonathan Engdahl]

Consider lcc, the Princeton C compiler. It's much smaller than gcc, and ANSI
compliant.

--
Jonathan Engdahl            Rockwell Automation
Principal Research Engineer 1 Allen-Bradley Drive
Advanced Technology         Mayfield Heights, OH 44124 USA
Mayfield Heights Labs       engdahl at safeaccess.com 440-646-7326

[pups] Re: GCC

[Lars Brinkhoff]

Johnny Billquist <bqt at update.uu.se> writes:
> DECUS C might be a better starting point.

norman at nose.cs.utoronto.ca writes:
> I would probably use lcc as a cross-compiler myself, after writing
> or snitching a code generator of course.

bwc at borf.com writes:
> I got Dennis' sixth edtion compiler to compile not long ago.
> My advice would be to start there.

How about the 2.11BSD compiler?  

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

[pups] Re: GCC

[Warren Toomey]

In article by Lars Brinkhoff:
> norman at nose.cs.utoronto.ca writes:
> > I would probably use lcc as a cross-compiler myself, after writing
> > or snitching a code generator of course.
> 
> bwc at borf.com writes:
> > I got Dennis' sixth edtion compiler to compile not long ago.
> > My advice would be to start there.
> 
> How about the 2.11BSD compiler?  

The next question is, why to do this, and for which operating system(s)?

If it's to get an ANSI C compiler, or some extra performance, then I
can see the point. If it's to ditch a `contaminated' compiler, then
I can see a few difficulties, especially if the target is 2.11BSD

The 2.11BSD linker knows an awful lot about overlays, and any replacement
would need to do the same.

Anway, that's my $0.02. I thought about porting lcc to 2.11BSD ages ago,
but I've never had the time to do it.

Cheers,
	Warren

[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

[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

[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

[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

[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

[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 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

[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

[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

[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

[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

[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

[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

[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

[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

[pups] Re: GCC

[Davidson, Steve]

Johnny,

I have access to both RT-11 and RSTS/E systems here.  I would be happy to
give the testing a shot.  My preference would be RT first, and then if you
get no other takers, RSTS.

Regards,

			Steve

> -----Original Message-----
> From:	Johnny Billquist [SMTP:bqt at update.uu.se]
> Sent:	Saturday, January 19, 2002 10:13
> To:	SHOPPA at trailing-edge.com
> Cc:	PUPS at minnie.tuhs.org
> Subject:	Re: [pups] Re: GCC
> 
> On Sat, 19 Jan 2002 SHOPPA at TRAILING-EDGE.COM wrote:
> 
> > Johnny Billquist <bqt at update.uu.se> writes:
> > > DECUS C might be a better starting point.
> > 
> > DECUS C is kind-of a funny case.  Whereas most C compilers are
> > traditionally maintained and distributed as C source code, DECUS C
> > is distributed and maintained in PDP-11 assembly language.
> 
> True.
> 
> > For other C compilers, a significant milestone was when they were
> > rewritten in C and compiled themselves.  DECUS C is the odd guy out
> because
> > it never tried to reach this milestone.  In some sense this is a good
> thing,
> > because it lets you build it on a machine without any access to any C
> compiler.
> 
> Which definitely is a good thing in this case. Since most systems don't
> have a C compiler anyway, the first compiler have to get down there
> someway, and MACRO-11 is the only language you *know* exist.
> 
> I'm soon done with a cleanup of DECUS-C by the way. I've tried to collect
> all the different versions I can find, and incorporated my own fixes as
> well. This version will support I/D space correctly in RSX (which no other
> version except my in-house hacks have done), will have a working profiler
> again, and also supports RMS and DAP. Fun fun...
> I'm testing it right now, and most things looks like they are working like
> a charm.
> However, if someone have plenty of time, and an RSTS/E or RT-11 system
> around, I'd sure appreciate some help. I've tried to keep those parts
> up-to-date as well, but I cannot test, or fix broken things.
> 
> This compiler have been a mess for many years now... About time it got
> some cleanup.
> 
> Oh. And I don't know if Allan Baldwin (sp?) have some extra hacks in for
> his IP-stack, and I haven't even investigated.
> Anyone know?
> 
> 	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
> 
> _______________________________________________
> PUPS mailing list
> PUPS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/pups

[pups] Re: GCC

[Johnny Billquist]

On Sat, 19 Jan 2002 SHOPPA at TRAILING-EDGE.COM wrote:

> Johnny Billquist <bqt at update.uu.se> writes:
> > DECUS C might be a better starting point.
> 
> DECUS C is kind-of a funny case.  Whereas most C compilers are
> traditionally maintained and distributed as C source code, DECUS C
> is distributed and maintained in PDP-11 assembly language.

True.

> For other C compilers, a significant milestone was when they were
> rewritten in C and compiled themselves.  DECUS C is the odd guy out because
> it never tried to reach this milestone.  In some sense this is a good thing,
> because it lets you build it on a machine without any access to any C compiler.

Which definitely is a good thing in this case. Since most systems don't
have a C compiler anyway, the first compiler have to get down there
someway, and MACRO-11 is the only language you *know* exist.

I'm soon done with a cleanup of DECUS-C by the way. I've tried to collect
all the different versions I can find, and incorporated my own fixes as
well. This version will support I/D space correctly in RSX (which no other
version except my in-house hacks have done), will have a working profiler
again, and also supports RMS and DAP. Fun fun...
I'm testing it right now, and most things looks like they are working like
a charm.
However, if someone have plenty of time, and an RSTS/E or RT-11 system
around, I'd sure appreciate some help. I've tried to keep those parts
up-to-date as well, but I cannot test, or fix broken things.

This compiler have been a mess for many years now... About time it got
some cleanup.

Oh. And I don't know if Allan Baldwin (sp?) have some extra hacks in for
his IP-stack, and I haven't even investigated.
Anyone know?

	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

[pups] Re: GCC

[SHOPPA]

Johnny Billquist <bqt at update.uu.se> writes:
> DECUS C might be a better starting point.

DECUS C is kind-of a funny case.  Whereas most C compilers are
traditionally maintained and distributed as C source code, DECUS C
is distributed and maintained in PDP-11 assembly language.

For other C compilers, a significant milestone was when they were
rewritten in C and compiled themselves.  DECUS C is the odd guy out because
it never tried to reach this milestone.  In some sense this is a good thing,
because it lets you build it on a machine without any access to any C compiler.

Tim.

[pups] Re: GCC

[Bill Gunshannon]

On Fri, 18 Jan 2002 bwc at borf.com wrote:

> Just check out the chapter on precidence parsing in the dragon book
> before you work on the compiler.

The dragon book!!  The best book on compilers ever written.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill at cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

[pups] Re: GCC

[bwc]

I got Dennis' sixth edtion compiler to compile not long ago.
It's definitly not ANSI C, in fact it's not quite K&R C, but
I really like coding in it.  My advice would be to start there.

Just check out the chapter on precidence parsing in the dragon book
before you work on the compiler.

  Brantley Coile

[pups] Re: GCC

[norman]

Jonathan Engdahl:

  Consider lcc, the Princeton C compiler. It's much smaller than gcc, and ANSI
  compliant.

lcc's a good compiler; it has become cc in my own peculiar Ancient UNIX
environment.  But my environment is on VAXes, not PDP-11s; the lcc I use
probably cannot be compiled to a core compiler binary of less than about
180KB, of which 136KB is text, and that is without any real code generators.
(For those who know lcc: I am using a slightly-hacked-up lcc 3.6; the
180KB binary includes just the symbolic and null code generators, not
the enormous one I ended up with for the VAX.)

On the other hand, it is probably easier to split lcc into overlays or
multiple passes to make it fit on a PDP-11 than to do the same to gcc;
and lcc works fine as a cross-compiler.  And it's a good solid ANSI
compiler; enough so that it is a little annoying to use it on heritage
code (it grumbles, correctly, if a function returns no value and wasn't
declared void), and helpful or very painful (depending on your point of
view) when used on really old code that is sleazy about mixing types of
pointers in procedure arguments, or reusing one structure as part of another,
or the like.  I had an interesting time a few months ago getting an old
version of tbl to compile cleanly and produce correct results under lcc;
the program contained some ancient constructs that are truly remarkable
to look back on, especially for those of us who started out programming
that way and learned better the hard way ...

If I were going to work with PDP-11s, I would probably use lcc as a
cross-compiler myself, after writing or snitching a code generator of
course.

Norman Wilson