This isn't generating boilerplate for a hello world script, it's reverse engineering standing software with virtually no exposed interface.
The typical tree is usually:
1. Determine how the file itself is loaded. Headers, magic, partitions, whatever. Pretty simple, and something AI could realistically speed up.
2. Converting the static, possibly packed bytecode (yes I'm aware bytecode is a different thing, ease of explanation) into a readable format for parsing into a higher level language, think
`
B8 01 00 00 00
BF 01 00 00 00
48 8D 35 10 00 00 00
BA 0E 00 00 00
0F 05
B8 3C 00 00 00
31 FF
0F 05
48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 0A
`
To
`
mov eax, 1 ; syscall: write
mov edi, 1 ; fd: stdout
lea rsi, [rip+16] ; address of our string
mov edx, 14 ; length
syscall
mov eax, 60 ; syscall: exit
xor edi, edi ; status = 0
syscall
db "Hello, world!", 10
`
One of these is significantly easier to read than the other.
3. Disassmebling, analyzing, and reconstructing (or directly) to a higher level language like C++ (or whatever the original was written in) for reuse.
4. Then you have to sort the various syscalls that are specifically for the origjnal platform's ABI, and either convert those into a format the host toolchain can accept, or make it a generic and allow the compiler to fix it per platform. This is the hard part. Anyone with enough time can understand how assembly works. You can even write scripts to help convert signatures across the entire thing, but it still needs direct human intervention usually.
The objective of this kind of thing is a 1:1 recreation of the original source code in the absolute sense, but that's extremely difficult to achieve, so we settle for "close enough". It's not like the source is just sitting there packed away, it's already packed and compiled and ready to go. We have to abstract the *how* from the *what*, and that's not something AI does well, especially when a lot of specialized software (games) depends on specific functionality from the host hardware (GameCube).
GitHub Repo
