Despite the many, many books on computer architecture already on the market, there is still disagreenment about the meaning of the word "architecture". Does it refer to the rules about how a system operates, or does it refer to the organization and implementation of an actual computer?
In a practical sense the definition hardly matters. The work-a-day issue most often addressed is how to ensure that a computer appears to obey program order when, in fact, it violates program order in pursuit of improved performance.
Complex cache structures and high speed data management algorithms are developed in the pursuit of greater speed. Yet always the question hangs in the air: can a programmer detect the difference between what was planned and what was implemented? Every design group dedicates people to the task of ensuring that the implementaiton does not violate the architecture. People are assigned to test an implemation Reviews are conducted. Analyses of new implementation techniques are made. Technical leaders who, throught skill and experience, have attained the status of project "guru", are called on to give their stamp of approval. Consequently, the topics of preserving data integrity and cache coherency get thoroughly examined. Yet despite all the efforts, there has naver been a practical method for ensuring that all "windows" of possible violations have been closed.
1. Seeing Architecture Failures
2. History
3. Basicsd
4. The Model
5. The Rule of Computation
6. The Rules of Program Order
7. Tge Rules of Atomicity
8. The Rules of Shynchronization
9. The Rules of Intrastatment Order
10. The Structure of Architectures
,etc.