On Wednesday 30 January 2002 10:18, P.A.Osborne wrote: 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... ;-) 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

Johnny Billquist wrote: 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.

On Thu, 31 Jan 2002, P.A.Osborne 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". 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(a)update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

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.

In message: <200201301952.g0UJq0E39966(a)ducky.net> Mike Haertel <mike(a)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

Mike Haertel wrote: 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@laposte.net

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.

In message <20020130091842.A12653(a)apple.ukc.ac.uk>uk>, "P.A.Osborne" writes: 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

On Thursday 31 January 2002 12:00, P.A.Osborne wrote: 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

On Thursday, 31 January 2002 at 20:45:03 +0200, Lauri Aarnio 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. Greg -- Finger grog(a)lemis.com for PGP public key See complete headers for address and phone numbers

On Mon, Feb 04, 2002 at 02:12:27PM -0800, Michael Davidson wrote: 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. 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. Exactly. That way you waste less time mucking around. 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

On Wed, Feb 06, 2002 at 10:36:42AM -0600, Jeffrey S. Sharp wrote: I don't insist on it. It was just my reckoning to get things going, that a floppy as an RK would be enough. 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 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