Rust Hello World on a PSP | Hacker News Reader

Rust Hello World on a PSP

github.com

98 pointspitterpatter17 comments

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:

    extern {
        fn pspDebugScreenInit();
        fn pspDebugScreenPrintf(format: *const u8, ...);
    }

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.

The official docs are nice: https://docs.python.org/2/extending/extending.html

If all you want is to call into C code, without needing to really expose that code as Python objects, CFFI[0] is probably a simpler path.

[0] https://cffi.readthedocs.org/en/release-0.8/

I dont know if you've ever tried this using python3, but the Unicode internals make it significantly more complex.

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...

Just reading EBOOT.PBP makes me all warm inside.

I felt such nostalgia. IRshell, cso's, rtype, those bastard proprietary sony memory cards.

Seriously fuck those memory cards, 4x the cost of SD/microSD and you could only buy them from Sony.

I remember at the last moment there was a hard drive adapter. People hated those sony cards.

Same here. Shout out to the ##psp-programming crew from Freenode. So many memories!

I remember the days of contributing to pi-key for the PSP-1001's with an infra-red unit.

That was my first experience with C before I knew what C was. It also was an excuse to finally just use linux instead of whacky cygwin.

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:

https://github.com/luqmana/rust-psp-hello/blob/master/psp.js...

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.

Reply on news.ycombinator.com