2 ms·
HW/SW co-design is supposed to go like this: Never do anything in HW if you can do it in SW. Because HW is expensive and dangerously set in stone. Because SW
by dewster 10y ago
HW/SW co-design is supposed to go like this: Never do anything in HW if you can do it in SW. Because HW is expensive and dangerously set in stone. Because SW can be as complex as it needs to be and can be easily fixed / updated later. If you can't do it in a timely manner in SW, add the minimum safest HW to enable things. That's it.
Except for cosmic rays flipping bits, well designed processors aren't inherently unsafe. People and the software they write are unsafe (guns don't kill people...). Why put any SW onus on HW where it will almost always be more expensive and less flexible?
- nickpsecurity 10y agoYou're still ignoring the other tradeoff of safety where you use any cost-effective technique at any layer to meet your goals. Intel's blown millions of gates on stuff tgey dont need plus bad ideas for safety. The stuff Im mentioning is in thousands. I imagine it's cheaper, faster, and easier to change than what vendors already add. Besides, empirical evidence is strongly against your statements about people's competence or bad analogies to guns. Empirical evidence, even for OpenBSD or Bernstein, show the best coders can't consistently make software work on tooling and architectures you seem to prefer. Whereas, average people using Rust and/or Java CPU's are producing software faster with few to no exploitable defects. And both can be targeted to under 10,000 gates (ARM is 30k+).