6 ms·
RISC-V OS using Rust: Graphics
- gnarbarian 6y agoI love the recent accelerated development of the risc v stack. Anxiously waiting for the day I can purchase a riscV raspberry pi like SoC with fully oss hardware and Ready for Linux.
- pavehawk2007 6y agoI think until they get into the mass production market, risc-v will be fairly expensive compared to the Rpi. Take a look at the full stack Hifive Unleashed ($1000) or the cheaper Hifive1 (revb): https://www.sifive.com/boards https://www.sifive.com/boards
- andoriyu 6y agoWell, Hifive Unleashed is a dev board with tons of features for developer, a market where $1000 is pretty okay price. It has DDR4 ECC RAM, RPi is another story: it's a single board computer with exposed GPIO and used to be shipped with ancient GPU. Hifive1 is more of a competitor to Arduino if you can call it that. They even have the same pinout for expansion. They are quite pricy, like you said, due to early adopter fee. However, you gotta understand that SiFive develop their cores and unlike Arduino RPi can't just slap something that is already produced and ready to be mounted on a board.
- pavehawk2007 6y agoI've been trying to use the Sipeed Maixduino. It's much like the hifive1 except it uses the Kendryte K210, which is a fully supported RV64GC dual-core. It even supports supervisor and user modes. It's also relatively cheap. The problem is that documentation is lacking, so I'm having to reverse engineer their BSP: https://maixduino.sipeed.com/en/ https://maixduino.sipeed.com/en/
- deleted 6y ago[deleted]
- Koshkin 6y agoUsing virtio to demonstrate how set a pixel looks unjustifiably complicated. Queues, requests, responses!.. By contrast, using the framebuffer in Linux is a breeze. (Doing this in DOS was easier still.)
- pavehawk2007 6y agoI'm writing this from the OS's perspective. Linux abstracts this away, but we have to do it to get the same abstraction. You can see under the user space portion how simple it is to grab a framebuffer, which is then mapped into user space. Then we have full access to RGBA values.
- varbhat 6y agoLinus Torvalds once told this about C++ : https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.2311@home.osdl.org/ https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.231... " any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel " This was about C++ . So,given that Rust is similar to C++ , How does this quote applies to Rust? Edit: I am getting downvoted for this post. Downvoters,any reasons?
- lachlan-sneff 6y agoThe rust std library doesn't hide allocations at all. It's very explicit.
- dthul 6y agoI'm not even sure what Linus was referring to when he talked about memory allocations in C++ being hidden. Aren't the only options either an malloc (kmalloc) call or a `new` operator call?
- cbsmith 6y agoI believe he was referring to encapsulation of allocations in constructors, and implicit invocations of the copy operator and constructor. He may have also been referring to a lot of how STL works, though the STL is pretty explicit about its allocations & behaviour.
- dthul 6y agoYeah, maybe he was referring to constructors. That might make sense, since something like "MyType t;" could allocate. I guess in the kernel context the STL (or whatever was around in 1992) would not be used though. Edit: or even something like "a = b"
- cbsmith 6y agoIt's not constructors per se. It's what people put in to them. So MyType t also allocates in C, right (it'd be a stack allocation of sizeof(MyType) bytes)? But the difference is in C++ that could cause a bazillion heap allocations. The problem gets magnified when you pass around these objects by value, thereby invoking copy constructors that also do those allocations, and doing value assignment, where you could have all those allocations happen again. His comments predate r-value references, and a lot of stuff that r-value references have improved would be exactly the kinds of things where he saw a problem (though he'd hate the r-value solution).