[HN Gopher] Modern Microprocessors a 90-Minute Guide
___________________________________________________________________
Modern Microprocessors a 90-Minute Guide
Author : codesuki
Score : 85 points
Date : 2021-05-02 10:55 UTC (12 hours ago)
(HTM) web link (www.lighterra.com)
(TXT) w3m dump (www.lighterra.com)
| walski wrote:
| Great post, last updated 2016. Might be helpful context on
| discussed architectures and processors.
| 7373737373 wrote:
| These kinds of optimizations always make me wonder whether they
| are worth it. Might it be more efficient to use these transistors
| for more, simple cores instead? Perhaps the property that most
| problems are so sequential makes timing/clock rate optimizations
| inevitable.
| posobin wrote:
| Previous discussions:
|
| 2018, 87 comments: https://news.ycombinator.com/item?id=18230383
|
| 2016, 12 comments: https://news.ycombinator.com/item?id=11116211
|
| 2014, 37 comments: https://news.ycombinator.com/item?id=7174513
|
| 2011, 30 comments: https://news.ycombinator.com/item?id=2428403
|
| This link has also appeared in 9 comments on HN, featuring
| threads on "Computer Architecture for Network Engineers", "X86
| versus other architectures" by Linus Torvalds, and "I don't know
| how CPUs work so I simulated one in code", also recommending a
| udacity course on how modern processors work
| (https://www.udacity.com/course/high-performance-computer-
| arc...): https://ampie.app/url-
| context?url=lighterra.com/papers/moder...
|
| Jason also has a couple of other interesting articles on his
| website, like intro to instruction scheduling and software
| pipelining
| (http://www.lighterra.com/papers/basicinstructionscheduling/) and
| the one I liked a lot and agree with called "exception handling
| considered harmful"
| (http://www.lighterra.com/papers/exceptionsharmful/).
| peter_d_sherman wrote:
| >"One of the most interesting members of the RISC-style x86 group
| was the Transmeta Crusoe processor, which translated x86
| instructions into an internal VLIW form, rather than internal
| superscalar, and used software to do the translation at runtime,
| much like a Java virtual machine. This approach allowed the
| processor itself to be a simple VLIW, without the complex x86
| decoding and register-renaming hardware of decoupled x86 designs,
| and without any superscalar dispatch or OOO logic either."
|
| PDS: Why do I bet that the Transmeta Crusoe didn't suffer from
| Spectre -- or any other other x86 cache-based or microcode-based
| security vulnerabilities that are so prevalent today?
|
| Observation: Intentional hardware backdoors -- would have been
| difficult to place in Transmeta VLIW processors -- at least in
| the software-based x86 translation portions of it... Now, are
| there intentional hardware backdoors in its lower-level VLIW
| instructions?
|
| I don't know and can't speculate on that...
|
| Nor do I know if the Transmeta Crusoes contained secret deeply
| embedded "security" cores/processors -- or not...
|
| But secret deeply embedded "security" cores/processors and
| backdoored VLIW instructions aside -- it would sure be hard as
| heck for the usual "powers-that-be" -- to be able to create
| secret/undocumented x86 instructions with side effects/covert
| communication to lower/secret levels -- and run that code from
| the Transmeta Crusoe's x86 software interpreter/translator --
| especially if the code for the x86 software
| interpreter/translator -- is open source and throughly
| reviewed...
|
| In other words, from a pro-security perspective -- _there 's a
| lot to be said about architecturally simpler CPU's_ -- regardless
| of how slow they might be compared to some of today's super-
| complex (and, ahem, _less secure_...) CPU 's...
| detaro wrote:
| AFAIK Transmeta's core was doing a lot of speculative execution
| stuff, so if it evolved until today I wouldn't bet on it also
| gaining issues like Spectre.
| peter_d_sherman wrote:
| It would be an interesting test, wouldn't it?
|
| See if Transmeta Crusoe is vulnerable to Spectre?
|
| But, even if it is... keep in mind that when running x86
| instructions, you still have the x86 translation software
| proxy layer... that means that could could grab any given
| offending / problem-causing x86 instruction -- when you
| encountered it, and recode the VLIW output from it to output
| a different set of native VLIW instructions -- that you knew
| were safe...
|
| In other words, with a Transmeta Crusoe -- if the x86
| translation layer is open source and you possess it (and can
| code / understand things) -- then you'll have some options
| there.
|
| Which is unlike a regular x86 CPU -- where the way it decodes
| and executes instructions -- cannot be changed in any way by
| the user...
| detaro wrote:
| Transmeta Crusoe is unlikely to be vulnerable, but it's
| Intel contemporaries aren't either. So you'd need to be
| looking at some hypothetical "today" version.
|
| An open system with such a design would indeed be
| fascinating (the original wasn't open, and Transmeta was
| big on their patents on this stuff). More flexibility than
| microcode patches too.
| peter_d_sherman wrote:
| >An open system with such a design would indeed be
| fascinating
|
| Agreed completely!
|
| >More flexibility than microcode patches too
|
| Agreed completely!
| Thorentis wrote:
| I would love a Bartosz Ciechanowski interactive article on
| microprocessors. It may be outside his domain though, since the
| visualisations and demo's would be less 3D model design, and
| more, perhaps, mini simulations of data channels or state
| machines that you can play through. Registers that can have
| initial values set, and then you can step through each clock
| cycle. Add a new component each few paragraphs and see how it all
| builds up. I did all this at university, but would love a
| refreshers that is as well made as his other blog posts.
| mhh__ wrote:
| I have been toying with making a game which is factorio-ish but
| literally for processors so potentially watch out for that (got
| a job now, though...)
| pantulis wrote:
| Isn't the material a little bit old? I remember reading about all
| this stuff in the University circa 1996.
|
| Edit: originally said "outdated".
| kens wrote:
| I wouldn't say outdated, but these ideas have a long history.
| Superscalar processors go back to Cray's CDC 6600 in 1966.
| Cache memory was used in the IBM System/360 Model 85 in 1969.
| Pipelining was used in the ILLIAC II (1962) and probably
| earlier. Branch prediction was used in the IBM Stretch (1961).
| Out-of-order execution and register renaming was implemented in
| the IBM System/360 Model 91 (1966).
|
| It's interesting to see how many CPU architecture ideas that we
| consider modern were first developed in the 1960s, and how they
| took a long time to move into microprocessor.
| FullyFunctional wrote:
| That's of course true, but it's might be misleading. OoO
| didn't take off until HPS came up with the reorder buffer
| (and enabled precise exceptions), with Pentium Pro being the
| first (and highly successful) implementation. Also, branch
| prediction has dramatically improved since stretch, McFarly's
| two-level was a breakthrough and the current state of the art
| is Seznec's TAGE-SC.
|
| My point is that there's still a lot of advancement made.
| pantulis wrote:
| You are right, outdated would imply not useful which is
| obviously not true. But all of this stuff was in my copy of
| Hennessy & Patterson from those days so it is not exactly new
| (because I am that old!).
| artemonster wrote:
| ahem, what HAS changed since then? besides new models & more
| updated "MHz" values and some tables with performances, nothing
| that is of interest to a compressed _introduction_ to the
| topic. So, personally, what would you have added to the
| article?
| pantulis wrote:
| Well, I wouldn't know, that's why I clicked on the article :P
|
| I said "outdated" in a wrong way, because this means is not
| valid today, which is obviously not the case.
| alblue wrote:
| I gave a presentation last year on this for QConLondon (before
| the lock down) and afterwards for the LJC virtually, if people
| prefer to listen/watch videos.
|
| https://speakerdeck.com/alblue/understanding-cpu-microarchit...
| klelatti wrote:
| Thank you for this - really engaging presentation.
| [deleted]
___________________________________________________________________
(page generated 2021-05-02 23:00 UTC)