By: Rob Thorpe (rthorpe.delete@this.realworldtech.com), October 31, 2006 1:38 pm
Room: Moderated Discussions
Linus Torvalds (torvalds@osdl.org) on 10/31/06 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/31/06 wrote:
>>
>>Given that hardware is much more difficult to get right
>>than software, hardware should "punt the hard stuff".
>
>Bullshit!
>
>Hardware is
>
>- simpler
>
>- easier to get right (both thanks to simplicity and
>because of development models enforced by economics)
>
>- non-cumulative (ie when you replace the CPU, you
>replace it, you don't mix it with older CPU's
>still running in the same system)
But this is only true because we use software to avoid very complex hardware. Of-course software *is* more complex, because it alleviates hardware of much complexity.
>As long as you live in a "hardware is more complex"
>mindset, you're totally out to lunch.
>
>Hardware is much simpler, as shown by the fact that
>you can actually even do correctness proofs for various
>subsystems of it (and sometimes even whole simple CPU's).
:) You won't get very far with that argument amongst hardware guys around RWT I reckon.
I've spent much of today working on connectors. With the backup of several companies, much time and careful research I should be able to come up with a suitable 3-way connector for the gadget I'm working on at present. Well, I hope anyway.
>You can literally find such correctness proofs for things
>like out-of-order scheduling (just google for "tomasulo
>correctness proof" and you get closer to a thousand hits)
>and memory hierarchy reordering. Look for things like
>"formal verification" etc.
>
>And if that isn't enough for you, just count lines of code,
>and compare the interactions between things like networking,
>graphical user interfaces, the kernel, and a web browser.
>The problem set for a piece of software simply tends to
>be infinitely bigger.
Yes. This is all very complex I know.
However it is complex exactly because the problems of computing have been turned into problems of software. Problems of unbounded complexity, or just high complexity are given to software.
If people were still relying on hardware to do what they needed then the MS-DOS v1 chip would just be in the process of tape-out right now.
>Quite frankly, I'm not even going to bother responding to
>the rest of your idiotic arguments, since they all seem to
>fall back on that provably wrong axiom of hardware being
>somehow "more complex". It is not true!
Yes it is. To implement the same functionality in hardware is much more complex than in software, in almost every case.
>Just from a verification angle, it is much easier
>to prove that a CPU core never visibly alters the memory
>ordering of an instruction stream, than it is to prove that
>the millions of programs that can potentially run on that
>piece of hardware are all ok with re-ordering.
I wouldn't argue with that. But that is not the issue.
Once a architecture is defined it is certainly much harder to change the software out-their than to make the new hardware work like the old hardware did.
This doesn't mean that it's a good idea from the outset to give the hardware a difficult job, it isn't.
>So not only is hardware usually simpler (with much stricter
>rules on "valid input" etc), it's also designed with much
>stricter verification goals - not (as you seem to believe)
>because it's harder to do, but simply because errors in it
>are more fatal, and re-spinning costs are much higher.
Well, I'd say that the length of the verification cycle is part of the reason why it is harder to do.
Verification of software is not really that different to hardware. If you had a 400 line program in a sensible language amenable to verification it would be just as difficult to verify as the same length of VHDL or verilog. The difference is that no-one would verify a program of this size because testing it is much more efficient.
>So for hardware, you do a lot of up-front testing, because
>that testing is (a) more possible in the first place due
>to the more limited environment and (b) economically much
>more important.
>
>(Btw, the economic factors are obviously also a big part
>of why software is more complex - it can afford to
>be more complex. You'd simply never do something like a
>web browser in hardware, because everybody immediately
>understands that it would be insane to do).
>
>So dont' get me wrong. Hardware has its own set of reasons
>for being hard to do, but "more complex" sure ain't one of
>them.
My point is that to do a similar thing in hardware is more complex than in software.
To give an example I came across recently. Company A make a communications gadget, company B make an almost identical gadget. Both sell to company D.
Company A decided to implement much of the lower levels of the protocol of said gadget in software. Company B decided to put rather more in hardware.
A change has been made to the protocol. As a result of this change company A have produced, tested and verified a new firmware update. Company B have had to redesign silicon, re-verify it, make more modules, distribute them *and* make and release new firmware. This is costing company B lots of money, and it's going slowly. As a result company D is not at all happy with them.
This is a demonstration of what I'm saying: If you have a feature X that can be done in software, unless speed is of the essence, or it's fantastically weird and low-level it should be done in software.
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/31/06 wrote:
>>
>>Given that hardware is much more difficult to get right
>>than software, hardware should "punt the hard stuff".
>
>Bullshit!
>
>Hardware is
>
>- simpler
>
>- easier to get right (both thanks to simplicity and
>because of development models enforced by economics)
>
>- non-cumulative (ie when you replace the CPU, you
>replace it, you don't mix it with older CPU's
>still running in the same system)
But this is only true because we use software to avoid very complex hardware. Of-course software *is* more complex, because it alleviates hardware of much complexity.
>As long as you live in a "hardware is more complex"
>mindset, you're totally out to lunch.
>
>Hardware is much simpler, as shown by the fact that
>you can actually even do correctness proofs for various
>subsystems of it (and sometimes even whole simple CPU's).
:) You won't get very far with that argument amongst hardware guys around RWT I reckon.
I've spent much of today working on connectors. With the backup of several companies, much time and careful research I should be able to come up with a suitable 3-way connector for the gadget I'm working on at present. Well, I hope anyway.
>You can literally find such correctness proofs for things
>like out-of-order scheduling (just google for "tomasulo
>correctness proof" and you get closer to a thousand hits)
>and memory hierarchy reordering. Look for things like
>"formal verification" etc.
>
>And if that isn't enough for you, just count lines of code,
>and compare the interactions between things like networking,
>graphical user interfaces, the kernel, and a web browser.
>The problem set for a piece of software simply tends to
>be infinitely bigger.
Yes. This is all very complex I know.
However it is complex exactly because the problems of computing have been turned into problems of software. Problems of unbounded complexity, or just high complexity are given to software.
If people were still relying on hardware to do what they needed then the MS-DOS v1 chip would just be in the process of tape-out right now.
>Quite frankly, I'm not even going to bother responding to
>the rest of your idiotic arguments, since they all seem to
>fall back on that provably wrong axiom of hardware being
>somehow "more complex". It is not true!
Yes it is. To implement the same functionality in hardware is much more complex than in software, in almost every case.
>Just from a verification angle, it is much easier
>to prove that a CPU core never visibly alters the memory
>ordering of an instruction stream, than it is to prove that
>the millions of programs that can potentially run on that
>piece of hardware are all ok with re-ordering.
I wouldn't argue with that. But that is not the issue.
Once a architecture is defined it is certainly much harder to change the software out-their than to make the new hardware work like the old hardware did.
This doesn't mean that it's a good idea from the outset to give the hardware a difficult job, it isn't.
>So not only is hardware usually simpler (with much stricter
>rules on "valid input" etc), it's also designed with much
>stricter verification goals - not (as you seem to believe)
>because it's harder to do, but simply because errors in it
>are more fatal, and re-spinning costs are much higher.
Well, I'd say that the length of the verification cycle is part of the reason why it is harder to do.
Verification of software is not really that different to hardware. If you had a 400 line program in a sensible language amenable to verification it would be just as difficult to verify as the same length of VHDL or verilog. The difference is that no-one would verify a program of this size because testing it is much more efficient.
>So for hardware, you do a lot of up-front testing, because
>that testing is (a) more possible in the first place due
>to the more limited environment and (b) economically much
>more important.
>
>(Btw, the economic factors are obviously also a big part
>of why software is more complex - it can afford to
>be more complex. You'd simply never do something like a
>web browser in hardware, because everybody immediately
>understands that it would be insane to do).
>
>So dont' get me wrong. Hardware has its own set of reasons
>for being hard to do, but "more complex" sure ain't one of
>them.
My point is that to do a similar thing in hardware is more complex than in software.
To give an example I came across recently. Company A make a communications gadget, company B make an almost identical gadget. Both sell to company D.
Company A decided to implement much of the lower levels of the protocol of said gadget in software. Company B decided to put rather more in hardware.
A change has been made to the protocol. As a result of this change company A have produced, tested and verified a new firmware update. Company B have had to redesign silicon, re-verify it, make more modules, distribute them *and* make and release new firmware. This is costing company B lots of money, and it's going slowly. As a result company D is not at all happy with them.
This is a demonstration of what I'm saying: If you have a feature X that can be done in software, unless speed is of the essence, or it's fantastically weird and low-level it should be done in software.