OctoX is a radical Rust implementation of a very old OS for RISC-V

Not only are various editions of Version 6 UNIX, often known as V6 for short, still being maintained – but new ones continue to appear. Version 6 UNIX arrived in 1975, and it was the first version of the new OS to see much widespread use outside of AT&T and a handful of research institutions. It's the OS documented in the …

[Red Ted]

You are not expected to understand this.

Having looked at the section of code, my opinion is that it's not too awful.

Certainly not for task switching code whose job it is to context switch and therefore directly manipulate the underlying system state so as different code executes when you return, from the one that was running when the function was called.

[Chris Gray 1]

Re: You are not expected to understand this.

Agreed. Its cool, but not terrible. *Of course* the process ending call does not return. Even though its existence as a standard C call makes it look like it should if you don't actually read it.

I did similar things a couple of times for thread termination. It was a bit of a thrill to watch them work, I will admit!

When I first looked into an old Linux kernel (writing code for hardware to plug into a bus and work shared-memory-wise with the kernel), I was definitely disturbed to see that it included the same device header file(s) twice. Its been years, but I think the first time was to add the devices to the device tables(s), and the second time was to compile the actual driver code. Doing it that way meant that it was all in one file, so was less likely to get broken, but it sure broke expectations! Dunno if it still works that way.

[ChoHag]

Re: You are not expected to understand this.

Implementing an entire library in a single .h file seems to be getting popular.

It's a bit weird but it can be done well and when it is it's quite convenient, although gcc and clang, at least, refuse to treat a file ending in .h as C source so some trivial shenanigans are required.

[david 12]

Re: You are not expected to understand this.

Implementing an entire library in a single .h file seems to be getting popular.

Because there are religious objections to doing it the other way, (including a .c file as an include file), and the use of .inc is not only evil, it's strange as well.

[Arthur the cat]

Silly comments

From ageing memory, so not guaranteed to be 100% correct:

In version 6 the tty driver had one line (setting device register bits IIRC) commented with "Eat flaming death, fascist pigs!". In version 6+(*) this had been changed to "Eat soggy cardboard, pinko wimps!".

(*) 6+ was the update which meant that the C compiler could handle identical structure field names at different byte offsets in different structures. If you've ever wondered why all system structures have unique prefixes on all the field names (eg st_uid, st_gid in stat(2)), it was because cc originally handled field names in much the same way as BCPL, as manifest constants equal to byte offsets from the beginning of the structure.

[Steve Graham]

Re: Silly comments

Pertinent to Silly Comments but not v6: one of my colleagues prefaced a 60-character regular expression with the comment "Work this one out, you bastard."

[ChoHag]

Re: Silly comments

> unique prefixes on all the field names ... because cc originally handled field names in much the same way as BCPL

"The more you know"

Shame how with computers the things you get to know are all so bloody useless. I sure do know a lot of them though.

[breakfast]

The real hero of this piece

Congratulations to Cliff Biffle on having exactly the kind of name I come up with when I'm GMing and the players ask the random shopkeeper what his name is so I have to come up with something on the spot. Big "background NPC who is about to be adopted by the party" energy.

[fromxyzzy]

Re: The real hero of this piece

Swear that's the name of a Bloom County character.

[Liam Proven]

Re: The real hero of this piece

[Author here]

> Congratulations to Cliff Biffle on having exactly the kind of name I come up with

It is a name to conjure with all right, and I like that he plays on it in his own domain name:

http://cliffle.com/

The odd thing is that I found that blog post of his while researching a completely different story... Which may yet appear soon.

[Anonymous Coward]

But how big is the Rust implementation.....

.....compared with other versions in other languages?

I've just written a C version of the toy "quickreplace" from an early Chapter of "Programming Rust" by Bill Blandy, et al.

Executable sizes (static compile):

- Rust: 26 megabytes

- C: 1.7 Megabytes

Dynamic linked sizes:

- Rust: not possible!

- C: 30 kilobytes

All this using Fedora 38, gcc 13.1, Rust 1.71

[Daniel Pfeiffer]

Re: But how <s>big</s>small is the Rust implementation.....

Have you tried this to shrink your binary by a big factor?

<pre>

[profile.release]

opt-level = 3 # Max

lto = true # Enable link-time optimization

codegen-units = 1 # Reduce number of codegen units to increase optimizations

strip = true # Strip symbols from binary

</pre>

How about either of these: --crate-type=dylib, #![crate_type = "dylib"]

[Anonymous Coward]

Gotta be careful about the Lions code copyright...

Is SCO truly dead, or is the Unix magic IP permeating your mind?

[IGnatius T Foobar !]

C will never be replaced.

The world is littered with the bones of languages that tried to replace C. Many have come and gone. Many will continue to come and go. C is the perennial king for a reason. Long live the king.

[david 12]

Re: C will never be replaced.

“I don’t know what the language of the year 2000 will look like, but I know it will be called Fortran.” (1982)

It's still called c, but it doesn't look like K&R c, and the compilers have large adopted the design decisions of Wirth Pascal.

The litter included the bones of c. What continues is partly compatible, and has the original name.

[abend0c4]

Odd definition of 100% Rust...

It may be true that 100% of the code is written in Rust syntax.

However, some of that code consists of statements like:

#[inline]

pub unsafe fn write(bits: usize) {

asm!("csrw satp, {}", in(reg) bits);

}

which is simply a transliterated combination of machine code and knowledge of compiler behaviour. It's about as high-level as PEEK() and POKE().

True, it's only a small amount of the overall code and the overall achievement is quite impressive, but it does seem a little over-zealous.

[LionelB]

Re: Odd definition of 100% Rust...

There will inevitably be cases where "unsafe" code is unavoidable (or desirable) - especially if you're writing an OS. The thing about Rust is that it obliges you to explicitly declare sections of code as unsafe, making for better transparency.

Rust also has several features which make it easier and more natural to code safely without incurring performance penalties, where the corresponding C paradigms are inherently unsafe (e.g., on gounds of NULL pointer dereferencing, array bounds overuns, data races, non-portability, etc.) The compiler does a lot more of the heavy lifting in Rust, and performance may sometimes by improved over C, as the language gives the compiler more guarantees than C does, which it may exploit for aggressive optimisation.

There's an excellent article about this here.

(Disclaimer: I code a lot in C and not at all in Rust.)

[spireite]

Caldera

. . A smoking crater in history, which seems appropriate

[Timochka]

I greatly sympathise with the original comment. I wrote my own small multithreading OS in Rust (for AVR microcontrollers, because essentially I hate myself), and even though I wrote the context switch/process creation code myself, I also don't understand it... I touch those files with dread. Once you're modifying the stack/SP manually, the brain fairly rapidly decides to just stop trying to work out what it's just done and leave it to faith, in my experience.