jahboater
Posts: 4678
Joined: Wed Feb 04, 2015 6:38 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sat Aug 10, 2019 1:44 pm

Heater wrote:
Sat Aug 10, 2019 12:58 pm
So now you can program in something C like. Soon you find that it's very tedious that your programs crash at random, have weird responses to odd input and are full of security vulnerabilities.
I must say that I don't have all these problems. Nowadays I write important code to be strictly standard conforming, validated both statically and at run time, and with no undefined behavior. Of course code has bugs, but its rarely this sort of random behavior that afflicts your code.

So no, I don't find it tedious.

To be fair, I am retired now and don't have salesmen worrying about "time to market" ....

I do like having a strong well defined standard, slowly evolved, with extremely wide usage, knowing that if I follow it to the letter, I am unlikely to have "random" problems.

Heater
Posts: 13299
Joined: Tue Jul 17, 2012 3:02 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sat Aug 10, 2019 5:20 pm

jahboater,
I must say that I don't have all these problems.
Ah but you do have all those problems. As you go on to say in your very next sentence:
I write important code to be strictly standard conforming, validated both statically and at run time, and with no undefined behavior.
By that I gather that you do the following:

1) Have read, fully understood and remember all details of the standards document for C/C++.

2) Have read, fully understood and remember all the details of the implementation of your C/C++ compiler(s). Especially all the definitions of what is undefined behavior in 1). You do this for all the platforms your code may run on, now and in the future.

3) Use some static analysis tool on your source code to find typical problems and potentially buggy code.

4) You have tests in place for all your functions/classes. You ensure you get 100% code coverage when running such tests. You ensure you are testing for all edge cases.

5) You are of course using tools like Valgrind and the various sanitizers at run time to check for memory leaks, out of bounds access, use before initialization etc, etc.

Good. That is what projects creating important code do. Admittedly I can be very slack on any (or all) of those activities for my personal projects.
So no, I don't find it tedious.
You don't, I do. That is all boring "work". It's not always easy either.
I do like having a strong well defined standard, slowly evolved, with extremely wide usage, knowing that if I follow it to the letter, I am unlikely to have "random" problems.
I can only totally agree with you there. Which is why we love C and even C++ so much.

Except for the part about "follow it to the letter" which I claim is impossible. A claim born out of the ever increasing evidence of bugs and security vulnerabilities we read about every day.

And of course "unlikely" there is saying "still have problems occasionally".

My question is:

Given that strictly adhering to the practices in 1) to 5) above is work that to a large part can be automated by your compiler why not have a compiler do that?

Going through all those motions and expending time and effort on all those checks is like programming without an assembler, sure you can calculate all those jump address offsets by hand but it's tedious work and it's error prone.

I do appreciate your argument that an established language with a good accepted standard and wide usage is desirable. But rigidly sticking to that would be a Catch 22 situation, we could never move on to something better because it's newer than the old thing we have.

I have no idea yet if Rust is the answer to all the complaints I have had about C/C++ for nearly four decades (See 1) to 5) above) but I am very happy to see that someone is stepping up to the plate to tackle the issues. Rust may well be new and hence suspect but it has some reassurances in that respect: It makes use of the well used and well tested LLVM compiler and no doubt soon GCC. Because of it's inherent safety checking it kind of future proofs itself against any changes in the future. It does already have a pretty huge user base. The Rust project has promised no breaking changes in the future, like C/C++, unlike Python :)

All of this convinces me Rust is worth a look at. Despite the fact that looking into a language is not something I get any fun out of unless it offers a compelling solution or two for me.

To be sure I'm not about to claim that Rust is a silver bullet that will rid the world of bugs. But I see no reason not to have the compiler do the work for us and stamp out a large classes of bugs.

jahboater
Posts: 4678
Joined: Wed Feb 04, 2015 6:38 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sat Aug 10, 2019 8:13 pm

