8 ms·
Microprocessor Design (2017)
- phoe-krk 9y agoI find it highly ironic that this link has appeared on Hacker News literally hours after Meltdown and Spectre vulnerabilities have been officially announced and described.
- rubayeet 9y agoNot a coincidence. Articles with the words CPU or Microprocessor in the title are getting a lot of attention on HN (including a 2016 article on CPU bugs).
- phoe-krk 9y agoHonestly, I find buzz like this to be extremely bad taste. It is trivially simple to post links like that on HN and wait for the "ha, Intel, this is how you should have been doing things!!!1". If this bug is really present in all chips since 1995, then where have all these people been for the last 22 years? If they're so competent about CPU design, why haven't we seen literally tens of Intel competitor startups pop up and succeed?
- aidos 9y agoPosting the article itself isn't in bad taste, though a comment like your example one would be, and would hopefully be downvoted. It's only natural that you get some articles like these posted. For many of us, we've read a few details about the bugs raised this week and thought to ourselves — "man, CPUs are so complicated, how do they even managed to make them work at all?" An article like this helps to answer some of the questions for those of us interested in finding out more.
- CthulhuOvermind 9y agoI can comment on this. Hardware is a long and tedious process. CPU design is an extra level of difficult on top. In my field, it is routine to hire people in late 40s/50s to make CPUs. I'm in my late 20s, and viewed as a weird specimen. In my career I've made a armv8 CPU and now work RV64. It takes a couple of years to get a guy from uni into working shape. And that's just to teach him how to do 1-2 tasks in his field. If verification, this usually is coverage specification and test writing. Combine this with a cpu project duration average of 5ish years and it's quickly evident that you won't beat someone with a startup. In my office today, in a team of 10, no one, other than me is under 40.
- xemdetia 9y agoSomething that always strikes me is how insanely complex it is to even experiment as an outsider to the university path. From my understanding a relatively simple 10+ year ago tech ASIC is still going to run like $10k USD for a shared die prototype from limited providers, compared to software, component level systems design, or even mechanical devices where you can get a local machine shop involved or at least do some parts of it yourself. Yes, FPGA's exist but they are not even relevant when you are talking about the skillset/engineering discipline to make the FPGA itself and actually producing the physical thing.
- pjc50 9y agoCPUs are a very hard market to break into, for reasons mostly unrelated to technology. It's like asking why there haven't been so many operating system competitors to Windows.
- Cthulhu_ 9y ago> why haven't we seen literally tens of Intel competitor startups pop up and succeed? ARM-based startups have conquered 95% of the smartphone market and significant chunks of TV's, set-top boxes, cars, tablets, etc since 1995, totaling at about 15 billion ARM-based chips a year (compared to Intel's 500ish million / year). That's pretty successful, right?
- InitialLastName 9y agoARM-based startups like Qualcomm, Broadcom, and Apple? Who are these ARM-based startups you speak of?
- monocasa 9y agoA lot of Maxim's offerings, at least, are startups that they acquired. That seems to be a large chunk of their business model, acquire rather than put in all the R&D themselves. The specific chips I know of have ARM cores in them.
- InitialLastName 9y agoI wouldn't call Maxim a startup, nor would I guess that their market reach approaches anything like the 95% figure above.
- monocasa 9y agoMaxim acquires startups, not is a startup themselves. A good chunk of their products are one offs from firms that won the startup lottery.
- JdeBP 9y agoIntel itself tried to do a better CPU design. It was called the Itanium. * https://news.ycombinator.com/item?id=16070020 https://news.ycombinator.com/item?id=16070020
- hajile 9y agoYou'd have a hard time convincing me of that. They had ALREADY tried the Itanium architecture with the i860 and knew that it was horrifically slow for almost all applications. https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860 I'd also look at the market of the time. Itanium was in the tech press everywhere. HP-RISC and Alpha were abandoned. MIPS moved into the low-power market. Resources for SPARC and POWER seem to have been cut. Everyone making the top-level decisions was convinced that Itanium and a sufficiently smart compiler were the solution (hint: the halting problem prevents general static analysis as Turing discovered in the 1930s). Everyone that is, except AMD and Intel. AMD had no alternatives, so they pulled the x64 rabbit out of their hat. Meanwhile, Intel hadn't slowed down their x86 work. When Itanium fell through (like history indicated it would), Intel was out some R&D and some marketing, but had effectively killed off all their RISC competition (it took a decade or more to catch up). Intel then proceeded to Monopolize AMD almost out of existence (and only paid a couple billion in return for their hundreds of billions in profit). It all works out way too conveniently for Intel.
- fellellor 9y agoItanium supposedly had a "better" 64 bit architecture, but required software creators to incorporate major changes in their design. Also they would have broken backward compatibility with 32 bit software. Since x86 was already popular, the market went along with the extended x86-64 architecture.
- JdeBP 9y agoAlthough the supposedly 2016 article was in fact last updated today, and discusses the recently disclosed problems.
- senozhatsky 9y ago"This page was last edited on 23 January 2017, at 15:28."
- kowdermeister 9y agoThis was probably posted because of it, so people can understand more how processors work and learn about the challenges if one wanted to design one.
- xattt 9y agoThe metaphors go from extremely simple to complex in the matter of a chapter. I’m not quite sure who the target audience is.
- Cthulhu_ 9y agoDid you read the blurb? > [...] students in computer science or computer or electrical engineering who are in the third or fourth years of an undergraduate degree > [...] The reader should have prior knowledge in Digital Circuits and possibly some background in Semiconductors [...]
- xattt 9y agoThen why does the author use a truck analogy at the start? An student with that type of background would most likely be able to understand the concepts more abstractly.
- dschuetz 9y agoPlease, let's not design and implement a hundred different architectures now. It's hard to keep track of Intel bugs alone already. The whole Von-Neumann system architecture is way too old for today's problems. We need heterogeneous systems. There needs to be a discussion on fundamental issues regarding which architectures are fit for what purposes.
- tanilama 9y ago> The whole Von-Neumann system architecture is way too old for today's problems. Why?
- dschuetz 9y agoBecause instructions and data share the same memory space in general? Potentially, in such a system architecture any bug or bad implementation might lead to memory leaks from the whole memory range.
- sparkie 9y agoAmdahl's law. The von Neumann bottleneck continues to get bigger and bigger with each iteration. We can do far more calculations in the same amount of time on a chip, due to the increasing number of transistors we can fit on them, and also improvements in the internal designs (superscalar architectures, etc). The speed of memory access however, has only been increasing at marginal rates in comparison, and now we have increasing contention for execution units in the processor to access it as we increase the number of distinct cores. Caching, prefetching, etc. have partially helped to mitigate some of the problems, but only as far as you can avoid cache misses (common in object oriented code, due to frequent pointer dereferencing). We're still at the stage, with all these technologies, that the VNB is what's preventing us from doing more in the same amount of time. Writing high-performance code is also difficult as often the hardware specializations are inaccessible to a programmer, and he has to rely on the compiler/microassembler to do the right thing. Often this means designing code in ways to suit the CPU (eg, vectorizing all your data), rather than to suit the programmers (eg, OOP). We should really be aiming towards NUMA, many-core processors with high-speed message passing between cores, and a programming model which suits development over that kind of architecture (eg, the Actor model).
- deleted 9y ago[deleted]
- nerdponx 9y agoKnowing next to nothing about microprocessor design, I suppose the Mill architecture would also be vulnerable?
- Symmetry 9y agoI'm genuinely not sure. Mills certainly speculate instruction just like the next guy but they handle memory access faults differently. Instead of stopping the world on a bad read they just tag the data as bad. With speculative execution and stop the world you have to supress stopping the world until the speculation is resolved or risk interrupting good programs because your branch predictor made a mistake. But there's no reason for a Mill to suppress tagging. Loading from invalid data should just short circuit to producing more invalid data instead of actually producing a load so I don't see why there should be data ex-filtration from arbitrary memory locations as in Spectre. And they're certainly not intensely optimizing everything for every last drop of performance in the way Intel did to suffer from Meltdown. I wouldn't be surprised if there was some sort of Spectre-esque speculative attack you could run against current Mill designs to get some data out but probably not from arbitrary memory locations? But all the above is pure speculation.
- deleted 9y ago[deleted]
- PyComfy 9y agohaven't played it but there is MHRD on steam which is a game about designing a CPU. http://store.steampowered.com/app/576030/MHRD/ http://store.steampowered.com/app/576030/MHRD/