also, a lot of things in stuff like ROMs is about I/O to component in the devices, so you can disassemble and decompile all you want but without the right specifications and context you cannot say what the code does.
so it will also need all specifications of the hardware platform you are running the code on, as well as in this case perhaps even hardware in the catridge etc. (heard those also sometimes have their own chips etc...).
i'd say for 'regular application code' that runs within an OS it might be easier, but still you need to provide a lot of context from the actual execution environment to reason properly what the code actually does? (what does INT 80 run and possibly return anyway, that code is outside of your target binary)
There are several scientific publications on this. But I don't think the latest models are available as convenient plugins for IDA or Ghidra. Guessing variable and function names are considered as relatively easy nowadays. Types and structures are the challenges now.
As with any LLM output, of course it won't be 100% perfect, and you shouldn't treat the output as truthful "data". But I could absolutely use it to make sense of things that at first sight were gibberish, with the original next to it.
It’s possible you could set it off on the labelling task, but anecdotally in my experience it will fail when you need to look a couple levels deep into the code to see how functions play with each other. And again, imo, the big risk is getting a label that _looks_ right, but is actually pretty misleadingly wrong.
If it's easy to generate documentation, and / or if documentation is autogenerated, people are also less likely to actually read it. Worse, if that comment is then used with another LLM to generate code, it could do it even wronger.
I think that at this stage, all of the programming best practices will find a new reasoning, LLMs - that is, a well-documented API will have better results when an LLM takes a swing at it than a poorly documented one. Same with code and programming languages, use straightforward, non-magic code for better results. This was always true of course, but for some reason people have pushed that into the background or think of it as a box ticking exercise.
It’s a lot easier to have someone who knows the code well review a paragraph of text than to ask them to write that paragraph.
Good comments make the code much easier for LLMs to use, as well. Especially in the case where the LLM generated docs would be subtly misunderstanding the purpose.