Heater wrote:
Sat Aug 10, 2019 5:20 pm
1) Have read, fully understood and remember all details of the standards document for C/C++.
Not C++ !!!!!!! C only. The C standard is far far smaller, easy to read, and actually quite helpful.
Also, since many library functions are now included in the C standard, I usually refer to that rather than the man page because it should be definitive.
Heater wrote:
Sat Aug 10, 2019 5:20 pm
behavoir
2) Have read, fully understood and remember all the details of the implementation of your C/C++ compiler(s).
No, its supposed to do what the standard says, if not its a bug. And in this respect I certainly wouldn't code differently for each compiler. Once you start doing that you know you are writing crap code, or your compiler is crap. That's not what a truly portable language like C is about. Each compiler does have to document its choices for "implementation defined" behavior, and I have read that for GCC (its short but boring).
Heater wrote:
Sat Aug 10, 2019 5:20 pm
Especially all the definitions of what is undefined behavior in 1).
Definitely not. Its nothing to do with the compiler (that would be implementation defined behavior).
All the possible causes for undefined behavior are listed in the standard, in great detail. Most are common sense of course.
Heater wrote:
Sat Aug 10, 2019 5:20 pm
You do his for all the platforms your code may run on, now and in the future.
No, that's why we have a stable and future proof ISO standard. Furthermore the compiler is very good at warning about things like this (say loss of precision on some platforms but not others). I saw recently this warning: -Wcast-align which warns of alignment problems in bad code. Obviously for some platforms like x86 it never matters and this warning would not be raised. -Wcast-align=strict on the other hand, warns of potential problems regardless, even if the current target doesn't care. Great for future portability.
Heater wrote:
Sat Aug 10, 2019 5:20 pm
4) You have tests in place for all your functions/classes. You ensure you get 100% code coverage when running such tests. You ensure you are testing for all edge cases.
That's why we have test coverage generation tools like tcov. 100% coverage is always the target, and its relatively easy for the normal code, but extending it to cover fatal error handling for instance is difficult because it stops the test. You then have to have lots of short tests, one for each error which is annoying (but tcov does handle it). The 100% coverage test suite should also be completed with valgrind too of course.
Heater wrote:
Sat Aug 10, 2019 5:20 pm
5) You are of course using tools like Valgrind and the various sanitizers at run time to check for memory leaks, out of bounds access, use before initialization etc, etc.
Of course, after every significant source code change. Or any change that affects a critical section.
Heater wrote:
Sat Aug 10, 2019 5:20 pm
A claim born out of the ever increasing evidence of bugs and security vulnerabilities we read about every day.
The thing is, you talk of "myriads" of bugs in the Linux kernel, and yet I have been using Linux for decades and never see them. I find Linux very reliable. Ditto these "constant" random problems with C, which I rarely see (maybe a segfault once or twice a year (if that), and then fixable within minutes).
Heater wrote:
Sat Aug 10, 2019 5:20 pm
I do appreciate your argument that an established language with a good accepted standard and wide usage is desirable. But rigidly sticking to that would be a Catch 22 situation, we could never move on to something better because it's newer than the old thing we have.
I'm not against progress, and I may take another look at rust one day. But coding is always hard to get right, without additionally having to worry about the growing pains of a new language.
Heater wrote:
Sat Aug 10, 2019 5:20 pm
My question is:

Given that strictly adhering to the practices in 1) to 5) above is work that to a large part can be automated by your compiler why not have a compiler do that?
No problem with that at all. Compilers don't get tired and bored and miss things!
Run time validation is a different matter. While great, and tools like valgrind etc should be used as much as possible, it can also be very dumb. In "for( int i = 0; i < 100; i += 2 )" whats the point in checking the += 2 addition for overflow?
I have a text editor. The line numbers used to be held in a type "int" with suitable overflow checks where needed. Later I changed it to int64_t and removed all the checks because integer overflow was impossible, making the code cleaner, simpler, and faster. A compiler could not know that, and would blindly add pointless checks (like -ftrapv does in C).

Heater
Posts: 13299
Joined: Tue Jul 17, 2012 3:02 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sun Aug 11, 2019 8:07 pm

jahboater,

I think we are largely in agreement there. Perhaps with a differing view as to what to do about the problems, or even accepting that they are problems...
Not C++ !!!!!!! C only.
Amen brother. As I have often said, I don't believe there is even one human that knows and understands all the details of the C++ spec, let alone how all those parts work together. I have seen even Stroustrup falter at understanding why a ten line function did not work as one might expect.
No, its supposed to do what the standard says, if not its a bug
But there in lies the problem. The standard does not say. In fact if you take the standard at face value everything is undefined behavior!

For example a simple function signature like so:

Code: Select all

char* myFunc (char* s);
Now tell me:

1) Is that parameter a pointer to a single character (Which is what it looks like to be honest) ?

2) Is that character a signed or unsigned value?

3) Or is it a pointer to a bunch of consecutive characters?

4) Is that bunch of consecutive characters C string with a null termination?

5) Or is it just an array of bytes?

6) Or is it a null pointer?

7) Or is it some random pointer, perhaps from somewhere uninitialized?

