Prev: CPU <> Memory chip communication interface
Next: interrupting for overflow and loop termination
From: Joe Seigh on 14 Sep 2005 08:09 Alexander Terekhov wrote: > Hey Mr. andy.glew(a)intel.com, > > you better fix the specs, really. It's not funny anymore. > > http://msdn.microsoft.com/msdnmag/issues/05/10/MemoryModels/default.aspx > It's pretty clear from Andy's comments and from the technical documentation that Intel's technical writers aren't entirely sure who their audience actually is and mix up the specification, which is of interest to programmers, and the implementation, which is of interest to engineers. Andy's last comment, which appeared to me to be about implementation, certainly didn't help. It also doesn't help that Intel has a tradition of not architecting multi-processing support and do it on the fly as Intel adds in multi-processing support, in clear contrast to how other companies have documented multi-processing support in their architectures. You had companies building Intel based multi-processors before Intel even supported multi-processing, which meant the memory model they implemented may or may not have matched what Intel later documented as the official memory model. This is apparently now a tradition and there's a comment to this effect in the Intel documentation. "Also, software should not depend on processor ordering in situations where the system hardware does not support this memory-ordering model." -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. |