Intel x86 cores have had Last Branch Records (LBRs) and Branch Trace Store (BTS) since at least Merom in 2006 [1][2]. Nowadays, there's Processor Trace (PT) or Precise Event-Based Sampling (PEBS) which can provide even more information. PT in particular is almost purpose-built to enable this kind of trace reconstruction.
[2] The MSRs for LBRs (MSR_LASTBRANCH_*_{TO,FROM}_IP) and BTS (IA32_DS_AREA) are described in Volume 4, Section 2.2 of the SDM: "MSRS IN THE INTEL® CORE™ 2 PROCESSOR FAMILY". Core 2 was launched in 2006.
I work remotely on a small-ish research team. Almost all of my immediate colleagues are in the US or Western Europe. Most (all?) of the folks on P- and E-Core Engineering that I work with are full employees (i.e. not contractors) in the US or Israel. I'm not sure I'd know if they were H1Bs, but they're generally very knowledgeable and hardworking. From my perspective, there's little outsourcing on the core businesses (pun fully intended).
As far as comp goes, mine is competitive with Bay Area FAANG.
At Berkeley, course numbers >100 are upper-division, and those <100 are lower-division, introductory classes. Especially in the CS department, the upper-division courses are far from introductory. 61B is the the second in the 61A-B-C series, which is required for all CS majors. (A fourth lower-division class, CS 70 ("Discrete Mathematics and Probability"), is also required, but is independent of the 61 series.)
X11 forwarding for Cadence's chip layout tooling is practically unusable nowadays! Sub-1 FPS, even on a reasonable 1 Gbps pipe with only 3-4 ms ping. I had to use NoMachine when I was doing that work -- proprietary tooling that does the "simpler" image/video streaming.
(Disclaimer: I work at Intel, but not on server products. Opinions are my own.)
There's a lot more that goes into a server platform than just the cores, for instance: the BIOS code, the BMC support, the maturity of the motherboard designs, etc. These are all areas where Intel seems to still have an edge -- but I'm also very excited about our upcoming server architectures on the core/compute side.
Further optimization are certainly possible, especially as the hardware improves and gains additional capabilities. With regards to your suggestion, this is essentially what already happens, thanks to the magic of out-of-order cores.
Check out angr [1], a symbolic execution engine, and claripy [2], its frontend to SMT solvers like z3. Depending on your background, I probably wouldn't describe angr as "for newbies," but claripy is a very clean SMT interface!
Another approach with which I've had success is to use something like PCBite's probes [1] to stab the little bits of solder sticking out the sides of the WSON package. PCBite's probes are excellent; they're sharp enough bite into the solder and hold themselves in place. (Those stalks aren't stiff; they support themselves by digging in.) PCBite is an all-around great product and definitely worth the somewhat-steep-for-a-hobbyist price tag, in my opinion.
This is one of my favorite episodes. I always thought the thin veiling helped to demonstrate the absurdity of both situations -- perhaps it was even done intentionally for that reason.
Erm, I'm not sure if you're being sarcastic, but they certainly are not giving these away to youtubers. This is a >$1 million instrument that isn't even very useful for hobbyist electronics. The ones they give away are from their new EDU line that does around 100 MHz sampling.
Great to hear that Intel is finally competitive in this space again. If process improvements are coming on time (and they are, if Pat is to be believed), perhaps Intel can finally compete in low-power, high-perf versus M1.
It generally goes the other way around -- programmers and compilers settle on a few idiomatic ways to do something, and new cores are built to execute those quickly. Because RISC-V is RISC, it seems likely that those few ways would be less idiomatic and more 'the only real way to do x', which would aid in the applicability of the fusions.
(Edited because I transposed "mutex" and "semaphore" in my mind.)
A mutex is a lock -- if multiple users attempt to access a resource simultaneously, they each attempt to acquire the lock serially, and those not first are excluded (blocked) until the current holder releases the lock.
Mutexes are typically implemented with semaphores:
First a more developer-oriented explanation (because I imagine that's what you really want):
A semaphore locks a shared resource by implementing two operations, "up" and "down". First, the semaphore is initialized to some positive integer, which represents how many concurrent "users" (typically threads) can use that resource. Then, each time a user wants to take advantage of that resource, it "down"s the semaphore , which atomically subtracts one from the current value -- but the key is that the semaphore's value can _never_ be negative, so if the value is currently zero, "down"ing a semaphore implies blocking until it's non-zero again. "Up"ing is just what you'd imagine: atomically increment the semaphore value, and unblock someone waiting, if necessary.
Semaphores are generally seen as a fundamental primitive (one reason being that locks/mutexes can be implemented trivially as a semaphore initialized to one), but they also have broad use as a general synchronization mechanism between threads.
For a true ELI5 of semaphores (I enjoy writing these):
Imagine everyone in class needs to write something, but there are only three pencils available, so you devise a system (a system of mutual exclusion, per se) for everyone to follow while the pencils are used: First, you note how many pencils are available -- three. Then, each time someone asks you for one, (which we call "down"ing the semaphore) you subtract one from the number in your head and give them a pencil. But if that number is zero, you don't have any pencils left, so you ask the person to wait. When someone returns and is done with their pencil, you hand it off to someone waiting, or, if nobody is waiting, you add one to that number in your head and take the pencil back ("up"ing the semaphore). It's important that you decide to only handle one request at a time (atomicity) -- if you tried to do too many things at once, you might lose track of your pencil count and accidentally promise more pencils than you have.
Thank you! It means a lot to me to be able to share what I learned. I don't know much of anything about the AMD side of things -- I'm just a poor college student and my investment in Intel platforms already hurt enough! Here's a brain dump about Intel, though:
Unfortunately we (the public) know very little about Yellow and Red. (Most of the time it's just called "Red" and "Red Unlock", because Red is a superset of Yellow and most conceivable exploits that could elevate to Yellow would also elevate to Red.)
[1] is a great place to start. It's a tiny bit out of date now (DAL was deprecated a while ago in favor of . . . IPC, I think it's called?). Check out Mark Ermolov's (one of the author's) Twitter [2] for some interesting developments -- he has Red unlock on a Goldmont Atom core via a cool exploit that he published (that has since been patched), leading to microcode (!) readout. (On a side note, I strongly suspect that he has some form of inside information -- there have been times where he knows some facet of the chipset internals that I can't find _any_ reference to online. I don't mean to diminish his work though; it's very cool stuff.)
Another good place to learn is the leak from last summer, referred to as "Ex-confidential lake." It doesn't contain anything damning, but skimming through it, especially the boot/bringup stuff, will help familiarize you with the terminology and also serves as a good reference if you have to dig through a compiled BIOS -- the leak contains the FSP source.
[4], a BlackHat talk, and [5], Intel's response/analysis, are super interesting. You'll definitely have to read them over a few times!
[6] is another great talk from Ermolov that also discusses Red unlock.
Finally, one of my favorite "tricks" is to just google for "<term> "Intel Confidential" filetype:pdf". You'll turn up a surprising amount of internal info that way.
In short, you need to do _a lot_ of research. I spent nearly an entire month just searching the internet for more information. A fun, endless mystery to solve!
(P.S. I'm not sure if you realize this, but it confused me initially: Chipset == Platform Controller Hub (PCH) != Management Engine (ME). The chipset/PCH is the whole piece of silicon that runs the system, whereas the ME is only the small processor core inside of there that performs some higher level operations such as booting and maintaining a root of trust. The PCH has a lot of cool stuff outside the ME!)
(P.P.S. If you're looking for something a bit easier to get started on, but also interesting and impactful, there's a lot of undocumented stuff going on in the PCRs -- the Platform Configuration Registers. It's partially documented in part 2 of the chipset datasheets, but there are a lot of fields that are readable/writable without any description. I wrote some very basic tools relating to it here [7] and here [8]. If you do something interesting with it, I'd love to hear: shoot me an email at my github username at gmail.)
[1] https://stackoverflow.com/questions/14670586/what-is-the-ove...
[2] The MSRs for LBRs (MSR_LASTBRANCH_*_{TO,FROM}_IP) and BTS (IA32_DS_AREA) are described in Volume 4, Section 2.2 of the SDM: "MSRS IN THE INTEL® CORE™ 2 PROCESSOR FAMILY". Core 2 was launched in 2006.