8) Is this function going to modify that bunch of characters?

9) Is that bunch of characters somewhere on the stack or on the heap?

10) If the latter, is this function supposed to free() that bunch of characters or leave it to the caller?

11) What happens if this function does a realloc on the memory pointed at by that pointer? How many other parts of the code have that old pointer value and will get broken?

12) If it's an array of characters how long is it?

13) Don't get me started on the return value.

In one line of code we have a ton of undefined stuff. Yes I know, using modern day types like uint8_t helps, and yes use of const helps, but basically you need to be checking the documentation at every step here to be sure what is going on.
The thing is, you talk of "myriads" of bugs in the Linux kernel, and yet I have been using Linux for decades and never see them.
I have also been using Linux since 1996 and I am constantly amazed that I don't see them either. That does not mean they are not there. There have been plenty of security issues raised on the kernel. There is a lot of people working to preemptively find all these undefined behaviors before the bad guys do:

Making C Less Dangerous in the Linux kernel: https://www.youtube.com/watch?v=FY9SbqTO5GQ&t=2361s
Does making the kernel harder make making the kernel harder?: https://www.youtube.com/watch?v=Gtjy7pWjW9M

It's much the same situation in a any large code base. Even the small ones I have worked on.
I'm not against progress, and I may take another look at rust one day. But coding is always hard to get right, without additionally having to worry about the growing pains of a new language.
I'm with you there. It's not a trivial matter to move from an old thing that you know all the problems with to a new thing that may have a bunch other problems you don't know about.
for( int i = 0; i < 100; i += 2 )" whats the point in checking the += 2 addition for overflow?
Quite so. Sometimes the possibility of overflow can be deduced from the source code at compile time.

Languages like Ada and Rust try to constrain the syntax and semantics to make it even more possible, such that actual run time checks are not needed.

User avatar
PeterO
Posts: 5005
Joined: Sun Jul 22, 2012 4:14 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sun Aug 11, 2019 10:15 pm

Heater wrote:
Sun Aug 11, 2019 8:07 pm
In one line of code we have a ton of undefined stuff.
You have become a broken record !
It really is hard to understand why you keep on about this over and over and over again.

You've taken one line of code in isolation and extrapolated to produce a list of irrelevant points.

Why irrelevant ? Because you've taken the line in isolation. Experienced programmers look beyond an isolated line and use things such as
the context, the variable names, the variables used in calls, how the parameters are used within the function, and maybe even comments to understand the code so they can disregard all those things that you claim are "Undefined behaviour".

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

LdB
Posts: 1231
Joined: Wed Dec 07, 2016 2:29 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Mon Aug 12, 2019 1:57 am

As I commented before I had a play for a couple of months with Rust and dropped it like many others because the language still has some structural issues which are in the "to be implemented list". There are definite good stuff in the language but there is some bad and some dam ugly. A quick walk thru the RFC's will give you an idea of some of the standing problems.

It is an easy and fun language to learn and I would certainly encourage people to have a play and make your mind up. However for my 2 cents it's nothing like a C/C++ beater and realistically I can do more with Go if I really want to get off C/C++. If it continues to develop I might have another look in a couple of years time but I fear it will go the way of other languages and carve out a space to some niche audience. However there are big companies showing interest (even MS: https://msrc-blog.microsoft.com/2019/07 ... ogramming/) so the jury is out.

Heater
Posts: 13299
Joined: Tue Jul 17, 2012 3:02 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Mon Aug 12, 2019 7:48 am

LdB,
...dropped it like many others because the language still has some structural issues which are in the "to be implemented list"....
If we were discussing a car or a house or a bridge it would be interesting to know what "structural issues" you have in mind there. What exactly is Rust lacking, or done wrong, in your opinion?

Admittedly I know nothing much of Rust yet having only started to scratch the surface. So far I don't see that it is lacking anything in comparison to C. With C you can build pretty much anything, a Linux kernel for example, one of the biggest projects in the world. There is already a micro-kernel and usable operating system created in Rust. As such it looks like it covers more than enough ground to do anything I will ever want to do with a programming language.

I have heard C++ people pointing out that C++ has more sophisticated generics/templates whatever. Also that Rust has no "class" and is not object oriented in the C++ way. I have heard Haskell people pointing out that it's not "functional" enough for their liking.

Well, frankly, I have never understood why I might need all that...

What I do need is something that compiles down to small fast binaries with a minimal, preferably no, run time requirements. Also deterministic timing is often required.

