Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raspberry Pi Bare Metal Programming with Rust

blog.thiago.me

Post reply on HN
Print view View original

71–80 of 96 posts

Re: Raspberry Pi Bare Metal Programming with Rust

#71

Post by jeffreyrogers »

pcwalton wrote: post #57
jcoffland wrote: post #28

As a long time C programmer this is not very convincing. A C program to do the same requires far less voodoo. All you need to do is take the address of the GPIO register then toggle the bit. No name mangling. No error handlers to override. Don't get me wrong I know rust does have some compelling features. It does seem odd to me that so many of what would be compiler options in C are hard coded.

Point by point: > All you need to do is take the address of the GPIO register then toggle the bit. Yes, and that is unsafe. Rust makes you put that in an unsafe block, to encourage you to build safe interfaces. This is a good thing. > No name mangling. The alternative to name mangling is not having a module system, with all the fun name conflict issues that come with it. Rust made the right decision here. > No error…

After having played around with Rust a bit and seeing it used in some non-trivial applications I've grown to like it a lot, despite being an initial skeptic. However it's aggravating that in every post about Rust which raises valid criticisms about the language (in this case having to do with the ease with which C allows you to do low level programming), those associated with the Rust project leap to its defense and suggest that Rust's decisions are right for every situation.

Just because Rust can't easily do things that C can doesn't make it a bad language, but it does mean that, shockingly, there are somethings that Rust isn't as well positioned for as other languages are.

Similarly, there are things that C is bad at. Both at the high level and the low level. At the low level it hides too much of the CPU's features so for some very low level programming you need to drop to assembly. At the high level it has obvious deficiencies, many of which Rust addresses, but for interfacing with the actual hardware it is tough to beat C in terms of convenience.

Re: Raspberry Pi Bare Metal Programming with Rust

#72

Post by pjmlp »

e12e wrote: post #68
pjmlp wrote: post #43

Earlier quoted context omitted.

