This is cool but at a glance I expected it would boot on "bare metal", however it seems to be running on top of some firmware/bootloader/BIOS to do talk with the hardware:
So the actual rust code basically does nothing besides calling a bunch of external C functions. The real work was probably in the rustc code itself to add a new target for the PSP.
I've written a bit of low level rust code and it's quite pleasant to work with. For one, it's very easy to crosscompile: all targets are included by default, so if you have a rustc installed you can probably generate code for arm or whatever (although you will have to crosscompile the various libs you need, but in the case of a bare metal application it's probably only libcore).
Then it's pretty much like working with C. I think my main annoyance is that pointer arithmetics is a pity to work with at the moment (you can't even use it in constexpr which is sometimes hard to work around). Oh and you code breaks every other day when you update rustc, but that's life on the edge :)
Almost all open-source code available for the PSP relies on the PSPSDK, which in turn relies on the Sony-supplied firmware on the console.
I think this is still really cool - it shows how easy it is to interface Rust with C code and how it's possible to configure Rust for new foreign build targets.
As a noob who recently moved away from the Python land, it is mind-blowing to me that the shim needed to communicate with a foreign library (or even, bare metal) is that simple.
When I first learned Python years ago, I was told that I can specialize some parts of my Python program using C code to speed up the entire application. However, I've never tried that. Maybe it seemed too complicated to me? I don't know, but it just haven't made my mind go.
It's not really very hard if you know the basics of C, the only weird part is having to deal with a bunch of Py* functions and types to interface with Python's.
Wow I just read up on that. Python 3 is from the late '00s but it still uses fixed 16-bit characters? That's just silly. Pay double the price for most strings, and still get Unicode support wrong. And then the newer versions "fix" this by allowing 32-bit characters? And even newer versions can do a different encoding per string?
I know people like O(1) indexing into strings, but I'm unconvinced it's so useful to totally fuck up your string implementation. Java, Windows and .Net have the excuse of being thought up before Unicode was over 16-bits so it's slightly excusable (but still a bad tradeoff for many, many, applications, probably the majority of server apps).
Scale back a bit, and have a look at Lua! If you've got C chops, you can learn to put Lua anywhere .. its another way to look at the same problem, albeit in a similarly compact fashion...
I didn't read the article. But I wonder, since Rust uses LLVM, isn't the PSP platform a compiler target automatically?
And if not (I suspect it could have something to do with kernel-specific stuff), then shouldn't there be some intermediate kernel-API translator that would make the process of porting the compiler more easy?
Yes, LLVM does (mostly) support the PSP as a target. Previously though, one would have to manually modify the rust compiler itself to recognize any new targets and basically fill in a lot of the plumbing for the new target. But thanks to the (relatively) recent Target Specs feature, teaching rustc about a new triple is as easy as writing a simple JSON file:
The PSP's calling convention ("MIPS EABI", not to be confused with ARM EABI) is simple, the executable format ("PRX" - basically ELF with some extra sections) is converted from ELFs by a PSPSDK tool, and the dynamic linker uses a funny table of 32-bit virtual pointers ("NIBs") correlating with the first 32 bits of the SHA-1 of a method name, which, once the method name is known, makes things pretty straightforward to set up.
Basically any compiler supporting MIPS-EABI-ELF can be made to generate PSP executables with the use of the ELF-to-PRX tools from the open-source PSP toolchain.
The PSP does support some special instructions (a VFPU and some "allegrex extensions") but they aren't necessary to make working binaries - just for performance.
I've written a bit of low level rust code and it's quite pleasant to work with. For one, it's very easy to crosscompile: all targets are included by default, so if you have a rustc installed you can probably generate code for arm or whatever (although you will have to crosscompile the various libs you need, but in the case of a bare metal application it's probably only libcore).
Then it's pretty much like working with C. I think my main annoyance is that pointer arithmetics is a pity to work with at the moment (you can't even use it in constexpr which is sometimes hard to work around). Oh and you code breaks every other day when you update rustc, but that's life on the edge :)