LdB
Posts: 1231
Joined: Wed Dec 07, 2016 2:29 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Mon Aug 12, 2019 1:18 pm

Heater wrote:
Mon Aug 12, 2019 7:48 am
What I do need is something that compiles down to small fast binaries with a minimal, preferably no, run time requirements.
That statement worries me ... make sure you read the section on linkage with Rust especially if you start including C/C++ codes.
https://doc.rust-lang.org/reference/linkage.html

Even rust itself somewhat clarifies that
https://prev.rust-lang.org/en-US/faq.html
Does Rust have a runtime?
Not in the typical sense used by languages such as Java, but parts of the Rust standard library can be considered a “runtime”, providing a heap, backtraces, unwinding, and stack guards. There is a small amount of initialization code that runs before the user’s main function. The Rust standard library additionally links to the C standard library, which does similar runtime initialization. Rust code can be compiled without the standard library, in which case the runtime is roughly equivalent to C’s.
I think what you are probably thinking of is called "Freestanding Rust" which is what I was initially playing with. I was playing with code from
the e-book Writing an OS in Rust (Second Edition) which has now been taken to web (https://hardware-interrupts--blog-os.ne ... st-binary/).

So part of me answering your question depends on how you define the sort of rust you are talking about.

I am also careful I don't want to discourage you because you seem to like the language try it. The language is evolving and there are RFC's suggestions in for some of the problems I encountered. It is worth the effort to try the language out, it wasn't wasted time IMHO.

If you asked me what I struggled with most with Rust it was what was supposed to be a feature the ownership concept. In your O/S event callbacks, multicore implementation and context switches and forced slow group iterations. A reasonable explaining of the problems you will encounter is given here (https://medium.com/@GolDDranks/things-r ... 96a3c740a5)

Heater
Posts: 13299
Joined: Tue Jul 17, 2012 3:02 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Mon Aug 12, 2019 7:50 pm

LdB,

Thanks for the links. I'd come across most of that already but the blog about booting into Rust on a PC is new and a fascinating read.

On the contrary, you have encouraged me to look deeper. Having seen that I can compile simple functions with #![no_std] and end up seeing much the same code generated as I'd expect from C in "objdump -d" I was sure that by hook or by crook I could use Rust much as I do C/C++ in small embedded systems.

There is the issue of missing features with #![no_std] but that's surely not much different than living without printf or the C++ standard library. Something we have been doing since forever.

If need be it looks like one can get to use collections and such as well if one can provide an allocator and has memory enough.

The Embedded Rust Book has a good discussion of all this: https://rust-embedded.github.io/book/intro/index.html

I can well imagine there are limitations of the borrow checker, it all sounds like an impossible task to me. But it also looks like progress is being made to make that more useful.

All in all, I'm all set to go rusty.

Thanks.

User avatar
Gavinmc42
Posts: 3730
Joined: Wed Aug 28, 2013 3:31 am

Re: Announce: RusPiRo - a kernel the Rust way ;)

Tue Aug 13, 2019 12:27 am

Ordered another Pi4 yesterday, my usual supplier had 2GB in stock.
I can use that for development and the 1GB for testing code.

Graphics might be a bit hard at this early stage, but then I thought this would be useful for RISC-V based bots.
There is new K210 based things coming out all the time.
https://m5stack.com/blogs/news/introduc ... a-m5stickv

If it is ok with you guys stop arguing about Rust/C etc and let Schnoogle get Rusty.
Don't want to talk about HAL, Hardware Abstraction Layers, but how to run on Pi or RISC-V or....
This could be the Rust version of Micropython but with AI intergrated?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 1231
Joined: Wed Dec 07, 2016 2:29 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Tue Aug 13, 2019 12:45 am

It's a thread about rust on the Pi and you want us not to discus rust but discuss other stuff :-)

User avatar
Gavinmc42
Posts: 3730
Joined: Wed Aug 28, 2013 3:31 am

Re: Announce: RusPiRo - a kernel the Rust way ;)

Tue Aug 13, 2019 1:01 am

It's a thread about rust on the Pi and you want us not to discus rust but discuss other stuff
Yep, sorry another one of my brain dumps.
Getting too far ahead, where Rusty robots take over the world from the old C ones.
Just ignore me, most people do ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 1231
Joined: Wed Dec 07, 2016 2:29 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Tue Aug 13, 2019 5:20 am

No you add to the forum discussion ... it just gave me a morning smile and please don't read anymore into than that.

Anyhow might have a more interesting thread soon I have made good progress with VC6.

