| ??? 09/03/07 15:32 Modified: 09/03/07 15:38 Read: times |
#143950 - Why do you think it\'s a lot of logic? Responding to: ???'s previous message |
Russ Cooper said:
Richard said:
How would you do it? Short Answer: I don't know. Long answer: This little discussion is quite hypothetical as far as I'm concerned. I don't have an architecture in mind, Perhaps that's why this simple concept eludes you. and if I went through the exercise of developing one (as Jan is doing), I might or might not arrive at exactly the configuration that you are describing. The only point I've been trying to make is that on the surface, the idea of the fake LJMP seems kludgy to me, primarily because of the extra logic needed to feed it those two fake zeros.
-- Russ If you proceed with the notion that every ALU operation is load from and store to the register file, and that the increment and decrement instructions are performed there in the ALU, since the register file is just registers and not D-flops, counters, shift registers, etc, requiring five or six times as many gates per bit, then the logic required to load PLC and PCH is pretty straightforward. Once the LJMP is loaded into the IOR, assuming, of course, that there is one, and in the presence of <state=0>, the new values are loaded into the state machines that control system operation, and that also clears the IOR, where, as a result, there is a 0x00. So long as that RESET signal persists, the IOR is loaded with 0x02. So long as RESET persists, this continues until it is removed. Once it is removed, the two loads take place in the normal fashion, with the exception that the system bus is not used as the data source, but the IOR is cleared and held clear for two cycles. This is easily achieved in a number of ways, but one might be a counter (perhaps part of the execution engine) that responds to the interpretation of the LJMP opcode in the presence of <state=0>. So long as RESET persists, the execution engine does nothing, but once it's released, it responds to the state imposed by the IOR content during <state=0>. It should do that on every opcode, regardless of how it came to be in the IOR during the <state=0> condition. There's lots of logic in the core, but very little of it is specific to the RESET-sequence-imposed LJMP. I still submit that it's not a "fake" LJMP, because it's a "real" one. LJMP is just an opcode. It's only a byte (0x02). When it's loaded into IOR in the presence of RESET, it causes the bus to be ignored for two cycles. That, as I've suggested, can be decided within the execution engine (a state machine responding not only to its present state and to the IOR content, but to RESET as well). BTW, it's that <state=0> condition that determines when what's on the system bus is to be interpreted as an opcode. RE |
