The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <>
To: The Eunuchs Hysterical Society <>
Subject: [TUHS] Early Unix on (64-bit) Risc-V
Date: Thu, 22 Dec 2022 11:55:04 +0100	[thread overview]
Message-ID: <> (raw)

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.

             reply	other threads:[~2022-12-22 10:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 10:55 Paul Ruizendaal [this message]
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

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).