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.
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
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
"Also, software should not depend on processor ordering in situations where
the system hardware does not support this memory-ordering model."
When you get lemons, you make lemonade.
When you get hardware, you make software.