Still alive: Ada, SPARK, ATS, FreePascal, D Controversial: Go (if someone ports the runtime to bare metal), embedded JVMs, embedded, Swift (depending how Apple drives it), .NET Native (if C# gets missing features from System C#) Faded away: Algol, PL/I, CPL, Mesa, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Turbo Pascal, Forth, Sing#, System C#

And C++, surely? (Although, I would probably choose C (or even assembler) over C++ for something this simple (loop, blink a light). And between all those, I think Rust is really interesting. It could probably be argued that Rust doesn't add much on top of D (as a "better" C++) -- but between the mind-share and the focus on "safe" (and boxing in unsafe) memory access, I think Rust is really interesting. Not sure how r…

I left C++, Objective-C and Objective-C++ out, because of the C compatibility.

The price of commercial compilers wasn't the only issue with Ads. It never had any friends in the UNIX culture.

UNIX culture always ignored safer system programming languages from the 60 and 70's.

If the hacker culture bashes Java for being verbose, what would they say about Algol languages like Ada?

Another problem was Ads was mainly a DoD thing, there were no commercial OSes using it.

So you either used the system programming language of the OS, if you were lucky to access to the official SDK, or bought one you could afford. There was always an option to type it all in as well.

So with these constraints it was hard to get Ada widely adopted.

It is now mainly used in avionics, train control systems and high integrity systems. All areas that the common Starbucks coder usually doesn't care about.

As for D there are some projects using it on micro-controllers, presented at D Conf 2014. In comparison to Rust, it might appeal to those that favour a C++ like syntax, interoperability with C++, GC support, great metaprogramming capabilities.

I like both, and think there might be space for both of them.

Re: Raspberry Pi Bare Metal Programming with Rust

#73

Post by slackersc »

e12e wrote: post #67
0xcde4c3db wrote: post #61

Earlier quoted context omitted.

My experience doing this sort of stuff in C is that this class of complexities is still present, but hidden outside the source in the crt0 and build scripts. Putting it in the actual program text seems like an improvement.

Exactly. I saw the gp comment and feared there was lots of boilerplate, arcane incantations -- and the only slightly smelly thing in the (IMNHO) beautiful and short example is the use of an empty asm block to "fight" the compiler on optimizing out the busy loop. I can't imagine the full C example for this is any prettier or easier to follow? [ed: As for "no name mangling" - having such an easy way to turn it off when…

I think you're giving it a bit more credit than necessary. Don't get me wrong, it's cool that they've got it running on a RPi, but it's almost word for word what you'd write in C (right down to needing to inline assembly to get a busy loop to work). The C implementation wouldn't need to bring in a bleeding edge nightly build, worry about name mangling etc..

Re: Raspberry Pi Bare Metal Programming with Rust

#74

Post by pcwalton »

jeffreyrogers wrote: post #71
pcwalton wrote: post #57

Earlier quoted context omitted.

Point by point: > All you need to do is take the address of the GPIO register then toggle the bit. Yes, and that is unsafe. Rust makes you put that in an unsafe block, to encourage you to build safe interfaces. This is a good thing. > No name mangling. The alternative to name mangling is not having a module system, with all the fun name conflict issues that come with it. Rust made the right decision here. > No error…

After having played around with Rust a bit and seeing it used in some non-trivial applications I've grown to like it a lot, despite being an initial skeptic. However it's aggravating that in every post about Rust which raises valid criticisms about the language (in this case having to do with the ease with which C allows you to do low level programming), those associated with the Rust project leap to its defense and…

Of those three issues, I see not sectioning off unsafe code as the only real defensible choice when comparing C to Rust. Whether you should have to type "unsafe" is a legitimate tradeoff; if all your code is unsafe, the unsafe keyword adds noise.

Undefined behavior and the lack of namespacing don't fall into this category, though. C would be a better language all around if it required that null pointer dereference trap to an error handler (at least on hardware with an MMU or MPU). It would also be a better language if it had a module system.

Not every engineering decision is a tradeoff. Sometimes certain decisions are just better all around. I think that modules and error handlers fall into this category.

Re: Raspberry Pi Bare Metal Programming with Rust

#75

Post by mpweiher »

pcwalton wrote: post #74
jeffreyrogers wrote: post #71

Earlier quoted context omitted.

After having played around with Rust a bit and seeing it used in some non-trivial applications I've grown to like it a lot, despite being an initial skeptic. However it's aggravating that in every post about Rust which raises valid criticisms about the language (in this case having to do with the ease with which C allows you to do low level programming), those associated with the Rust project leap to its defense and…

Of those three issues, I see not sectioning off unsafe code as the only real defensible choice when comparing C to Rust. Whether you should have to type "unsafe" is a legitimate tradeoff; if all your code is unsafe, the unsafe keyword adds noise. Undefined behavior and the lack of namespacing don't fall into this category, though. C would be a better language all around if it required that null pointer dereference tr…

> Not every engineering decision is a tradeoff.

Scratch the "not". For example, if I have a small-enough code-base, a module-system, is not worth it, unless it has zero cost. Or if the module system doesn't fit my needs, it will often be easier to create what I need if I don't have to work around what is there. Same with error handlers.

Every engineering decision is a tradeoff, though you may be in a space where the tradeoffs obviously point in one direction.

Re: Raspberry Pi Bare Metal Programming with Rust

#76

Post by pcwalton »

mpweiher wrote: post #75
pcwalton wrote: post #74

Earlier quoted context omitted.

Of those three issues, I see not sectioning off unsafe code as the only real defensible choice when comparing C to Rust. Whether you should have to type "unsafe" is a legitimate tradeoff; if all your code is unsafe, the unsafe keyword adds noise. Undefined behavior and the lack of namespacing don't fall into this category, though. C would be a better language all around if it required that null pointer dereference tr…

> Not every engineering decision is a tradeoff. Scratch the "not". For example, if I have a small-enough code-base, a module-system, is not worth it, unless it has zero cost. Or if the module system doesn't fit my needs, it will often be easier to create what I need if I don't have to work around what is there. Same with error handlers. Every engineering decision is a tradeoff, though you may be in a space where the…

A module system is always worth it because every program needs to use library functions. Even if you think you don't, LLVM will generate calls to library functions for ordinary code; for example, if you move structures around on the stack, LLVM might just decide to call memcpy(), even if you didn't ever import string.h. (Checking your code after the fact to verify there are no library calls doesn't get around this because a new version of the compiler might add a library call where there wasn't one before.) Now you want some mechanism to isolate your code's names from the library's names. That's a module system.

Re: Raspberry Pi Bare Metal Programming with Rust

#77

Post by pjmlp »

dom96 wrote: post #56
pjmlp wrote: post #43

Earlier quoted context omitted.

Still alive: Ada, SPARK, ATS, FreePascal, D Controversial: Go (if someone ports the runtime to bare metal), embedded JVMs, embedded, Swift (depending how Apple drives it), .NET Native (if C# gets missing features from System C#) Faded away: Algol, PL/I, CPL, Mesa, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Turbo Pascal, Forth, Sing#, System C#

Don't forget to add Nim to that list! One of Nim's defining features (compilation to C) makes it work rather well for this sort of thing.

Forgot about that one sorry.

Compilation to C is a toolchain feature, not a language one.

Re: Raspberry Pi Bare Metal Programming with Rust

#78

Post by pjmlp »

jeremyjh wrote: post #49
pjmlp wrote: post #43

Earlier quoted context omitted.

Still alive: Ada, SPARK, ATS, FreePascal, D Controversial: Go (if someone ports the runtime to bare metal), embedded JVMs, embedded, Swift (depending how Apple drives it), .NET Native (if C# gets missing features from System C#) Faded away: Algol, PL/I, CPL, Mesa, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Turbo Pascal, Forth, Sing#, System C#

I think he was asking which languages could actually be used to do this today, without writing a new cross-compiler first.

You always need a cross-compiler, or a VM. There is no way around it.

Re: Raspberry Pi Bare Metal Programming with Rust

#79

Post by pjmlp »

akhilcacharya wrote: post #52
jeremyjh wrote: post #49

Earlier quoted context omitted.

I think he was asking which languages could actually be used to do this today, without writing a new cross-compiler first.

That's exactly right. I didn't know that D would be an appropriate language for things like this - I'll have to check it out.

Check some of the videos here

http://wiki.dlang.org/Videos

Namely "Tiny, Ubiquitous Machines Powered by D" and "x86 Bare Metal and Custom Runtime Programming".

Re: Raspberry Pi Bare Metal Programming with Rust

#80

Post by pjmlp »

Manishearth wrote: post #65
izacus wrote: post #37

Earlier quoted context omitted.

Of course that same ability lets you clobber anything else in your address space and leads to those lovely debugging sessions playing "track down what corrupted my datastructure".

Whilst having to debug this is still undesirable, I recommend trying `rr` ( http://rr-project.org/ ) to track this if you're ever in such a situation. It's as simple as setting a watchpoint and reverse-continue-ing! I don't do much C/++ these days, but when I do (and it's a large codebase which is hard to debug), `rr` is invaluable. It works with Rust too.

Seems quite restrict in terms of platform support.
Post reply on HN