The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Luther Johnson <>
Subject: [TUHS] Re: Fwd: Early Unix on (64-bit) Risc-V
Date: Fri, 30 Dec 2022 13:31:46 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 6163 bytes --]

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:
> And the SysIII port is here:
>> 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: * <>, 
>> <>, 
>> <>
>> 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.

[-- Attachment #2: Type: text/html, Size: 15570 bytes --]

      parent reply	other threads:[~2022-12-30 20:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 10:55 [TUHS] " Paul Ruizendaal
2022-12-30 18:24 ` [TUHS] Fwd: " Paul Ruizendaal
2022-12-30 19:50   ` [TUHS] " segaloco via TUHS
2022-12-30 20:31   ` Luther Johnson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).