Now that it’s been proven that the z80’s incrementer/decrementer circuit is on the bottom left of the die, across from the registers, and not part of the ALU:
Does the z80 programming bible need to be updated, which has the ALU wedge shapes all over the inc pages:
Third edition still has this issue also. I can understand why they thought the ALU is doing this. But, I don’t think we should still be teaching programmers little fibs that may not affect them at all - like that the 4-bit ALU does “all” the arithmetic - anymore just so there are less low level hardware facts to explain. We know more now and can explain better now that the chip has been reverse engineered. Especially in a big textbook, there is space to do this. Imagine being some noob deciding not to read the textbook because they are wondering how many more mistakes are in it, oblivious to the fact that it’s still an excellent textbook and the authors likely just have a different definition of what an ALU is.
Is there any chance of this getting fixed in new edition? Or is it time to write a new z80 textbook from scratch?
I don’t see this as a concern, to be honest. Zaks’ book serves to explain programming a microprocessor, in general and specifically. (I imagine it bears a great resemblance to his book on the 6502, which first came out a year earlier.) The programmer needs a model of the CPU, but it doesn’t need to bear a perfect resemblance to a particular implementation - and different implementations can have quite different microarchitectures.
This diagram from the book probably originates with Zilog:
The internal organization of the Z80 is shown in Figure 2.14. This diagram presents a logical description of the device. Additional interconnections may exist but are not shown.
Similarly in the 6502 book, we don’t see the Special Bus, or the PC incrementer.
Well those diagrams are clearly not illustrating each and every transistor, and I don’t think they should. But I have been frustrated with the official documentation not giving enough details about various “internal” things that can help with understanding. For example, if something is stored in the W or Z register, I want the documentation to say so and not just that’s its “stored internally” which isn’t clear.
For understanding why certain instructions have certain cycle counts instead of just memorizing them I think getting the hardware details right is important. The way I see it, if it’s possible to write a program that detects it’s running in an emulator, that’s a behavior difference that needs to be explained, and more accurate block diagrams helps with that.
I understand, but I think you’re looking for a different level of documentation. From the perspective of the programmer’s model, the W and Z registers are not a concern - they sit lower in the abstraction, and it’s only through undocumented behaviour that they are visible.
There is of course a place for more exhaustive documentation - but on the one hand there’s what you’d need to implement something which fits the programmer’s model, and on the other hand something even more detailed to get fully cycle accurate behaviour including everything originally undocumented.
I think the idea and practice of abstraction has served us very well, even when sometimes the abstraction has holes in it.
In particular, from the point of view of designing, verifying, and selling a microprocessor (and then supporting it), there’s a very strong argument for keeping a lot of implementation details hidden. Customers will be happy to see improved performance from later implementations. Customers who made use of undocumented behaviour will be unhappy. This has happened many times.
Yeah and if I were designing a new architecture that would be good to hide a lot of implementation details. But someone asked me to work on a project that used illegal 6502 opcodes all over the place and I realized how much of a pain it is make everything legal again when you don’t have that undocumented stuff documented well.
(The “traps” are subtle or misleading structures in the Z80 layout, intended to delay successful reverse-engineering - an effort which was regarded as successful - see the Zilog Oral History Panel on the Founding of the Company and the Development of the Z80 Microprocessor where Shima says “I heard from NEC later the copy maker delayed the announcement of Z80 compatible product for about six months”)
