RISC-V OS Using Rust: Memory Management Unit | Hacker News Reader

RISC-V OS Using Rust: Memory Management Unit

osblog.stephenmarz.com

288 pointsazhenley26 comments

> Obviously, I wasn't consulted when this was kicked around, and I haven't done my due diligence to look up potential reasons. So, I risk embarrassment to preserve my time :(.

If anyone's wondering, I explained the reason:

https://github.com/pavehawk2007/osblog/issues/11

TL;DR: You're expected to still use the bits as access/dirty flags, but instead of the hardware automagically setting them, you set them yourself from the page fault handler. (Or if you don't need to track those things, you just set the flags to 1 from the start.)

> Just because we wrote 8 in the MMU mode, we don't quite have the MMU turned on. The reason is because we're in CPU mode #3, which is the machine mode. So, we need to switch to "supervisor"

I'd encourage him to start in Supervisor mode instead and use one of the standard bootloaders (bbl or openSBI) to deal with machine mode. This would be compatible with Linux and be more portable as different platforms will supply platform specific boot loaders.

RISC-OS is a thing, since 1987, but thats not what this post is about, for anyone who was confused like me.

https://en.wikipedia.org/wiki/RISC_OS

It’s a custom written OS for the RISC V processor written in Rust.

http://osblog.stephenmarz.com/index.html

Edit: original post I could’ve sworn was worded to imply it was what was what GP linked, but either I misread or it was edited, so changed my reply accordingly.

Also missing from this tutorial - one really needs to execute a sfence.vma instruction after writing satp to sync CPU pipelines to new memory management state (otherwise code that happily runs on a simulator will fail on a real-world deeply pipelined CPU)

Patience, my friend. We're not quite there yet with this tutorial. We don't need sfence.vma for what I've covered here. Plus, there are about four ways to use the sfence.vma instruction (whether or not rs1 is zero or not and if rs2 is zero or not). I'd like to have some context behind each one of these four cases, but I can't do that in the OS's current state.

Can someone explain some soup to nuts applications that would benefiet greatly from this type of architecture? Why is RISC-V becoming so popular right now?

RISC-V is popular because it's a clean RISC design (unlike IAxx) which is not controlled by any for-profit company (unlike Arm). That means anybody can use it, enhance it, or fix any not-yet-identified bugs in it without paying license fees.

Thanks, I gathered as much about RISCV, but my question was maybe more basic, kind of eli5 of why would someone would use RISC for an application over x86 or ARM, what level of task requires or benefits from a reduced instruction set chip. I noticed alot of video games have used it.

If you're "using RISC", that means that you're producing something that involves a processor. If you're just making software you just need to have it compile with common compilers and have the relevant libraries available on your target platform (ok, I'm over-simplifying), so you don't "use processoer X over Y".

When you do use hardware, you're interested in things like power budget and price for comparable performance. RISC-V is now reaching competitiveness in some cases, and companies/people will now start choosing to use it on the merits. If, there is, there's an OS available and a bunch of supporting tools and libraries.

If you're designing a new computer platform, do you care about power (i.e. does it need to run on batteries)? If so you probably want a RISC architecture rather than CISC (although the Intel Atom tries hard to be a low-power CISC machine). That leaves you with two choices: Arm (used in all smartphones, some Chromebooks, and Raspberry Pi) or RISC-V. Arm is more mature and there's a lot more software available, but it's not an open source architecture.

There are recently some guides about how to build an operating system in Rust. Rust is innovative and great, but also brings complex new ideas. Can it slow down learning and implementing because the developer have to dedicate too much time to the language itself?

I believe that building a full blown OS requires dedicating so much time that this overhead due to the language itself will not be significant. On the other hand, without the sufficient experience with the language itself, it's easy to run into problems that will consume a significant amount of time

sigh - the PTE A&D bits cause traps they way they do so that software can implement them (if it needs them, and not if it doesn't), it's an old trick and very much a RISC thing - not wanting to burden the hardware with something that software can do

what does A&D stand for?

A = Accessed (read from or written to [a load or a store]), D = Dirty (written to only [a store only])

ty!

accessed and dirty (where a page has been accessed and whether it has been changed)

You need to know "dirty" to know whether a page needs to be written back to a swap file (or needs to be duplicated in lazy copying cases), you may want to know "accessed" if you want to do the accounting to push out less often used pages when memory gets short

thanks!

There's no reason to sigh, it is a pretty goofy thing to both specify the bits as separate from the permissions, and check them, but not fill them out.

Going through RISCS I've implemented MMU code for:

MIPS - Has what they call a Dirty bit, but no separate RO bit, the dirty bit is really the ~RO bit.

SH* - See MIPS (lol, that could be their tagline)

Sparc - Doesn't really specify an MMU, but the "Reference MMU" does specify that the Modified bit (AKA the Dirty bit) is filled in by the MMU

PowerPC - Referenced and Changed bits in the PTEs are updated by the MMU.

ARM - Doesn't specify any A&D like construct.

Am I missing any? I can't think of an arch off the top of my head that has separate A&D from RWX, and doesn't have the MMU fill them in for you. Well other than RISC-V, lol.

Vax's had modified bits, 68030s had both (dirty managed in software), 80x896s have both [an 'unnamed' risc architecture (I worked on) had both, managed in software]

The big advantage of handling this stuff in software is that any hardware doing this has to go through the system caches which is just really messy - better to use the existing coherent paths already provided and provide hardware support so you don't have to do this often

ARM (both 32-bit and 64-bit) does have an access bit, which, like RISC-V, can be either hardware managed or treated as an extra 'valid' bit.

RISC-V _and_ Rust? Straight to #1!

Haha I see what you did there.

Too many buzzwords! Hype field at critical! Implosion imminent!

I like rust and more architectures are sorely needed, but this seems... Calculated

it should also be targetted at deep learning 3D printed IoT using 5G to connect to an autonomous vehicle

Reply on news.ycombinator.com