In the early days of personal computing CPU bugs were so rare as to be newsworthy.
-
@gsuberland thanks, I was playing a bit fast and loose with the terminology. As I was writing these toots I reminded myself that entire books have been written just to model transistor behavior and propagation delay, and my very crude wording would probably give their authors a heart attack.
@gabrielesvelto haha for sure
-
@gabrielesvelto haha for sure
@gabrielesvelto I actually keep meaning to find a decent reference text on FET construction and modelling. I've got plenty on SI/EMI, power delivery, etc. but everything I've found for FETs has been the sort of thing that presumes you're either someone with a deep background in semiconductor physics or a professional semiconductor/ASIC engineer just looking for a reference text. very little out there for EE folks who are coming at it from the practical side.
-
@gabrielesvelto there was also no meaningful computer security nor much need for it in the days of 6502. it's much different when most computers are now connected to the internet and can be infected with malware within seconds of connecting.
@burnitdown @gabrielesvelto in the 70's, most issues were largely logic bugs, nowadays there are a larger proportion of timing/analogue issues.
-
@mdione yes, it's very complex, but motherboard firmware has a mechanism to load the new microcode right as the CPU is bootstrapped. That is even before the CPU is capable of accessing DRAM. All the rest of the UEFI machinery runs after that. Note that this early bootstrap mechanisms usually involves a separate bootstrap CPU, usually an embedded microcontroller whose task is to get the main x86 core up and running.
@gabrielesvelto wow, and where does it get the microcode from? Another computer within the computer? (turtles and all that
-
In the early days of personal computing CPU bugs were so rare as to be newsworthy. The infamous Pentium FDIV bug is remembered by many, and even earlier CPUs had their own issues (the 6502 comes to mind). Nowadays they've become so common that I encounter them routinely while triaging crash reports sent from Firefox users. Given the nature of CPUs you might wonder how these bugs arise, how they manifest and what can and can't be done about them. 🧵 1/31
@gabrielesvelto I was just thinking about those bugs and something crept up my neck when i thought "now add hallucinating AIs to all that". Pretty sure they're already used in CPU development to deal with the increasing complexity.
So the problem will become much worse than it already is.
for the article. Loved it. -
@gabrielesvelto I actually keep meaning to find a decent reference text on FET construction and modelling. I've got plenty on SI/EMI, power delivery, etc. but everything I've found for FETs has been the sort of thing that presumes you're either someone with a deep background in semiconductor physics or a professional semiconductor/ASIC engineer just looking for a reference text. very little out there for EE folks who are coming at it from the practical side.
@gsuberland @gabrielesvelto You mean you don’t want my college device physics textbook that starts with solving Schrödinger's equation for a hydrogen atom? They should not have allowed that class at 7am.
For the practical side, I really like Jacob Baker’s books.
-
In the early days of personal computing CPU bugs were so rare as to be newsworthy. The infamous Pentium FDIV bug is remembered by many, and even earlier CPUs had their own issues (the 6502 comes to mind). Nowadays they've become so common that I encounter them routinely while triaging crash reports sent from Firefox users. Given the nature of CPUs you might wonder how these bugs arise, how they manifest and what can and can't be done about them. 🧵 1/31
@gabrielesvelto As someone involved in CPU design in those days I would frame it slightly differently. The bugs were there but we did a better job of providing work arounds, usually through compiler changes to avoid code sequences that would trigger the bug. The FDIV bug was memorable because of how many Pentium chips were in customer hands before it was discovered.
-
@gabrielesvelto wow, and where does it get the microcode from? Another computer within the computer? (turtles and all that
@mdione @gabrielesvelto in the same flash that contains UEFI. There's a set of headers that describe what is in the flash. That typically includes microcode for the chip generations supported by the motherboard. For example, a board that supports Zen2 and Zen3 will have two microcodes in the flash and the one that matches the CPU installed will be used
-
In the early days of personal computing CPU bugs were so rare as to be newsworthy. The infamous Pentium FDIV bug is remembered by many, and even earlier CPUs had their own issues (the 6502 comes to mind). Nowadays they've become so common that I encounter them routinely while triaging crash reports sent from Firefox users. Given the nature of CPUs you might wonder how these bugs arise, how they manifest and what can and can't be done about them. 🧵 1/31
@gabrielesvelto @eniko I shouldn’t have read that while sick. Now every time I’m between sleep and wake, I have one of these feverish hallucinations that I’m a little worker inside a CPU core, waiting for a branch prediction to resolve, my hand on the button that dumps everything that was wrongly preloaded.
That’s a very boring job.
-
In the early days of personal computing CPU bugs were so rare as to be newsworthy. The infamous Pentium FDIV bug is remembered by many, and even earlier CPUs had their own issues (the 6502 comes to mind). Nowadays they've become so common that I encounter them routinely while triaging crash reports sent from Firefox users. Given the nature of CPUs you might wonder how these bugs arise, how they manifest and what can and can't be done about them. 🧵 1/31
-
J Jürgen Hubert shared this topic
P Pteryx the Puzzle Secretary shared this topic
