Jan,

You certainly can use as much logic as you like.

However, since every operation of the ALU can be a load and store, based on the instruction set, every operation takes data, some data, from somewhere, and does something, even if it's a NOP and does nothing, and stores it somewhere, even if it's in its original source. No matter how many clock ticks you have, you can do the address arithmetic on one phase of the clock, and the data arithmetic on the other. If you insist on more than one clock tick per instruction, then you simply divide the N-clock oscillator by N to generate the controlling, and preferably non-overlapping, clock.

If you construct your ALU wisely, you then have a register file, fed from an adder, fed from a multiplexer, fed from the register file. It's the same number of propagation delays through the whole ALU all the time, so timing is not complicated. One of the registers, of course, is the data bus output register, and one is the data bus input register. Since there's an IRAM bus, and an SFR bus, and an external DATA bus, and an internal Code bus and an external code bus, it makes for a substantial multiplexer and register file, one from which you might want to delete unnecessary aspects if you were to go to hard silicon. In that case, you might find that the cost per pound of the silicon vastly favors the transparent latches rather than clocked flip-flops. Since this is a totally virtual architecture, it matters not whether you use 10^4 gates or or 10^4096. However, if you use clocked registers, you'll probably want to use 12 clocks, or maybe 6 or 8.

I'm persuaded that the IOR is the only thing that needs to be clocked. It can do double-duty in that once an instruction is underway, it's available for at least half of each cycle.

Think about it! Consider the use of a DLL to multiply the single clock by two or four, and then back down again. Consider what possibilities that would open up for you. Sleep on it!

RE