4 ms·

Detailed reply below, but I'm going to agree with the other child and say that you're vastly under-educated in this area and arguing from a point of ignorance.

by jawnv6 11y ago

Detailed reply below, but I'm going to agree with the other child and say that you're vastly under-educated in this area and arguing from a point of ignorance. CPU's are not written in a "functional" manner, any similarity is superficial at best and certainly not anything to base practices on. CPU's are relatively, not completely as you so carelessly asserted, bug-free through a development process with high standards. > As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way, because you know, they really needed this to work. HDL's are not "only" logic gates. Have you developed anything substantial in a HDL? I'd think the lack of recursion alone would cleanly delineate them from anything functional. My own work with FPGA's started without language, literally wiring things together in a GUI. That's the legacy ASIC design descended from, not a functional ivory tower. > That's why CPUs don't have bugs - they picked a better starting language than C, with a principled approach (logic) that is amenable to mathematical verification. iHDL is not a "better" language than C. Imagine having to specify the exact opcode you wanted the linker to emit for a particular instruction, that's the level of dipping into implementation details that HDL's allow. It's not uncommon to have "behavioral" code that is checked in concert with the rest of the design, "implementation" code representing the actual circuit, and some poor engineer tasked with signing off that the two are equivalent without the ability to simulate all inputs. Formal verification is a specialized technique that is only used on vanishingly small parts of the design. At no point in the consideration of an HDL for a new design is "amenable to mathematical verification" given weight. Another slight problem with your argument: CPU's DO have bugs. Google up "Intel Errata" and prepare for your stone castle to be torn apart. If you'd like to duck this and say that they're esoteric and don't matter, I'd really like to know what you think about the TSX-killing errata that's essentially set back parallel computing in a measurable way. Why wasn't this subjected to formal verification magic? > Guess what - functional programming languages are also increasingly more amenable to mathematical verification. Once this is popularized, you'll be delegated to maintaining the old sand castles from dinosaurs while we will be building stone castles over here. Join us. :) You don't understand what you're comparing to with enough fidelity to trust the end result. The easiest way to imagine a CPU design team is that it's Just Another Software project. The only extra constraints are that you can't run it full speed. You can simulate a 5GHz chip at 5Hz with SW-like visibility. At some point in the alpha, the team will spend a few million dollars to wait 8 weeks to get a few dozen test chips that will run at full speed, with near-zero visibility. So the question is how much extra unit testing would you do, on each of those models, with those kind of timelines. Formal verification doesn't make a dent on modern CPU design. It's all these extra considerations (read:bodies) taken during the design process that make up the gap. Please, try to educate yourself before going off on half-baked assumptions based on superficial similarities.

innguest 11y ago
Thanks for the informative reply. A CPU might not be functional as in Haskell with recursion and types, but it is a weaker kind of functional in the sense that given the same inputs it will return the same outputs - it has no state, and even memory access is just a function to set or read from an address and those functions never fail, never throw null pointer exceptions, etc. Do you disagree that a circuit is more an example of data-flow paradigm than an example of the state-machine paradigm? For a CPU to take the next step and decide what work to do at each clock cycle it needs only its inputs - it need not inspect the previous work it did in order to decide what to do next - it simply reads the next opcode the user wants to execute, and does it. That means it is referentially transparent. Which means it's tons more functional than C. I will grant you though that I was wrong that CPUs never have bugs, they do and I appreciate your opening my eyes to that. Lots of interesting reading ahead of me. Let me ask you, then. Do you think CPUs have so few bugs just because of more stringent testing, or because of referential transparency and the fact that they a CPU is not a state machine like a C program is?
- jawnv6 11y ago
  > it is a weaker kind of functional in the sense that given the same inputs it will return the same outputs - it has no state, I'm trying to imagine what paucity of knowledge about a CPU you can have to say something like "no state." Registers? The program counter? The megabytes of caches? You've got to be stretching the definition of "state" beyond recognition. Each CPU has at least a few dozen, up to a few hundred, fuses covering everything from PLL tuning values to the vendor string. CPU's are not deterministic, in the sense that given the same inputs it will return the same outputs. Have you never powercycled a system to have it come up when no "state" was changed? A single degree difference can cause transitions to different power states. A PLL might not lock on the same cycle. Electrical systems are ugly nightmares and it's just speaking to the quality of the abstractions that have been presented to you that you think otherwise. > and even memory access is just a function to set or read from an address and those functions never fail, never throw null pointer exceptions, etc. Do you disagree that a circuit is more an example of data-flow paradigm than an example of the state-machine paradigm? I'm not sure how to answer this. Everything's built as a series of state machines. Crack open a PRM and see state machines explicitly drawn out with all their transition arcs. If we're talking about generic "circuits," take a look at something like the PCIe LTSSM. PCIe is all about shoveling data from point to point, pretty dataflow-oriented, but it's behavior is specified as a combination of state machines. > For a CPU to take the next step and decide what work to do at each clock cycle it needs only its inputs - it need not inspect the previous work it did in order to decide what to do next - it simply reads the next opcode the user wants to execute, and does it. That means it is referentially transparent. Which means it's tons more functional than C. You're not talking about a "CPU" here. You're talking about the abstraction that a CPU provides about how it's assembly instructions will be interpreted. Normally it's not really an issue, people blur that all the time, but you're using statements about the abstraction to talk about the concrete. Map instead of the territory. If CPU's were implemented in the fashion you describe they'd be incredibly slow. They HAVE to consider what they did before, what they're doing next, and how it all relates to the current instruction. There are prefetch blocks that just watch traffic, completely unaware of the actual instruction stream, just looking for patterns and optimistically pulling things into the cache. There's a ton of state just to keep up the illusion that things are happening sequentially, instruction by instructions, instead of out-of-order as possible to keep execution units humming. > I will grant you though that I was wrong that CPUs never have bugs, they do and I appreciate your opening my eyes to that. Lots of interesting reading ahead of me. Let me ask you, then. Do you think CPUs have so few bugs just because of more stringent testing, or because of referential transparency and the fact that they a CPU is not a state machine like a C program is? CPU's have so few bugs because of more stringent testing. There is no functional magic happening. It's just hard work by a lot of talented people. Please respect their effort.

