... There is little (if any?) sample code in SWEET16 here. perhaps worth considering for the
source code repository? And yes, I agree that SWEET16 is elegant. Even the 6502 code that
implements it is elegant.
(Just to note: this thread is one of many with ideas about extending the 6502 architecture. I've posted an attempt at an index to such threads here. There's another flavour of discussion, which is ideas about implementing the 6502 architecture with higher performance. See this recent thread for example. I think it's useful to keep those two kinds of things separate - they are both interesting and useful topics of discussion and areas of work, but they scratch different itches.)
I had a flash of inspiration and I've been implementing a 65Org32 emulator in C. I'm presently working on an assembler.
It is possible to place four 8 bit opcodes into one 32 bit instruction fetch. In this regard, it is very much like Charles Moore's C18 processor or Seymour Cray's CDC6600, although with the registers and addressing modes that we know and love. It doesn't retain binary compatibility with 6502 or 65816, in part because batches of opcodes precede any subsequent operands. Regardless, it has similar registers and addressing modes to 65816. Specifically, direct, absolute and long. I've arranged function and addressing mode into two nybbles. This regular format allows one operand to be sourced from the usual places. The major differences (apart from 32 bit everywhere) is multiplication which can source one operand from anywhere and a lack of carry flag. This would be a lovely architecture for signal processing but I relatively certain that operand size precludes general use.
Unfortunately, I have a technical problem. I'm developing on Unix. This aids some aspects of development. For example, I use a shebang hack to make a 65Org32 binary work transparently like a native binary. Specifically it is possible to prefix any foreign binary with '#!' and the path of the interpreter. Normally, this technique is used to distinguish text scripting language and dialect, such as the various versions of shell, Perl, Python and Ruby. However, it can also be used to run a 6502 binary as easily as any script. I was hoping to apply this technique in other projects and I hoped that others would similarly benefit in this project and their own work. However, I'm fairly certain that the most likely alpha testers for 65Org32 don't use Unix. This may greatly hinder contributions and feedback.
It would also be useful if a standard format is adopted for opcode maps. This would allow considerable generality within a macro assembler. I enclosed an example in CSV format. The first line defines opcode. The second line defines addressing mode. Subsequent lines may define details such as clock cycles and privileges.
After reading your post two or three times, I still haven't caught how you're going to get the operands in if you fetch four op codes in one read. Most instructions will have operands which will have to come from somewhere. Michel Barry's 65m32 takes an approach that's a little different in that fetching the 32-bit word, it's taking the op code and up to 24 bits (or was it 23?) of operand, and then if you need a wider operand, something in the op code specifies that the operand has to wait for the next 32-bit word to be fetched. This (and your proposal too) is more oriented toward higher performance than keeping as much of the 65xx flavor. It would be good to give it a slightly different name, to avoid confusion.
