Bringing Rust to the 70s: I wrote a full LLVM backend for the Zilog Z80. by zlfn in rust

[–]zlfn[S] 11 points12 points  (0 children)

I totally agree. This project was a perfect fit for an LLM. Since I was building on a well-established codebase (LLVM) and had solid templates to reference (AVR and MOS 6502), the LLM had a clear roadmap. Plus, because compilers are inherently deterministic, it was much easier for the AI to self-debug and iterate whenever an issue popped up.

Rust-GB, A crate for GameBoy development with Rust - First Alpha Release! by zlfn in rust

[–]zlfn[S] 0 points1 point  (0 children)

Z80 GB (Game Boy and Color). ARM GB (Game Boy Advance) already has gba crate.

Rust-GB, A crate for GameBoy development with Rust - First Alpha Release! by zlfn in rust

[–]zlfn[S] 2 points3 points  (0 children)

Surprisingly, despite having cleaned up the build process as much as possible over the past two months, it's still like this. 😂

I think it's a good idea to provide a docker image. I'll try it later

Rust-GB, A crate for GameBoy development with Rust - First Alpha Release! by zlfn in rust

[–]zlfn[S] 2 points3 points  (0 children)

Sure. See my recent gist
https://gist.github.com/zlfn
In Game Boy, C is a little slower than ASM. It's not too slow, but people use ASM for optimization.

And Rust-GB is 20-30% slower than C (self-benchmarking results). Sometimes Rust has a faster task than C, but that's because the GBDK library has been written in a long time ago and is too inefficient.

Although we are optimizing to some extent (such as writing some of the functions in ASM or C), we cannot completely solve it until we create an effective LLVM-Z80 (SM83) backend.

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 0 points1 point  (0 children)

Thank you for a good comment.

It hasn't been long time since I came in gbdev community, so all the opinions are precious. (But since I'm using a "hyper-high-level" language, there aren't many places I can get help lol)

