Live data from Hacker News

Rust on the MOS 6502: Beyond Fibonacci

gergo.erdi.hu

1–10 of 40 posts

Re: Rust on the MOS 6502: Beyond Fibonacci

#2
That is so cool. I saw some posts about LLVM-MOS a while ago, but at that point I thought it would be just another in a fairly long list of attempts to try and get LLVM to output 6502 instructions.

I never expected it to come together this well! Especially considering that the author of the article mentions there were so many issues with LLVM-AVR, you'd expect them to exist in LLVM-MOS as well. Apparently not! I guess the code quality will only improve from here on out, the loop at the bottom of the article does seem like it is not as optimal as it could be :)

Re: Rust on the MOS 6502: Beyond Fibonacci

#3
See also https://www.nordicsemi.com/News/2019/12/Rust-a-security-prog...

PS: Holy crap! For the first time in my 40+ year career I have clicked-thru from a semi-relevant article about Rust on a micro p̵r̵o̵c̵e̵s̵s̵o̵r̵ controller to a reference about the...[RCA] COSMAC VIP (in the form of this dude's effort to get CHIP-8 running on LLVM-MOS). Do you have any idea how many lawns I had to mow to buy one of those? It was a big disappointment (over my ELF and SuperELF) too! ROFL

[ https://youtu.be/fLVN05Jl6wA ]

Re: Rust on the MOS 6502: Beyond Fibonacci

#4
post #3

See also https://www.nordicsemi.com/News/2019/12/Rust-a-security-prog... PS: Holy crap! For the first time in my 40+ year career I have clicked-thru from a semi-relevant article about Rust on a micro p̵r̵o̵c̵e̵s̵s̵o̵r̵ controller to a reference about the...[RCA] COSMAC VIP (in the form of this dude's effort to get CHIP-8 running on LLVM-MOS). Do you have any idea how many lawns I had to mow to buy one of those? It wa…

I guess when mentioning Rust on Nordic controllers one should also mention these excellent projects

https://github.com/embassy-rs/embassy https://github.com/embassy-rs/nrf-softdevice

Together with https://github.com/nrf-rs/nrf-hal these enable most everything one can do on these controllers form pure Rust (the softdevice is a blob with a C-SDK that's wrapped in rust though)

Re: Rust on the MOS 6502: Beyond Fibonacci

#6

That is so cool. I saw some posts about LLVM-MOS a while ago, but at that point I thought it would be just another in a fairly long list of attempts to try and get LLVM to output 6502 instructions. I never expected it to come together this well! Especially considering that the author of the article mentions there were so many issues with LLVM-AVR, you'd expect them to exist in LLVM-MOS as well. Apparently not! I gues…

I haven't looked at this closely, but 6502 really doesn't lend itself to C compilation. Three registers, only one of which works with the ALU, awkward immovable stack, etc.

The 65816 is a better target (moveable direct page and stack and some wider registers), but also awkward with its register mode switching.

Re: Rust on the MOS 6502: Beyond Fibonacci

#7
post #5

It looks like so much Rust code to generate the simplest of 6502 code. No thanks.

No thanks indeed, but I completely agree with this sentiment from the article:

> It is worth pointing out that the amazing thing about chirp8-c64 is not how well it works, but that it works at all.

Re: Rust on the MOS 6502: Beyond Fibonacci

#8

That is so cool. I saw some posts about LLVM-MOS a while ago, but at that point I thought it would be just another in a fairly long list of attempts to try and get LLVM to output 6502 instructions. I never expected it to come together this well! Especially considering that the author of the article mentions there were so many issues with LLVM-AVR, you'd expect them to exist in LLVM-MOS as well. Apparently not! I gues…

I haven't looked at this closely, but 6502 really doesn't lend itself to C compilation. Three registers, only one of which works with the ALU, awkward immovable stack, etc. The 65816 is a better target (moveable direct page and stack and some wider registers), but also awkward with its register mode switching.

Not only C, any language that thinks there’s other things than global state.

If all your functions are void foo(void) and you don’t use local variables (or your language doesn’t support recursion, in which case all locals can be given a fixed address), targeting 6502 is fine (it also helps if you avoid floating point, use 8-bit variables where possible, etc)

Not supporting recursion also means you can statically compute maximum stack depth. That way, you can avoid linking code that would overflow the stack.

Re: Rust on the MOS 6502: Beyond Fibonacci

#9
post #5

It looks like so much Rust code to generate the simplest of 6502 code. No thanks.

Did you look at chirp8-engine, or only chirp8-c64? The value add is not in the parts that interface with the C64 internals; probably using C for that would make for nicer code. But I wanted to push as much into Rust as I could in the short amount of time I spent on this.

The real advantage of using Rust is in the actual program logic. E.g. the instructions are decoded into an algebraic datatype (in https://github.com/gergoerdi/chirp8-engine/blob/7623353a8bf0...) and then that is consumed in the virtual CPU (https://github.com/gergoerdi/chirp8-engine/blob/7623353a8bf0...). Rust's case-of-case optimization takes care of avoiding the intermediate data representation at runtime.

Re: Rust on the MOS 6502: Beyond Fibonacci

#10

That is so cool. I saw some posts about LLVM-MOS a while ago, but at that point I thought it would be just another in a fairly long list of attempts to try and get LLVM to output 6502 instructions. I never expected it to come together this well! Especially considering that the author of the article mentions there were so many issues with LLVM-AVR, you'd expect them to exist in LLVM-MOS as well. Apparently not! I gues…

I haven't looked at this closely, but 6502 really doesn't lend itself to C compilation. Three registers, only one of which works with the ALU, awkward immovable stack, etc. The 65816 is a better target (moveable direct page and stack and some wider registers), but also awkward with its register mode switching.

From what I understand, LLVM-MOS treats large parts of the zero page as virtual ("imaginary") registers, so you have no shortage of that (https://llvm-mos.org/wiki/Imaginary_registers). Then, sufficiently advanced compiler technology improves the stack situation (https://llvm-mos.org/wiki/C_calling_convention).
Post reply on HN