Yeah. My favourite one (which I think I posted here quite a while back) was when I asked ChatGPT for a simple "add two 16-bit numbers on a 6502" routine and it added the MSBs first, and then added the carry from that to the addition of the two LSBs.
While things are definitely improving, the LLMs are still nowhere near (and showing no indication of getting anywhere near) being anything more than an assistant to someone who already knows how to program and develop software. I pay for Claude and use it a fair amount, so as soon as I'd heard that the new Opus 4.6, with all the extended thinking etc. turned on, was finally going to do things right, I turned it on. I am still daily getting utterly stupid errors, as well as more subtle ones that I'm reasonably sure that someone without my level of experience won't be able to identify.
I guess, since it's been a couple of years, I should have Claude do another pass over some of my more highly optimised assembly code to see if it's any better, but I'm suspecting not. For basic syntax etc. you can expect it to do pretty well with extremely popular languages like JavaScript and Python, but I doubt it would do well with Algol, much less something so different as 6502 or similar assembly languages.
I’m a bit amazed that AI would know enough about the 65C816 and its assembly language to produce anything of note, never mind whether it would work. :D[
Assembly language is hardly unknown on the Internet. Now you might find a few 80386 instructions in your LLM-generated 65C816 code....
I didn’t dissect the AI-generated code, but it seems to be a lot of code for what is supposed to get done.
Yes. LLMs tend to copy and paste code. A lot. Which is why I (amongst many others) currently have a job fixing the results of that. :-/
We all know (surely) that any reasonable CPU can do anything that any other reasonable CPU can do, given memory and time.
Which is rather misleading, because of course what some CPUs have and others don't is precisely memory and time.
I mean, sure, you can use memory to substitute for registers in your 6502, and then after you've already increased your memory usage you can use yet more to deal with all the overhead of bank switching so you can get more memory, and so on, but even if you're willing to do al the work (including all the debugging), you've gone from a hundred times slower to tens of thousands of times slower than a VAX, and you're in that world where, theoretically, you can break any passphrase or encryption key because it's just a matter of time, right? (I think here is where that "sometimes quantity is a quality of its own" thing comes in.)
So, no, doing a thing that works fine on CPU X may not, in fact, be feasible on CPU Y, for any reasonable definition of "feasible."