User avatar
Gavinmc42
Posts: 3730
Joined: Wed Aug 28, 2013 3:31 am

Re: Announce: RusPiRo - a kernel the Rust way ;)

Tue Aug 13, 2019 6:20 am

Maybe I should make some combat robots and let the C++ ones fight the Rust ones.
Go against Free Pascal, see who makes the final.
Time for some Darwinian language evolution?
I have made good progress with VC6.
Baremetal 3D on VC6 :D
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Schnoogle
Posts: 71
Joined: Sun Feb 11, 2018 4:47 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Tue Aug 13, 2019 8:34 am

Hi there,
it's great to see the discussion around Rust and C/C++ and the different advantages and disadvantages

Let me add my 2 cents to the story :)

I'm not the one who played with C/C++ over decades but I find it a bit "annoying/weird" (sorry for the hard words ;) ) that - especially when it comes to programming languages - we as developers tend to hold on to the known ancient things and "fear" or complain about the new stuff over and over to somehow convince our self, that we did not wrong in the past and should continue the good old things...

I'm far away from even thinking Rust is the holy grail (or any other language) but I find many of the concepts, ideas and "solutions" to some problems quite interesting and started to think I really should give it a try.

Comparing every new language with C/C++ all the time especially the new ones feels a bit unfair. I mean Rust is young and has not evolved over decades already and to be honest even C++ is still evolving and new items are added to the specification. I mean, it's all about technical evolution. No one would stand up and say that we should stop inventing new cars or autonomous driving. Sure they might not be 100% sophisticated at first and the first versions might have lacks in their concepts or bugs in their design. But still no one would argue and try to keep the good old manual gear cars from the sixties around just because they always did what they supposed to do - moving people from A to B - and they did well.

I'll take Rust as an opportunity to break with some old paradigms and to introduce new features like the crates registry and the very easy to maintain and to use dependencies - a module system never arrived at C or C++ in decades - that supports us as developers to build better software may be in less time, but for sure with better quality.

I've read some of the concerns for Rust and what special constructs and possibilities are available in C or C++ but not in Rust. However, I always ask myself there: why should they be there (1:1 or close to it) and what is the need for them or would one do it completely different in a functional / Rust way and therefor would not need the C / C++ construct 1:1 in Rust ? I mean, there would never be the need for yet another language if we always try to do the exact same things like we did in C/C++. If you would like to drive a car by your own you would never buy a autonomous self driving car and start complaining that there is no steering wheel and the like you would like to use - no, you would get a usual car. Everyone is free to stay with the usual car, but I like to see how far I get with the new concepts and wherever possible like to be part of the community that shapes the new concepts and their implementation.

My first bare metal project on Raspberry Pi was with C, than with C++ and now with Rust and I started also skeptical about Rust but I kinda like it now very much and I'm curious to see where it may lead to :)

So - hands on - and lets gather more experience and really try to get Rust to it's limits while building a bare metal kernel for Raspberry Pi that will drive a robot in the near or far feature :D

I the meantime I continued working on my RusPiRo stuff and created a bundle crate: https://crates.io/crates/ruspiro-sdk That aims to give a jump start into building Raspberry Pi kernels the "Rust" way ;) with the typical list of ruspiro crates useful for minimal kernel stuff. The list of RusPiRo crates is constantly growing and here and there some bugs are fixed ;)

Schnoogle
Posts: 71
Joined: Sun Feb 11, 2018 4:47 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Wed Sep 04, 2019 2:28 pm

Hmm, well - did I just killed the discussions ? I'm sorry for that :oops: ...

However, I thought it might make sense to come up with a kind of a tutorial series to get things started when first trying bare metal on RPi with Rust :) ....

So here we go:
https://github.com/RusPiRo/ruspiro-tutorials

It's just one simple one in the tutorial repo but more are to come :) ...

BR,
Schnoogle

User avatar
Gavinmc42
Posts: 3730
Joined: Wed Aug 28, 2013 3:31 am

Re: Announce: RusPiRo - a kernel the Rust way ;)

Wed Sep 04, 2019 11:58 pm

Hmm, well - did I just killed the discussions
I think most of us might be distracted by all the new stuff that just works on Pi4 :D
I have been doing lots of OpenGL learning and testing in various languages.

What I have not found is a Rust library for OpenGL.
Have you come across one in your travels?
Something suitable for baremetal without relying on massive dependanices.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Schnoogle
Posts: 71
Joined: Sun Feb 11, 2018 4:47 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Fri Sep 06, 2019 11:58 am