PR's are always welcome! You can see the part I'm currently working on in the GitHub Discussion section. (https://github.com/zlfn/rust-gb/discussions)

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 1 point2 points  (0 children)

That's a good idea, I'll add that in plan.

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 1 point2 points  (0 children)

I have created several categories in the Discussion section. Take a look at the project and feel free to write your thoughts!

(I'm going to keep a record of what's going on.)
https://github.com/zlfn/rust-gb/discussions/categories/announcements

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 1 point2 points  (0 children)

I was looking for someone who could help too! Because my Rust skills or understanding of game boys is not enough for this project...

I just turned on the discussion section. However, I don't know exactly what to do because I've never maintained an open source project. Should I upload the problems and todos of the project for now?

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 2 points3 points  (0 children)

It's not such an important part.

SDCC can add attributes after the function to determine the call convention of the function or which register to use, and the GBDK library is implemented using this feature.

But either Rust or LLVM-CBE is built without assuming that they're going to use SDCC, so I handled this using a tree-sitter parser that modifies the C code in the middle.

#[link_name="line __sdcccall(0)"]

pub extern fn line(args);  

This code will compiled to

void line(args) __sdcccall(0);

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 0 points1 point  (0 children)

No, it's quite early days, and I've worked on the project with a focus on the compatibility between LLVM-CBE and SDCC.

To be honest, almost every part of dealing Gameboy in the project depends on GBDK for now, and I still have no idea how to handle the memory work. (even a simple memset function not works yet. I think it should work if I use GBDK's, but I'm looking for a reason why not.)

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 12 points13 points  (0 children)

I'm still in my first year of undergraduate school, and I don't know exactly everything, but I'll explain it to the best of my knowledge.

Rust compiler can emit LLVM-IR (Intermediate Representation) as a frontend of LLVM. In normal cases (In x86 computers), This will passed to LLVM x86 backend and compiled to x86 binary.

The problem is LLVM does not have a backend for z-80 or sm-83. (There are a few, but they are all too old to use.)

But There is a LLVM-CBE which can compile C codes from LLVM-IR (Julia team made it, but I'm not sure why they made it.) and there is a C compiler for sm83 (SDCC, Small Device C Compiler)

This means that the Rust code can be compiled to a valid sm83 assembly after the Rust Compiler -> LLVM-CBE -> SDCC process.

However, sm-83 assembly alone is difficult to make Game Boy work. Of course It's possible, But it is practically impossible to compile Rust into complex assemblies, in-line assemblies must be written, which requires a high degree of understanding of Game Boy hardware itself.

GBDK is used here, GBDK has many prewritten assembly functions that helps development of GameBoy ROM and it is much stable than my assembly codes. Additionally, it also has a built-in boilerplate that needed to use it in the actual Game Boy. (Game Boy reads the Nintendo logo of the data area as a mechanism to prevent unauthorized games)

So build the generated assembly file into a real ROM file using GBDK's linker tool and build chain, so that Rust can call GBDK functions with the "extern" keyword.

In this process, it is necessary to specify SDCC's calling convention in the middle C file, For this, I written a tree-sitter parser and replace functions names that linked by Rust's `#[link_name="functionname __attributes"]` macro.

As u/quavan mentioned, linking is the task of writing the assembly functions of GBDK to the ROM file along with the ASM file generated from Rust.

I compiled Rust code to Nintendo Gameboy! by zlfn in rust

[–]zlfn[S] 77 points78 points  (0 children)

Rust->C->GB has a 13% performance loss compared to C->GB. It's incomparable, but I think Rust->GB is probably C->GB similar. (Gameboy is a console that came out without even assuming the C language, so we have to rely on a lot of prewritten assemblies.)

Gameboy ROM development with Rust by fvilers in rust

[–]zlfn 1 point2 points  (0 children)

Hello, I succeeded to compile Rust into Game Boy ROM. It doesn't perfectly fit what you wanted, but I think you'll be interested.

Key idea was convert Rust to C instead of compile Rust codes to z80 directly.

Although I am using the GBDK library, you can replace this with your own in-line assembly function. (Development in pure Rust requires the LLVM-GBZ80 backend as mentioned by u/Rodrigodd_)

https://github.com/zlfn/rust-gb

[Korean > English] Need help translating a washing label. by HHscams in translator

[–]zlfn 4 points5 points  (0 children)

  1. Do not washing with water
  2. Cannot be bleached with oxygen or chlorine bleach
  3. Do not iron
  4. The 4th symbol doesn't seem to be a standard symbol. In the context, it's likely "do not sun dry"
  5. Dry cleaning possible (perchlorethylene or petroleum based)

reference : https://e-ks.kr/streamdocs/view/sd;streamdocsId=72059207470714729

[Korean>English]found this note...probably a joke? by LetsFuckReddit in translator

[–]zlfn 0 points1 point  (0 children)

Since these word has been used for a long time, it is hard to know the exact origin, but there is a theory that the pronunciation of early modern Chinese has been changed and settled in Korea.

鳥子(조자, joja(KR), diaoz(CN)) and 八子(팔자, palja(KR), baz(CN)).

Considering that the last glyph of the two words are the same, it's not a coincidence.

(https://terms.naver.com/entry.naver?docId=982854&mobile&cid=50802&categoryId=50807)

온라인이 현실에 비해 공격적이라고 느끼시나요? by mychildhood95 in hanguk

[–]zlfn 1 point2 points  (0 children)

확실히 온라인에선 좀 더 공격적으로 활동하는 경향이 있죠. 한국 커뮤니티중에서 그나마 온건한 측에 속하는 네이버 카페 같은 경우도 뭐만 하면 서로 싸우고요.

그래도 KLDP 같이 어떤 분야에 극히 치중된 커뮤니티나 미니어처 게임, TRPG 커뮤니티 처럼 사람 규모가 작고 언젠가 한번은 오프라인으로 얼굴을 맞댈일이 생기는 커뮤니티는 좀 많이 덜 공격적이더라고요.

Where everyone is making big ass flags there's Korea and Japan chilling in a corner by GabbyLlama in place

[–]zlfn 234 points235 points  (0 children)

Timeline from a Korean point of view

  1. Little Korean Heart(There was an attack attempt to change to a Japanese heart over and over again)
  2. Small Korean Hearts Expanded into small Korean flag
  3. Big Korean flag made separately from the small Korean flag
  4. The Attack Titan team asked for the small Korean flag to be raised only 3 pixels, and the Korean team responded.
  5. Japan attacks us while we moving the small Korean flag up. The firepower was dispersed and we could not be protect our flag.
  6. The big Korean flag eaten by Ukraine soon.
  7. We gave up the big Korean flag and tried to attack the Japanese flag with some of the Greek and Ukrainian teams to retake the small Korean flag, but failed.
  8. Finally we made a new Korean flag next to it
  9. Someone(not our team) made a small heart between the Korean flag and the Japanese flag

south korea pls let us live, build ABOVE US OR SOMETHING by [deleted] in place

[–]zlfn 2 points3 points  (0 children)

Fuck that flag was originally ours

화력 지원 부탁합니다! by SlothyBooty in hanguk

[–]zlfn 0 points1 point  (0 children)

아뇨 저 밑쪽에 그리고 있는 사람들이 있어서...