by jawnv6 11y ago

innguest 11y ago

Thanks for the informative reply. A CPU might not be functional as in Haskell with recursion and types, but it is a weaker kind of functional in the sense that given the same inputs it will return the same outputs - it has no state, and even memory access is just a function to set or read from an address and those functions never fail, never throw null pointer exceptions, etc. Do you disagree that a circuit is more an example of data-flow paradigm than an example of the state-machine paradigm? For a CPU to take the next step and decide what work to do at each clock cycle it needs only its inputs - it need not inspect the previous work it did in order to decide what to do next - it simply reads the next opcode the user wants to execute, and does it. That means it is referentially transparent. Which means it's tons more functional than C. I will grant you though that I was wrong that CPUs never have bugs, they do and I appreciate your opening my eyes to that. Lots of interesting reading ahead of me. Let me ask you, then. Do you think CPUs have so few bugs just because of more stringent testing, or because of referential transparency and the fact that they a CPU is not a state machine like a C program is?

jawnv6 11y ago
> it is a weaker kind of functional in the sense that given the same inputs it will return the same outputs - it has no state, I'm trying to imagine what paucity of knowledge about a CPU you can have to say something like "no state." Registers? The program counter? The megabytes of caches? You've got to be stretching the definition of "state" beyond recognition. Each CPU has at least a few dozen, up to a few hundred, fuses covering everything from PLL tuning values to the vendor string. CPU's are not deterministic, in the sense that given the same inputs it will return the same outputs. Have you never powercycled a system to have it come up when no "state" was changed? A single degree difference can cause transitions to different power states. A PLL might not lock on the same cycle. Electrical systems are ugly nightmares and it's just speaking to the quality of the abstractions that have been presented to you that you think otherwise. > and even memory access is just a function to set or read from an address and those functions never fail, never throw null pointer exceptions, etc. Do you disagree that a circuit is more an example of data-flow paradigm than an example of the state-machine paradigm? I'm not sure how to answer this. Everything's built as a series of state machines. Crack open a PRM and see state machines explicitly drawn out with all their transition arcs. If we're talking about generic "circuits," take a look at something like the PCIe LTSSM. PCIe is all about shoveling data from point to point, pretty dataflow-oriented, but it's behavior is specified as a combination of state machines. > For a CPU to take the next step and decide what work to do at each clock cycle it needs only its inputs - it need not inspect the previous work it did in order to decide what to do next - it simply reads the next opcode the user wants to execute, and does it. That means it is referentially transparent. Which means it's tons more functional than C. You're not talking about a "CPU" here. You're talking about the abstraction that a CPU provides about how it's assembly instructions will be interpreted. Normally it's not really an issue, people blur that all the time, but you're using statements about the abstraction to talk about the concrete. Map instead of the territory. If CPU's were implemented in the fashion you describe they'd be incredibly slow. They HAVE to consider what they did before, what they're doing next, and how it all relates to the current instruction. There are prefetch blocks that just watch traffic, completely unaware of the actual instruction stream, just looking for patterns and optimistically pulling things into the cache. There's a ton of state just to keep up the illusion that things are happening sequentially, instruction by instructions, instead of out-of-order as possible to keep execution units humming. > I will grant you though that I was wrong that CPUs never have bugs, they do and I appreciate your opening my eyes to that. Lots of interesting reading ahead of me. Let me ask you, then. Do you think CPUs have so few bugs just because of more stringent testing, or because of referential transparency and the fact that they a CPU is not a state machine like a C program is? CPU's have so few bugs because of more stringent testing. There is no functional magic happening. It's just hard work by a lot of talented people. Please respect their effort.