"Rule #1 in kernel programming: don't *ever* think that things actually work the way they are documented to work. The documentation is a starting point, nothing else."
As an author of a number of specs that have later gone through the sausage grinder that churns out end-customer documentation, I have to say, it's all too true. Heck, the specs themselves often don't reflect what was actually implemented, and corrections don't always get applied in a timely manner. The stuff that ends up in the end customer documentation is rarely improved (at least accuracy-wise) by the process that generated it from the original specs.
When product cycles are measured in months, there simply aren't enough hours in the day to get to a vanishingly small defect rate oh these, especially when there's only 100s (or if we're really, really lucky, 1000s) of people reading these documents at that depth. It's a tradeoff.
For me, I make specs, and then i code to meet to these specs.
In very few situations, especially when it is small code that is easy
and trivial to find out, I dont use any spec. (But i prefer to be
as concise as possible, and also write a few lines of useful
help)
I was mainly referring to hardware specs and hardware documentation, as I believe Linus was. Code specs are often much easier to get right. If nothing else, even if a software spec is "wrong," it's still easier to write code that conforms to the software spec than it is to design hardware that hits the desired frequency, area and power targets that meet the written hardware spec. A "wrong" hardware spec is much harder to work with.
There are many times where an innocuous one-liner in a hardware spec would lead to a grossly inefficient implementation, even if it's easy to model in software. A slight change to "how things works" ends up with a much better over-all solution. Unfortunately, even if that change is negotiated with the spec writer, it's quite likely that the spec doesn't get updated right away, or the end-user documentation writers start writing from an out-of-date spec. And then there's just the outright bugs that are minor enough such that they won't get fixed and we live with software workarounds. (Linus was complaining about this last range of issues, I believe.)
I don't expect this happens as often on mainstream CPUs, at least relative to the complexity. There are a lot of eyes on mainstream CPUs, and plenty of revenue associated with them to fund extensive documentation efforts. I expect it happens rather often with the lower-volume and more widely varied pieces, such as motherboard chipsets, add-in cards, embedded processors and so forth. Embedded processors have tons of fun going on with their on-chip hardware. Trust me. :-)
*sigh* Too true
As an author of a number of specs that have later gone through the sausage grinder that churns out end-customer documentation, I have to say, it's all too true. Heck, the specs themselves often don't reflect what was actually implemented, and corrections don't always get applied in a timely manner. The stuff that ends up in the end customer documentation is rarely improved (at least accuracy-wise) by the process that generated it from the original specs.
When product cycles are measured in months, there simply aren't enough hours in the day to get to a vanishingly small defect rate oh these, especially when there's only 100s (or if we're really, really lucky, 1000s) of people reading these documents at that depth. It's a tradeoff.
--
Program Intellivision and play Space Patrol!
The thing however is how you
The thing however is how you look at it.
For me, I make specs, and then i code to meet to these specs.
In very few situations, especially when it is small code that is easy
and trivial to find out, I dont use any spec. (But i prefer to be
as concise as possible, and also write a few lines of useful
help)
Code specs are often easier...
I was mainly referring to hardware specs and hardware documentation, as I believe Linus was. Code specs are often much easier to get right. If nothing else, even if a software spec is "wrong," it's still easier to write code that conforms to the software spec than it is to design hardware that hits the desired frequency, area and power targets that meet the written hardware spec. A "wrong" hardware spec is much harder to work with.
There are many times where an innocuous one-liner in a hardware spec would lead to a grossly inefficient implementation, even if it's easy to model in software. A slight change to "how things works" ends up with a much better over-all solution. Unfortunately, even if that change is negotiated with the spec writer, it's quite likely that the spec doesn't get updated right away, or the end-user documentation writers start writing from an out-of-date spec. And then there's just the outright bugs that are minor enough such that they won't get fixed and we live with software workarounds. (Linus was complaining about this last range of issues, I believe.)
I don't expect this happens as often on mainstream CPUs, at least relative to the complexity. There are a lot of eyes on mainstream CPUs, and plenty of revenue associated with them to fund extensive documentation efforts. I expect it happens rather often with the lower-volume and more widely varied pieces, such as motherboard chipsets, add-in cards, embedded processors and so forth. Embedded processors have tons of fun going on with their on-chip hardware. Trust me. :-)
--
Program Intellivision and play Space Patrol!