Linked by Thom Holwerda on Sun 26th May 2013 18:48 UTC
OSNews, Generic OSes "A tiny 32 bit kernel written in Rust. I was inspired to download Rust and try to do this after seeing zero.rs - a stub that lets Rust programs run almost freestanding. It paints the screen bright red and then hangs. That's it."
Thread beginning with comment 562992
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: I clicked it, I liked it
by Brendan on Tue 28th May 2013 04:53 UTC in reply to "RE[4]: I clicked it, I liked it"
Brendan
Member since:
2005-11-16

Hi,

That can be considered as part of the boot loading process, just clearing the screen before calling the real OS, like any other boot loader.

Do you understand Assembly?!


Yes. See those labels (abort, memcmp, memcpy, etc)? They're unimplemented run-time support that Rust probably needs to compile. If the Rust code wasn't trivial I'd expect that these would need to be implemented.

While we're on the subject of "if the Rust code wasn't trivial" and "real OS"..

For a real OS you'd want to setup the video mode properly, which would require assembly. You'd also need to get a memory map from the BIOS, which would require assembly. You'd need to remap the PIC chips, which would require assembly. You'd need to enable A20, which would require assembly. You'd need to scan physical memory for things (e.g. ACPI tables, etc), which would require assembly.

Then; you'd start the other CPUs, which would require assembly. Next comes memory management and scheduling, which typically involves atomic operations and/or lock-free/block-free algorithms, which would require assembly. Then there's the task switching code, which would require assembly. Of course there's also exception handling, IRQ handling, etc; which would require assembly.

Can you see a pattern here? If the "kernel" wasn't a trivial joke, you'd find Rust being used for glue and not being used for anything that's actually important; especially once you start micro-benchmarking and trying to get performance/scalability close to other OSs.

So; what does this trivial example, with its ~20 lines of Rust and its ~100 lines of assembly, actually show? It shows that assembly is so awesome that it can make Rust "sort of usable". ;)

- Brendan

Reply Parent Score: 3

Neolander Member since:
2010-03-08

For a real OS you'd want to setup the video mode properly, which would require assembly. You'd also need to get a memory map from the BIOS, which would require assembly. You'd need to remap the PIC chips, which would require assembly. You'd need to enable A20, which would require assembly. You'd need to scan physical memory for things (e.g. ACPI tables, etc), which would require assembly.

Then; you'd start the other CPUs, which would require assembly. Next comes memory management and scheduling, which typically involves atomic operations and/or lock-free/block-free algorithms, which would require assembly. Then there's the task switching code, which would require assembly. Of course there's also exception handling, IRQ handling, etc; which would require assembly.

Can you see a pattern here? If the "kernel" wasn't a trivial joke, you'd find Rust being used for glue and not being used for anything that's actually important; especially once you start micro-benchmarking and trying to get performance/scalability close to other OSs.

I disagree with that conclusion. What OSs mainly written in C or C++ show is that it is possible to write most of an OS' logic in another programming language, and only keep Assembly for the few operations that actually access hardware directly. Sure, these Assembly parts are vital, but so is the logic code: it is where all the interesting stuff is decided, and what differentiates one OS project from another one.

Of course, we can argue that some languages are better-suited for OS development than others. As an example, any language with heavy runtime requirements, or nondeterministic performance due to garbage collection, is probably a very poor fit unless such mechanisms are optional as in C++.

That may be the case or not in Rust, but you have not actually proven this point so far. In fact, the author of this code hasn't either, he has only shown that Rust code which does something trivial like moving memory around may have little actual runtime requirements, which is already something but not enough to showcase it as a good language for OSdeving.

Also, the fact that he has to define abort, memcmp, memcpy, malloc and free for the code to compile worries me. It means that some part of the OS binary somewhere requires these primitives, and will cause a random crash if it ever attempts to run them. But perhaps that's a result of someone not properly reading his compiler's manual...

So in summary, I agree with you regarding the feeling that this code does little to prove Rust's suitability for OS development, but I disagree with the arguments you use to prove your point.

Edited 2013-05-28 06:28 UTC

Reply Parent Score: 2

moondevil Member since:
2005-07-08

I disagree with that conclusion. What OSs mainly written in C or C++ show is that it is possible to write most of an OS' logic in another programming language, and only keep Assembly for the few operations that actually access hardware directly. Sure, these Assembly parts are vital, but so is the logic code: it is where all the interesting stuff is decided, and what differentiates one OS project from another one.


And Object Pascal, Modula-2, Ada, ...

Of course, we can argue that some languages are better-suited for OS development than others. As an example, any language with heavy runtime requirements, or nondeterministic performance due to garbage collection, is probably a very poor fit unless such mechanisms are optional as in C++.


10 years ago no one would believe you could do something like Unreal in JavaScript.

I think it is also a question how much the industry is willing to invest in such topics.

Also, the fact that he has to define abort, memcmp, memcpy, malloc and free for the code to compile worries me. It means that some part of the OS binary somewhere requires these primitives, and will cause a random crash if it ever attempts to run them. But perhaps that's a result of someone not properly reading his compiler's manual...


I think he just had them as stubs, because it was just a proof of concept. Of course in a real kernel similar functions need to be defined.

Reply Parent Score: 2

moondevil Member since:
2005-07-08

Can you see a pattern here? If the "kernel" wasn't a trivial joke, you'd find Rust being used for glue and not being used for anything that's actually important; especially once you start micro-benchmarking and trying to get performance/scalability close to other OSs.


You mean like C?

Last time I checked you are doing exactly the same, glue between Assembly code that interacts with the hardware.

So; what does this trivial example, with its ~20 lines of Rust and its ~100 lines of assembly, actually show? It shows that assembly is so awesome that it can make Rust "sort of usable". ;)


It shows that Rust also provides a very thin runtime requirements and with a bit of Assembly it is possible to produce executables that execute directly on hardware.

This is no different from many systems that execute directly on embedded hardware without an underlying OS, for example.

It can also be considered the starting point of any OS, if the next Linus now would pick this example and developed it further.

Reply Parent Score: 2