Quote:
There are a lot of pitfalls, as the 6502 is hardly a RISC machine
It is no RISC machine, not even hardly.
enso wrote:
You'd be better off implementing a RISC core with minimal paths, specifically fine-tuned for 6502-like operations (alu and flags matching 6502), and using it as a microcode machine. You can break the 6502 instructions into 'micro-ops' and execute them as fast as possible then...
Yes in fact this is what I had in mind. I've already made a RISC core, now I could adapt it to be 8 bit instead of 32 and change it so that it is best suited to execute 6502 instructions.
The idea I have would be to do a 32-bit instruction fetch (all 6502 instructions are either 8, 16 or 24 bit, so all of them can be fetched in a single cycle) followed by a decode stage which would asynchronously tell the fetch stage the length of the instruction it just fetched, so it can increment accordingly (it would manage to provide the next 32-bit with some kind of simple shift register/FIFO).
Then the decode stage would send microcode to the RISC machine (in other words CISC to RISC converter) and voilĂ . If the RISC machine is designed greatly, most instructions could be done in 1 cycle, but only if zero page is constantly cached. I'm not too sure how that part is supposed to be done so I'll have to think a bit more.
EDIT : OK this topic is already widely debated in the other thread, sorry for brining it here ^^ All the difficulty is how much importance you add to fetching instructions in Z-Page and access Z-Page with non Z-Page instructions. If you drop both, then 1 cycle per instruction is easy to get. However this is not a 6502 any more if it can't do that