Awesome ! I'll particularly be reading your thoughts on the Plan 9 tool chain with interest. Thanks for all of this ! On 12/30/2022 11:24 AM, Paul Ruizendaal wrote: > During the past year I’ve worked on and off on porting Sys III. My > approach to studying ancient Unix is to port it to a new system, as > that forces one to consider many of the design trade-offs in a code > base. For 16 bit Unix I used the TI990 as a target, for the 1980-1985 > period I was thinking about a 68030 based board. However, in the end > using a Riscv based target seemed more interesting and that is what I > used (more specifically the 64-bit Allwinner D1 chip, for which > several cheap boards are available, along with Fabrice Ballard’s > TinyEMU for simulation). > > In general, my approach was to first select a toolchain and I settled > on the Plan9 compiler suite, with the Riscv backend as done by Richard > Miller, used together with a library that enabled using this tool > chain on modern Unix. This I then used to port the educational XV6 > system to the D1 chip, building on work done by Michael Engel. From > there I ported the SysIII kernel (reusing some bits of XV6 memory > code), initially using the XV6 user land. From there I went on to port > the original SysIII user land. Much to my surprise, the original > SysIII code can support the Plan 9 tool chain, just a dozen standard > libc routines needed to be added to give this SysIII port a native > compiler. > > There is a lot to report, and I will split it over several posts > covering different aspects. I hope that this will not be perceived as > spamming this list. The topics are: > > 1. Riscv, Plan-9 and a toolchain > > 2. Porting the SysIII kernel: first steps & memory management > > 3. Porting the SysIII kernel: boot, config & device drivers > > 4. A few comments on porting the Bourne shell > > 5. Xv6, Linux and SysIII on a RV32 FPGA system > > For those who just want to see the results, the tool chain is here: > > https://gitlab.com/pnru/riscv-kencc > > And the SysIII port is here: > > https://gitlab.com/pnru/SysIII_rv64 > > >> Begin forwarded message: >> >> *From: *Paul Ruizendaal > >> *Subject: **Early Unix on (64-bit) Risc-V* >> *Date: *December 22, 2022 at 11:55:04 AM GMT+1 >> *To: *The Eunuchs Hysterical Society > > >> *Cc: *athornton@gmail.com , >> davida@pobox.com , luther@makerlisp.com >> >> >> >> Adam Thorton wrote: >> >>> I mean all I really want for Christmas is a 64-bit v7 with TCP/IP >>> support, a screen editor, and SMP support. >>> >>> The third one is a solved problem. The second one would not be that >>> hard to adapt, say, uIP 0.9, to v7. That first one would require >>> some work with C type sizes, but getting larger is easier than the >>> reverse. It's that last one. >>> >>> Having said that...maybe what I really want is 64-bit 4.3 BSD? >>> >>> I mean, just a Unix, without all the cruft of a modern Linux, but >>> which can actually take advantage of the resources of a modern >>> machine. I don't care about a desktop, or even a graphical >>> environment, I don't care about all the strange syscalls that are >>> there to support particular databases, I don't care much about being >>> a virtualization host. >> >> Luther Johnson wrote: >> >>> I'm in the process of building a system like that for myself, but >>> perhaps a little smaller - mine will be based on an embedded >>> microprocessor I've developed (so much work still yet to do ! at >>> least a >>> year out). >> >> Earlier this year I ported VAX System III to Risc-V, to a simple >> Allwinner D1 based SBC. This is RV64GC. Just ported to the console >> terminal. >> >> It turned out that porting Sys III to 64 bit was surprisingly easy, >> most of the kernel and user land appears to be 64 bit clean. It helps >> that I am using a LLP64 compiler, though. Apart from networking Sys >> III also feels surprisingly modern (for an ancient Unix) - its should >> get more attention than it does. The hardest work was in porting the >> VAX memory code to Risc-V page tables (and to a lesser extent, >> updating libc for the different FP formats). >> >> The code is currently in an ugly state (with debug stuff in >> commented-out blocks, a mix of ansi and K&R styles, an incoherent >> kludgy build system, etc.) and the shame stopped me from putting it >> out on gitlab until I found enough time to clean this up. As there >> seems to be some interest now, I’ll put it up anyway in the next week >> or so. There you go Adam, half your wish comes true. >> >> The kernel is about 60KB and most binaries are quite close in size to >> the VAX equivalents. >> >> My next goals for it are to re-implement the Reiser demand paging (I >> think I have a good enough view of how that worked, but the proof of >> the pudding will be in the eating), and to add TCP/IP networking, >> probably the BBN stack. Making it work on RV32 and exploring early >> SMP work is also on my interest list. >> >> === >> >> David Arnold wrote: >> >>> I think xv6 does SMP? (param.h says NCPU = 8, at least). >>> >>> You’d need to add a network stack and a userland, but there are >>> options for those … >> >> For the above, making xv6 work on the D1 board was my first stepping >> stone, to proof the tool chain and to get the basics right (hardware >> init, low-level I/O, etc.). >> >> As an educational tool, I am sure that xv6 hits all the right spots, >> and it certainly does SMP (the D1 is single hart, so I have not tried >> that myself). I like it a lot in that context. However, as a simple >> Unix it is useless: from a user-land view it is less capable than >> LSX. At minimum it needs fixes to make the file system less constrained. >> >> In my view, for SMP Keith Kelleman’s work for Sys-V is probably a >> better place to start. >> >