https://www.righto.com/2023/01/reverse-engineering-conditional-jump.html
Intel introduced the 8086 microprocessor in 1978 and it had a huge influence on computing. I'm reverse-engineering the 8086 by examining the circuitry on its silicon die and in this blog post I take a look at how conditional jumps are implemented. Conditional jumps are an important part of any instruction set, changing the flow of execution based on a condition. Although this instruction may seem simple, it involves many parts of the CPU: the 8086 uses microcode along with special-purpose condition logic.
Most people think of machine instructions as the basic steps that a computer performs. However, many processors (including the 8086) have another layer of software underneath: microcode. One of the hardest parts of computer design is creating the control logic that directs the processor for each step of an instruction. The straightforward approach is to build a circuit from flip-flops and gates that moves through the various steps and generates the control signals. However, this circuitry is complicated, error-prone, and hard to design.
The alternative is microcode: instead of building the control circuitry from complex logic gates, the control logic is largely replaced with code. To execute a machine instruction, the computer internally executes several simpler micro-instructions, specified by the microcode. In other words, microcode forms another layer between the machine instructions and the hardware. The main advantage of microcode is that it turns design of control circuitry into a programming task instead of a difficult logic design task.
The 8086 uses a hybrid approach: although the 8086 uses microcode, much of the instruction functionality is implemented with gate logic. This approach removed duplication from the microcode and kept the microcode small enough for 1978 technology. In a sense, the microcode is parameterized. For instance, the microcode can specify a generic Arithmetic/Logic Unit (ALU) operation, and the gate logic determines from the instruction which ALU (Arithmetic/Logic Unit) operation to perform. More relevant to this blog post, the microcode can specify a generic conditional test and the gate logic determines which condition to use. Although this made the 8086's gate logic more complicated, the tradeoff was worthwhile.
(Score: 4, Funny) by Opportunist on Thursday January 26 2023, @12:01AM (2 children)
I noticed this when I noticed that this is way, way more interesting than it should be.
(Score: 4, Insightful) by RS3 on Thursday January 26 2023, @05:52AM (1 child)
Well, I've always known I'm a gEEk, so I'm not surprised that I find this interesting. I'm more surprised that anyone can reverse-engineer a friggin CPU using a microscope. And then have the time and tenacity to do the whole thing!
(Score: 3, Informative) by owl on Thursday January 26 2023, @12:58PM
In some of his HN comments about his posts Ken has said the method with which to have "the time" do do things like this is "to retire".
(Score: 3, Interesting) by bzipitidoo on Thursday January 26 2023, @01:58AM (21 children)
I thought the whole idea of microcode for the x86 architecture was introduced with the Pentium. Was talked of as a RISC core for a CISC CPU. To read that it was being done in the 8086 is startling.
I was also under the impression that it was the crappy design of the x86 arch that drove the move to a microcode implementation. It is my understanding that better designed architectures don't need microcode layers. The RISC-V, for instance, does that have microcode?
Maybe I'm confused about the meaning of microcode.
(Score: 3, Interesting) by RS3 on Thursday January 26 2023, @06:16AM (10 children)
I'm no expert on microprocessor design, but one thing I'd add to Ken's amazing write-up is: AFAIK, the direct digital logic is probably much faster than the microcode. But I speculate there are many tradeoffs, and maybe some of the microcoded functions, if implemented in logic gates, would have taken up much physical space on the die, and maybe too much to fit in the 40-pin package (considering that time period's feature-size technology).
My first PC had an 8086, and I quickly learned of and bought the significantly faster NEC "V30" replacement chip. Ken's article mentions NEC and something about an Intel lawsuit. I didn't read deeply, so I might have missed something. But I'm wondering if NEC refined the design and replaced some of the microcode with direct digital logic? I could do some research I suppose, but I'm not that invested in it.
Many refer to the "crappy design of the x86 arch"- what are some things you don't like, or know of that are not liked?
What little I've studied it, it seemed to incorporate some features of mainframes, including memory segmentation (that never bothered me, but I'm a nerd).
Microcode is simply code that runs inside of the microprocessor. Some instructions go directly into logic gates and trigger the function needed. But some go into the microcode unit, and generally take many more clock cycles to complete. As Ken alludes to, it's a trade-off / compromise.
AFAIK, early microprocessors had hard-coded microcode (in ROM). At some point CPUs seem to have started to allow microcode to be loaded into the CPU. I know at some point, maybe 10 years ago?, Linux started loading "drivers" that uploaded updated microcode into CPUs. I think part of it was for fixes for "rowhammer", "spectre", "meltdown", ... Not all CPUs have new microcode available. Also it seems that BIOS can contain and upload updated microcode. I remember Intel releasing a list of CPUs for which they were willing to make microcode patches available, but that didn't mean a system / motherboard maker would bother incorporating it and releasing an updated BIOS.
spectre-meltdown-checker.sh is pretty good at reporting if the CPU has the latest microcode.
A very brief websearch says that RISC-V is a specification for the architecture and instruction set for a CPU. It's up to whoever designs and builds a CPU whether they use microcode, or just implement everything in logic gates (hardware).
https://www.quora.com/Does-the-RISC-V-use-microcode [quora.com]
(Score: 3, Informative) by Rich on Thursday January 26 2023, @12:01PM (2 children)
Similar to what NEC did, Hitachi made a spin on the MC6809, the HD6309. It could go faster by clock rate and used less power (CMOS!), but had a lot of hidden features that Hitachi never revealed and which only later became known: Extra registers, 32-bit multiplication, and faster by cycles-per-instruction. I think the V20/V30 also had stuff that went beyond the speedups, like 8080 emulation.
I've always wondered what it is about the Japanese that they make these things neater and better - and then hide it.
(Score: 3, Interesting) by RS3 on Thursday January 26 2023, @06:08PM (1 child)
Very interesting question. As engineers, we seem to think along certain lines, including that it doesn't make much sense, to us anyway, to hide things. But as most of us have experienced, sales / marketing have their own ways and reasons. I've studied Japanese culture a bit, and what little I've studied just opens up more mysteries. But for sure, something about their culture influences these things.
I forget the whole history, but they love refining and enhancing things (as do I) far more than scrapping something and starting with NEW!. That's very evident in their car industry, for example.
Some years ago, mid-90s, I was in a small social group, one of whom was a Windows programmer. At that point I probably already had the book "Undocumented DOS". Aforementioned programmer told me of a function (method?) she worked on for weeks, only to find it was already done in Windows, but undocumented. So I got the book "Undocumented Windows". The reasons MS would do that should be pretty obvious (like, MS's programmers can use those APIs, but everyone else surely should not).
IIRC NEC made computers, so maybe they were giving themselves some extra functionality / efficiency / competitive advantage?
(Score: 3, Informative) by Joe Desertrat on Sunday January 29 2023, @01:51AM
For anyone interested, I just discovered both books are available on archive.org.
(Score: 5, Insightful) by bzipitidoo on Thursday January 26 2023, @06:22PM (6 children)
Why x86 sucks:
Too few registers, just 4 general purpose ones: AX, BX, CX, and DX.
The whole idea of doubling up by making the H and L each half of X (AH+AL is AX), what a waste of opcode space.
General purpose registers are not general enough. For instance, multiplication has to go through AX.
Division was so slow it was often faster to implement it with shift and add/subtract.
Many instructions are not needed, and just take up space and add to the complexity:
The packed decimal arithmetic stuff (AAA, AAD, AAM, AAS, DAA, DAS)
The string stuff (REPE CMPSB, REPNE SCASB, etc.),
The funky shortcut instructions that save so little you wonder why they bothered (LOOP, LOOPNE, TEST, PUSHF, POPF)
And speaking of PUSHF, the stack stuff (PUSH, POP, CALL, RET)
And also, speaking of the flags, the flag twiddling stuff (CLD, STD, CLC, STC, etc.).
On the matter of stacks, the x86 uses a load/execute paradigm, but the x87 floating point instructions use a shitty stack paradigm, WTF? Why didn't they stick with load/execute for the floating point math??
The segmented memory model is another stinker. For every address, let's waste 12 bits to use 32 bit addresses on a 20 bit space, yeah!
No instruction suitable for implementing a semaphore. Need an atomic test and set, as was introduced in the 486.
Virtualization is yet another area x86 has sucked for decades. Wouldn't need the likes of VMWare, had it been done well.
Further explanations:
Other processors from that era are guilty of many of the same things. But the x86 way tended to stink it up worse. Packed decimal arithmetic arose from thinking of computers as just fancy calculators, in which the user enters numbers in decimal, the machine performs just one operation, and returns an answer, also in decimal. Doesn't make sense to convert to binary and back for that. Nowadays, there is such an immense amount of calculation that the effort needed to convert to and from decimal is minuscule in comparison. However, compare how the 6502 does packed decimal. Instead of half a dozen special instructions hogging up the opcode space, the 6502 uses a flag to set or clear a decimal mode. The same ADD instruction handles both binary and packed decimal addition, depending on how that flag is set, none of this "ASCII Adjust" baloney. To be fair, the 6502 doesn't even have native multiplication and division, that has to be done with shifts and adds, but all the more reason maybe the x86 should've used a flag. Of course, packed decimal shouldn't be in there at all.
As for stacks, in particular, call stacks used to pass parameters, the problem with that is the massive inefficiency. If the architecture had had more general purpose registers to start with, parameters could be more easily passed all in the registers, no need to push and pop from a stack. The next issue with push and pop is that for each one, the stack pointer must be updated. It's basically, move, increment (increment the stack pointer), move, increment, move, increment. If memory is going to be used at all for this, better to do move,move,move,add 3, than have those 3 increments.
The string instructions suffer from algorithmic inadequacy and obsolescence. String searching can be done far, far faster than a dumb REPNE SCASB instruction pair. If Google relied on REPNE SCASB, their search engine web site would melt down under all the extra work that would take.
Flags should've been grouped into another register, maybe call it FX? Ditch instructions such as LAHF and SAHF, as the existence of FX makes something like MOV AH,FL the equivalent. Then, to change the flag settings, just use AND, OR, and XOR on FL, no need for a Clear and Set instruction for each flag.
(Score: 2) by RS3 on Thursday January 26 2023, @07:41PM
Wow, amazing answer, thank you so much! You make all great points.
I don't mean to defend x86, but it is the one I've done the most with. Did a tiny bit with 6502, 8085, Z80, 68xx and xxx... Hindsight is 20/20, for sure. Considering the time-frame and environment- mainframes morphing into superscalar super computers, many "minicomputers" coming into being, microprocessors doing their best to compromise everything and get into market, competition, sales/marketing pressuring engineering.
I've NEVER been a fan of stacks- just seems far too easy to lose track of what's where, and over the years we've seen so many bugs, and malware attacks, on the stack. I especially agree, and never understood, using stack operations to pass stuff to FPU. Best I can think is that it used to be a separate chip.
As far as the split registers, remember pretty much every peripheral chip was 8-bit, and the whole x86 was growing out of the 8-bit CPU world- that's what they knew.
I always thought better use of memory was a better way, like 6502, but as CPUs and caches have become so fast, using RAM in place of registers would slow things down a ton. So yes, many more internal registers is better.
Again, considering the timeframe, tons of BCD stuff was being done, and they just wanted to make the 8086 friendly to all that world.
We've come a long way, baby!
You're obviously someone who should be working on CPU development, if you're not already. I'm more of an analog EE. I've done enough digital to make stuff work, but I don't get in deep enough to consider what might be better design choices in CPU / system architecture. Heck, CPU aside, you can argue for a different system architecture, like Harvard or whatever others there are.
Have you ever thought about designing a CPU? Get some Xilinx (or equivalent) stuff and see what you can do?
Do you have a favorite uP?
(Score: 5, Insightful) by owl on Thursday January 26 2023, @08:38PM (2 children)
Do keep in mind that the 8086 was (per Wikipedia [wikipedia.org]) designed sometime between early 1976 and June 8, 1978. I even saw one pub (but no longer have a link to it) that claimed that most of the "architecture" (the higher level design) was done over a single weekend, and in a somewhat panic over the fact that the iAPX432 was not going well. The rest of the time would have been spent doing the actual implementation, tape out of the chip rubyliths, and debugging.
You have the benefit today of 47 years worth of research for how to design a better CPU architecture that simply was not available in 1976 (because none of the research had been done, nor published, yet). As well, the concept of RISC did not yet exist. It looks like IBM might have been working on the '801 in some overlapping timeframe, but general computer architecture knowledge of RISC as we know it today did not exist.
As well, many of the 8086's quirks are directly the result of it being intended to be able, after some simple machine translation, of running 8080 code. The AX/AH/AL dichotomy you reference exists to make execution of 8080 code possible. Same with the convoluted 'segment registers'. They allow for an 8086 aware OS to run 8080 code in its own area of memory, without it being able to stomp all over other memory areas.
Agreed. However, given the constraints of integration technology in 1976, adding more general purpose registers would likely have blown the transistor count beyond that which Intel, at the time, was capable of integrating onto a single chip that also fit a 40-pin package. So yes, too few, but likely because of other constraints.
Agreed, although at the time (1976) having particular functions constrained to using particular registers was common on other designs, and with RISC and its concept of fully general registers still a few years away from seeing any publishing, it is not surprising the registers were more special purpose than general purpose. And, as additional family members have arrived, the register set has become more general purpose (and for x86_64, larger).
Also agreed on your critique of all the decimal instructions. At least the 6502 with its "decimal flag" had launched before Intel started the 8086 design, and so packing in a bunch of "fix it" instructions to correct decimal math should have seemed a bit silly, even then, vs. a flag to just turn on proper BCD math.
The string copy and loop stuff likely exist due to it being a 1976 design, and existing designs in mini/mainframe computers were full of all kinds of "special instructions". The VAX 11/780 CPU even had a CRC instruction, in 1978. So these likely got included because "other designs are doing similar 'high value' instructions, we need them too..." and also likely thinking that these would be faster than coding a loop with the other instructions. Then, by the time they got to the point of having actual test chips to learn that their "special string copy or loop instructions" were not actually faster than a loop of regular instructions it was too late to backtrack and remove them.
No idea why the 8087 used a stack based model. There was probably some reason why the architect went with that design, but I do not recall ever encountering a publication that gave a reason.
BCD does not exist because it was hard to convert to binary and back. BCD exists because binary fractions can not accurately represent a whole set of common decimal fractions in a finite space. I.e., the value 0.1 (decimal) is an infinite repeating value in binary (just like the value 1/3 is 0.333... in decimal). BCD math exists so that the computers could perform math that had the same inaccuracy issues as what everyone was already accustomed to in base 10 vs. having a whole host of additional fractional values that can not be accurately represented. With that said, yes, Intel's way was silly vs. what MOS built on the 6502.
Well, in 1976, for a single chip CPU intended to be sold to a low cost market, I very much doubt anyone was thinking "virtualization" (granted, it existed, but in the million plus dollar market of IBM Mainframes). At the cost/power/die size of the 8086, no one likely gave one thought to "virtualization". With that said, when Intel did start to begin to think about it (386 and their Virtual-86 mode) they did half-ass it, so they get to take a knock there.
Some RISC chips have done this, dedicate one of the registers to flags (often the same ones that also dedicate a register to the PC) -- which also creates "special purpose registers" in a chip that should have "general purpose registers"...).
But, had Intel done this on the 8086, the set/clear flag instructions would have been two byte instructions, and would have needed to be read/modify/write as well, vs. all the existing instructions being single byte instructions. That and all existing designs in 1976 having specific "flag on/flag off" instructions, one pair per flag bit, and these exist likely because "that's the way it is done" (in 1976) and for not making flag set/resets a multi-instruction sequence (assuming no read/modify/write internal hardware).
The real issue is, for a 1976 design, it isn't that much worse than some of its distant cousins of the time. The problem is that it became the one that "won out" the shakeout and ended up becoming the majority architecture all the way up until AMD produced the x86_64 design. It did not take that many years past 1976 for the design limitations to really be hampering where computer systems could have been performance wise. But by that point it was too entrenched to be pushed out in favor of a better design.
(Score: 2) by bzipitidoo on Friday January 27 2023, @05:42AM (1 child)
> BCD exists because binary fractions can not accurately represent a whole set of common decimal fractions in a finite space.
Converting between binary and decimal is very easy, yes. As to the problems with decimal fractions, first, the x86 was integer math only, and second, if that's such a problem, just use a rational number representation, keep an integer numerator and denominator for each number. I think you're right about the decimal fractions being the reason for BCD, but even so, it was a silly concern. Another way to avoid the issue, in finance, is to keep monetary amounts in cents, not dollars. Stock markets used to split cents down to 8ths, now they are all in 10ths. Trivial to shift the decimal point another digit and represent monetary amounts with integers in units of a tenth of a cent.
> most of the "architecture" (the higher level design) was done over a single weekend, and in a somewhat panic
I've been delving into the history of computing a bit more, and one thing that stood out was what a tremendous hurry everyone was in. Rush the next shiny out the door, quick, never mind if it's less than fully polished, got to beat the competition. ALGOL, especially in 1958 when FORTRAN had recently shown that high level languages could be useful, was an attempt to standardize on a programming language, quick, before everyone went off and did their own thing and we end up with hundreds of programming languages. Obviously, that goal of ALGOL was dashed.
> for a 1976 design, it isn't that much worse than some of its distant cousins of the time.
Not much worse is still worse. I suggested to the professor teaching the architecture class that even if it's garbage today, maybe the x86 was okay for its time, and was told that no, it wasn't. Even by 1970s standards, it was poor.
> many of the 8086's quirks are directly the result of it being intended to be able, after some simple machine translation, of running 8080 code.
What are the reasons for such strenuous efforts to maintain backward compatibility? Why bother with 8080 code? To pander to intellectual property concerns, that's really what it comes down to. There was also a wish to not have to reinvent wheels, so to speak. Could offer a system sooner if existing binary code could be reused. The GNU project wasn't launched until the 1980s. No one could be sure of getting a binary for a different architecture, were the popular architectures of those times to be abandoned. Today, portability is greatly improved. Lot more stuff is open source, and compilers can cross compile. Hardware deficiencies have had to be eliminated, or the hardware vendor would go out of business. Now, porting a complete functioning OS with apps galore to a new architecture such as RISC-V is eminently doable. For those cases that for whatever reason are not portable, we have excellent emulators that have stretched into such areas as even recreating the sounds of the Apple II disk drive, a thing I would've thought too trivial and incidental to bother with. I do however know of one hack with the packed decimal arithmetic that, so far, I have not seen 6502 emulators get right. What happens if you do packed decimal arithmetic on an invalid value, such as FF? A real 6502 will see FF as 15*10+15=165, and do math on that anyway. For instance, FF/2 = 82! And if emulation is not enough, there's always the last resort of reverse engineering and recreating. If going to that much trouble, may as well update the graphics, if applicable. I can't imagine any 8080 software is worth that much effort, but if someone feels otherwise, it can be done. Anyway backward compatibility at the hardware level is no longer reason to compromise an architecture.
(Score: 2) by owl on Friday January 27 2023, @04:03PM
Without this, Intel would not be the monster company it is today. There is enormous value for the hardware maker in "backwards compatibility". It means that customer's can buy your new chip (thereby giving you sales, and profit) without simultaneously having to buy all new software for the new chip. Which encourages sales of new CPU's because customers can just "swap out to a new CPU" [1] for only the expense of the new CPU.
This is why, today, the newest i9 CPU can still run a program originally written for an 8086 CPU (provided the i9's running in real mode....).
This same adherence to backwards compatibility also helped Microsoft. By being able to "upgrade to a new windows version" without also replacing all one's existing software, the path to upgrading was easier, and brought MS more profits as well.
If every new Intel CPU had required all one's software be 'repurchased' or 'recompiled' (which is only possible if one has the source code and compiler) then this step would have been a huge barrier to upgrading to the "next Intel CPU" and would have seriously hampered sales.
Take the 386 as an example. It was released in 1985. On it's release day, it was capable of running existing i286 protected mode code, and existing MS DOS real-mode code. So users who wanted a faster machine could replace their CPU [1] and gain a faster system -- without replacing anything else (lower effort -- lower cost).
It took at least 5-6 years before any software was really available that took advantage of i386 protected mode operation (5-6 years being the time till Linux/BSD's started to appear for the i386). If, instead, the i386 had been protected mode only, with a world full of real-mode dos and 286 protected mode windows programs, many fewer users would have opted to buy a new i386 CPU, and Intel would have had far fewer profit with which to fund the development of the i486 (released April 1989, before any real mainstream software was using an i386 as much more than a "fast 8086").
That's the reason for the adherence to backwards compatibility. It drives much more profit than not having backwards compatibility.
[1] Yes - a very simplified description.
(Score: 2) by owl on Monday January 30 2023, @08:01PM (1 child)
Here [googleapis.com] is the most likely reason why Intel went with the plethora of "decimal adjust" instructions instead of doing what MOS did on the 6502 (flag to turn on "decimal mode"). MOS had patented the "flag to turn on 'decimal mode'" technique.
So Intel most likely went with all the extra instructions to avoid having to pay MOS for use of the patented "decimal mode".
(Score: 2) by bzipitidoo on Monday January 30 2023, @11:07PM
Oh for the love of mud! Yes, avoiding infringement strikes me as a much more likely explanation than that Intel engineers were that stupid. Patents, hindering progress since before the dawn of computing!
A further thought is that maybe they shrewdly guessed packed decimal arithmetic would prove to be unimportant, so it didn't matter much that the x86 implementation was so clunky. What has been the most recent use of packed decimal? I don't think it's finance. I'd guess video games, for scores, stats, rounds, levels and all the other numeric values dear to the players, when implemented on 1980s hardware that was being pushed to the limit. You can see this in where the scores roll over-- if it's some power of 10 minus 1, that strongly suggests packed decimal arithmetic, whereas if it's some power of 2 minus 1, that's definitely binary arithmetic. For such applications as spreadsheets and CAD, performance needs differ in ways that favor binary arithmetic.
(Score: 3, Interesting) by RS3 on Thursday January 26 2023, @06:20AM
Followup I like, from quora link:
(he used the word "precept" so it makes me want to believe him... :)
(Score: 2) by WeekendMonkey on Thursday January 26 2023, @08:24AM (8 children)
I could be wrong, but was the Pentium the first x86 CPU that supported microcode updates? That would have been the point where people became aware that microcode was part of Intel CPUs.
(Score: 2) by owl on Thursday January 26 2023, @01:05PM (7 children)
According to the Wikipedia page on Intel Microcode [wikipedia.org] it was the P6 architecture that first offered updatable microcode. P6 was Pentium Pro, which while it wasn't the original Pentium, the name was similar enough to become confused with its sibling in the years since introduction.
(Score: 2) by RS3 on Thursday January 26 2023, @05:51PM (6 children)
(Asking without websearch) - did the Pentium Pro morph into the Pentium II (2), then 3, ...?
(Score: 4, Informative) by owl on Thursday January 26 2023, @05:58PM (5 children)
Architecture wise, the Pentium Pro morphed into the Pentium 3 and has become the underlying base for the Core and i3-5-7 chips.
The Pentium 2 was an entirely new architecture that was very different from the Pro and that ended up becoming a dead end when the P3 morphed out of the Pentium Pro design.
(Score: 2) by RS3 on Thursday January 26 2023, @06:11PM (4 children)
Wow, thank you much, I did not know that. I assumed P3 grew out of P2, but I know P3 was much faster and generally cooler. Very interesting, thanks again.
(Score: 2) by owl on Thursday January 26 2023, @11:28PM (3 children)
Rereading my comment, I realize I got my 2's and 4's mixed up.
The Pentium 2 was a continuation of the Pentium Pro. P3 was also a continuation of the P2 architecture, which was itself a continuation of Pentium Pro.
The "odd" one out was Pentium 4 -- that was the Netburst arch [1], which was very different to the Pentium Pro/P2/P3 architecture.
P3 morphed into the first Core chips, which then led to the Core2, and then the current i5-7-9 family.
[1] The biggest difference was the P4 had massively longer pipelines, which it has been reported that Intel did this to allow for very high clock rates. Unfortunately the branch predictor was not good enough to make up for the deep pipe performance wise. So every miss-predicted branch resulted in a pipe flush and refill, which seriously hampered the chips ultimate performance. I.e., it spent a significant percentage of its time executing instructions that would be thrown away when the branch resolved and turned out to be different than the prediction.
(Score: 2) by RS3 on Friday January 27 2023, @01:05AM (2 children)
Okay, thank you again, great clarification. That's what I was thinking, but have barely paid attention to it over the years. I remember being surprised at how cool the P3s ran, and the P4 jumped way up in TDP. Interesting to remember and consider is software development, and that applies to your most excellent post about 8086 above. That multi-threading and multi-core software was still being developed 20-ish years ago. No point in having many cores when most software only ran on one core. Again, we've come a long way, and the hardware has improved along with software development.
You really know your stuff! Do you teach it, or work in uP design? If not, you both should.
Reading up on and trying to implement some mitigations for all of the spectre, meltdown, etc., iirc the branch prediction is one of the problems. I've never read anything explaining it well, and the vulnerability doesn't make sense to me, unless: the branch predictor can read memory that is supposed to be off limits to the current running context. And maybe worse, the RAM is protected, but maybe one of the cache layers is not included in the protection circuitry, which would make some sense as cache control would become very complex if it had to follow ownership boundaries, but at the same time it would be a terrible mistake.
When I was a kid in the early to mid 70s, my next door neighbor and good friend's dad was working at a major computer company. He had some of the original patents on what we call cache memory, including read-ahead, etc. All I know is he built an office in his basement, and there were very large drawings of tons of logic stuff. My dad was an EE, and being a nerd, I learned a lot of that stuff early, so I recognized the gates, but had no idea what it all was other than overwhelming. Friend's dad and some other guys were designing and building a minicomputer. At some point they rented some offices and I remember visiting one day, seeing lots of stuff connected, them programming feverishly, wide likely SCSI cables, etc. I have no idea what ever happened to them or the project.
(Score: 3, Informative) by owl on Friday January 27 2023, @02:19AM
BSEE with computer arch specialty. Would have been "Computer Engineering" but for the fact that my college was not yet IEEE accredited to call that "specialty" path a "computer engineering" path. Worked in the area for about 22 or 23 years, then shifted to something else for the last 9-10 or so.
And yes, if you add that up, that also means I'm near that point that Ken S. refers to as "how to have free time to do something like what he does".
(Score: 3, Interesting) by bzipitidoo on Monday January 30 2023, @11:28PM
Thanks! I have an interest in computer architecture, and several degrees in CS.
You're on the right track about Spectre. To increase performance, the hardware is designed to speculate first, and check access rights later. The idea is that the branch not taken doesn't have to be checked for access rights. But the speculation leaves traces. Malicious code can exploit this to read memory it shouldn't be able to access.
Don't be fooled by all the noise and hand wringing over security. When it comes right down to it, performance is more important, and both vendors and customers will make all kinds of excuses why it is okay to trade security for performance. Spectre could be squashed in an instant, but it would cost in performance.