Hi, yup, the RPi 4 really looks promising, hope I will also get one until end of the year :)

My self did not came across any OpenGL library, but this one might be worth a read:
https://bheisler.github.io/post/state-of-gpgpu-in-rust/

But I don’t think any is available for bare metal or no_std environments, but this is said without any serious research ;)

Regards
Schnoogle

User avatar
Gavinmc42
Posts: 3730
Joined: Wed Aug 28, 2013 3:31 am

Re: Announce: RusPiRo - a kernel the Rust way ;)

Fri Sep 06, 2019 12:15 pm

Thanks for the link, I had forgotten that one.
I guess Rust - OpenCL needs to be re looked at too now ;)

Been trying to Grok GLSL and the shader stuff.
If the Mesa GLSL compiler can be converted to Rust, could it be used to make a GLSL based GUI?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

bzt
Posts: 393
Joined: Sat Oct 14, 2017 9:57 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Fri Sep 06, 2019 12:24 pm

Hi,

Yes, I agree with jahboater, C is very very different to C++, we should not mention them on the same page. I personally prefer C (not C++) for bare metal development, but it is really good to see that we have lot more programming languages to choose from!

1) C++, with rst's Circle library
2) Pascal, with Ultibo's awesome framework
3) and now Rust too with this project

All I can say is well done, keep up the good work! It is easier to get more people into RPi development if there are more choices!

Btw, do you plan an AArch64 version in the future? Someone has already ported my 64 bit C tutorials into Rust, maybe you can use them.

bzt

Schnoogle
Posts: 71
Joined: Sun Feb 11, 2018 4:47 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Mon Sep 09, 2019 3:33 am

bzt wrote:
Fri Sep 06, 2019 12:24 pm

Btw, do you plan an AArch64 version in the future?
Well, I’ve not thought on this yet as I’ve still only limited knowledge of the 64Bit part, but you are right, this might make totally sense to provide 32bit and 64Bit versions, covered by rust feature switches ;)

BR,
Schnoogle

User avatar
Gavinmc42
Posts: 3730
Joined: Wed Aug 28, 2013 3:31 am

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sat Sep 14, 2019 11:22 am

Been years since I use Rust, things are better now ;)
http://arewegameyet.com/#games

Rust comes pre-installed on Gentoo64 :D
Will those OpenGLES engines port to baremetal?
There looks to be bunch of stuff that could potentially be useful in baremetal?
Or if not, some coding fun in x11.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Heater
Posts: 13299
Joined: Tue Jul 17, 2012 3:02 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sat Sep 14, 2019 1:50 pm

I would never dream to use Rust from whatever packages are install with an OS package manger.

Like node.js and others it's better to install the way the project says. That makes it dead easy to keep up with new releases and/or flip-flop around between new releases, old stable versions etc.

I suspect Gentoo is better and keeping things more recent than Debian/Raspbian but still.

https://www.rust-lang.org/tools/install

User avatar
Gavinmc42
Posts: 3730
Joined: Wed Aug 28, 2013 3:31 am

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sun Sep 15, 2019 12:18 am

I suspect Gentoo is better and keeping things more recent than Debian/Raspbian but still.
Yep, much better, Gentoo64 has RustC 1.37.0.
Unlike Raspbian it stays current, GCC is 9.2. LLVM/clang 8.0.1....
I noticed when I first started using it Mesa/OpenGL was current and worked better than Raspbian.

The penalty for this is that Sakaki's genup script (apt-get update/upgrade) takes hours.
Keeping multi compilers up to date is a pain to do manually, Gentoo does that for me.
If I leave it on, it even automatically updates once a week.
In a production/commercial situation this is probably the last thing anyone would want.

I have yet to find out if it breaks anything as I still have not used it for real development, just exploring the Pi's capabilities.
Which usually leads to questions and brain dumps ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Heater
Posts: 13299
Joined: Tue Jul 17, 2012 3:02 pm

Re: Announce: RusPiRo - a kernel the Rust way ;)

Sun Sep 15, 2019 6:07 am

Gentoo is great. I used it exclusively for some years in 200x. Then Daniel Robbins quite the project and went to work for Microsoft. I got disillusioned and switched to Debian. Last I heard Daniel has not been at MS for a long time, he had some other ideas and started yet another Linux distro...

It's good to see Gentoo is still going strong. I think it's a great idea.

However, I have:

Code: Select all

$ rustc --version
rustc 1.39.0-nightly (760226733 2019-08-22)

Return to “Bare metal, Assembly language”