When you look at this block diagram you can see a 'Predecode Register'
I suppose that the Opcode is already a 8-bit Number (D0-D7). So what was the purpose of the Predecode Register. Did it really decode something?
5
-
My guess: the opcode can't be allowed to change while the command is running, so it's simply buffered in the register.– Zac67Oct 11, 2017 at 20:30
-
3Could you also provide the full diagram (by reference if required)? Otherwise my guess is just that decoding probably takes more than the amount of time that the data is on the bus, which is something like a quarter of a cycle if memory serves.– TommyOct 11, 2017 at 20:40
-
I have the same instinct as Zac67. It feels like a buffer/latch to lock the value of the opcode before decoding.– Geo...Oct 12, 2017 at 2:53
-
But there is also the Instruction Register, which hold the current command.– user6734Oct 12, 2017 at 4:48
-
2The 6502 has a limited form of pipelining where it fetches the next instruction on the last cycle of the current instruction. Thus the PD register would be needed to latch the next instruction while the IR is still holding the previous one and controlling the final cycle of execution.– George PhillipsOct 12, 2017 at 17:41
Add a comment
|
4 Answers
I suppose that the Opcode is already a 8-bit Number (D0-D7).
Yes, like any other data byte.
So what was the purpose of the Predecode Register.
The Predecode register is loaded with each (read) bus cycle. Effectively being a duplicate of the data latch (DL). In a general way it's the much cited 6502 pipeline, as it loads the byte fetched, during the last cycle of an instruction (usually the one doing the work). Here it gets stored for one cycle to be fed into the instruction register at the beginning of the next cycle.
Did it really decode something?
No. That's what the Predecode Logic (to the left) is good for. Also that decoding is limited to detecting single byte instructions with the purpose to stop the PC from incrementing during the first cycle of a one byte instruction (that is why the opcode of the next instruction gets fetched twice). It detects all x8 and xA opcodes plus whatever irregularities exist (RTI, RTS).
So basically PD and Predecode Logic are pipeline and pipeline/fetch control of the 6502.
In addition, the Predecode Logic is where the pseudo BRK gets 'injected' to handle an interrupt. Not a real 'injection' of a full byte, as it's done via the clear input of the IR.
Edit: If I understood it correctly, according to this forum post, the Predecode Register isn't really a register but a latch which stores only 1 Bit at a time and passes it to the Predecode Logic.
Looking at that post, I can't really find any claim about something serial. It basically describes the same as here.
answered Oct 12, 2017 at 18:15
-
Sorry for asking the same question, but that would mean that the Predecode Register is an actual register with a size of 8 Bits and not a latch?– user6734Oct 12, 2017 at 18:29
-
2
-
2@mondlos Erm, I'm a bit confused. Your asking about 6502 internals and you're not aware that Phi2 is the basic clock signal used across the CPU (and ints perhipherals)? Further, if you don't understand latching vs. registers, you might want to ask that on electronics.stackexchange - or try some beginners course for digital electronics.– RaffzahnOct 12, 2017 at 19:18
-
2Latches and registers are both made from flipflops. The term Latch or Register doesn't imply any size. A register can be one bit and a latch can be 16. The difference is when they accept input and when this is reflected as output. A latch features an enable input and all data is routed transparent to output until the enable is released. After that the output stays. A register outputs a previous loaded input until the next is loaded at a specific time (clock pulse). The decision of using a latch or register depends what outputbehaviour is wanted.– RaffzahnOct 12, 2017 at 19:23
-
1@Raffzahn, I have learned since then. Thanks for providing your in-depth info on the predecode register.– user6734Sep 15, 2019 at 11:05
The Predecode register just holds the opcode which was fetched, as you have seen. The opcode which is about to be executed has already been loaded into the predecode buffer during the execution of the previous instruction. It does not decode anything just of itself; registers don't do anything like that. It just buffers the opcode until the time when it might be needed. The reason this value must be buffered in this way, and not sent straight into the decoding ROM is because:
- an interrupt might get serviced at this point.
- the previous instruction may not be done executing yet.
So what the predecode logic does is either load the opcode from the predecode register if no interrupt happened, or the byte $00 if an interrupt did happen. That byte is the BRK opcode, which invokes the interrupt handler. (This is incidentally the reason behind the bug where a hardware interrupt "swallows up" a software interrupt.)
That hopefully explains why the opcode has to be buffered in that predecode register before it may be executed.
answered Oct 12, 2017 at 8:28
-
So you think the Predecode Register has a capacity of 8 Bit?– user6734Oct 12, 2017 at 16:22
-
2It's 8 bit wide and basicly a duplicate or the input data latch. Each byte loaded, no matter if it's an opcode, parameter or data, is moved into PD.– RaffzahnOct 12, 2017 at 17:44
-
@Wilson No, the PD is loaded with each Phi2. It's just the last byte read, which happenes to be the next instruction during the last cycle of the previous. It gets copied into the IR one cycle later. Reset is an interrupt and gets handled by the predecode logic by inserting a BRK into the IR. except it's one the CPU usually never returns from :))– RaffzahnOct 13, 2017 at 7:06
-
@Wilson I guess that could have be done. There might have been at least two resons why a seperate register would be preferable. For one, the DL is already a quite complex structure, layed out verticaly along the lower left side to go with the register structure. It features 3 output drivers for DB/ADH/ADL. Adding one more might have been more complex than a seperate register. which in itself is smaler than a single bit of the DL. Second the PD register is quite interlinked with the PD Logic, thus seperating it from DL might inprove timing and ease layout. Your guess is as good as mine.– RaffzahnOct 13, 2017 at 9:11
-
@Wilson: Many instructions need to do something on the cycle after their "last" one. For example, ADC #immed takes two cycles, but it can't even start doing the addition until after the end of the cycle where it fetched the operand. The ADC opcode needs to remain loaded in the 6502 even while the next opcode is being fetched.– supercatOct 14, 2017 at 17:22
If you look at the Visual6502 simulation in advanced mode, you can see the predecoder latch and predecoder logic on the very right side near the top, diagonally below the decoder ROM that stands out with its regular pattern at the top. The Visual6502 signal names contain the lines pd0 to pd7, associated pd*.clearIR clear lines, and also the predecoder output lines
// internal signals: predecode latch partial decodes
"PD-xxxx10x0": 1019,
"PD-1xx000x0": 1294,
"PD-0xx0xx0x": 365,
"PD-xxx010x1": 302,
"PD-n-0xx0xx0x": 125,
So the predecoder does really decode something. I haven't looked at where those lines go, and why they are needed (possibly because otherwise timing wouldn't work, as getting those signals from the final decoding ROM would be too late in the cycle), but with a bit of time investment into the netlist and the Visual6502 representation it should be possible to find that out.
-
I've not fired up the simulator on a large enough screen to let my feeble eyes watch all the details, but I think there are a number of places where, instead of using passive pull-ups, the 6502 drives a signal unconditionally high on one clock phase and then conditionally drives it low on the other. I don't know if the "pre-decode" does that, but if a one-phase switched pull-up is smaller than a passive weak pull-up I would think such an approach could be helpful with the decide ROM (which would otherwise need a lot of passive pull-ups).– supercatOct 14, 2017 at 15:29
-
Now the predecoder does decode something. It works out if the instruction is a single byte or not (this information is somehow fed to the PC, to keep it from incrementing too many times or something). But the predecode register does not decode anything. Oct 16, 2017 at 9:08
Registers by themselves don't decode anything. Instruction decoding, as is apparent from the full diagram, happens in two stages: Predecode logic; then the Decode ROM. There must be a register before each stage to ensure that the inputs to the circuit it feeds is stable while the signals are propagated through the logic. The Instruction Register between the Predecode logic and Decode ROM is likely wider than 8 bit.
The Decode ROM is marked 21x130, and 130 is written on the outgoing arrow, so it is apparently 130 bit wide, but it is unclear how deep it is.
Decoding directly from 8 bit to (alleged) 130 would take either too many levels of logic, requiring to lower the clock frequency, or too large a ROM to fit on the chip. Hence the decision to split the decoding scheme into two clock cycles.
