Intel Suggests Dropping Everything But 64-Bit From X86 With Its X86-S Proposal

In a move that has a significant part of the internet flashing back to the innocent days of 2001 when Intel launched its Itanium architecture as a replacement for the then 32-bit only x86 architecture – before it getting bludgeoned by AMD’s competing x86_64 architecture – Intel has now released a whitepaper with associated X86-S specification that seeks to probe the community’s thoughts on it essentially removing all pre-x86_64 features out of x86 CPUs.

While today you can essentially still install your copy of MSDOS 6.11 on a brand-new Intel Core i7 system, with some caveats, it’s undeniable that to most users of PCs the removal of 16 and 32-bit mode would likely go by unnoticed, as well as the suggested removal of rings 1 and 2, as well as range of other low-level (I/O) features. Rather than the boot process going from real-mode 16-bit to protected mode, and from 32- to 64-bit mode, the system would boot straight into the 64-bit mode which Intel figures is what everyone uses anyway.

Where things get a bit hazy is that on this theoretical X86-S you cannot just install and boot your current 64-bit operating systems, as they have no concept of this new boot procedure, or the other low-level features that got dropped. This is where the Itanium comparison seems most apt, as it was Intel’s attempt at a clean cut with its x86 legacy, only for literally everything about the concept (VLIW) and ‘legacy software’ support to go horribly wrong.

Although X86-S seems much less ambitious than Itanium, it would nevertheless be interesting to hear AMD’s thoughts on the matter.

Hackaday Links Column Banner

Hackaday Links: March 26, 2023

Sad news in the tech world this week as Intel co-founder Gordon Moore passed away in Hawaii at the age of 94. Along with Robert Noyce in 1968, Moore founded NM Electronics, the company that would later go on to become Intel Corporation and give the world the first commercially available microprocessor, the 4004, in 1971. The four-bit microprocessor would be joined a few years later by the 8008 and 8080, chips that paved the way for the PC revolution to come. Surprisingly, Moore was not an electrical engineer but a chemist, earning his Ph.D. from the California Institute of Technology in 1954 before his postdoctoral research at the prestigious Applied Physics Lab at Johns Hopkins. He briefly worked alongside Nobel laureate and transistor co-inventor William Shockley before jumping ship with Noyce and others to found Fairchild Semiconductor, which is where he made the observation that integrated circuit component density doubled roughly every two years. This calculation would go on to be known as “Moore’s Law.”

Continue reading “Hackaday Links: March 26, 2023”

Exploring Texas Instrument’s Forgotten CPU

Texas Instruments isn’t the name you usually hear associated with the first microprocessor. But the TI TMX 1795 was an 8008 chip produced months before the 8008. It was never available commercially, though, so it has been largely forgotten by most people. But not [Ken Shirriff]. You can see a demo from 2015 of the device in the video below, too.

The reason the chips have the same architecture is they were built to replace the same large circuit board inside a Datapoint 2200 programmable terminal. These were big beasts that could be programmed in BASIC or PL/B.

Datapoint asked Intel to shrink the board to a chip due to heating problems — but after delays, they instead replaced the power supply and lost interest in the device. TI heard about the affair and wanted in on the deal. However, Datapoint was unimpressed. The chip didn’t tolerate voltage fluctuations very well, since they had replaced the power supply and had a new CPU design that was faster than the chip would be. They were also unimpressed with how much stuff you had to add to get a complete system.

So why did the Intel 8008 work out in the marketplace but the TI chip didn’t? After all, Datapoint decided not to use the 8008, also. But as [Ken] points out, the 8008 was much smaller than the TI chip and, thus, was more cost-effective to produce.

As usual, [Ken]’s posts are always interesting and enlightening. He’s looked at a lot of old computers. He’s even dug into old space hardware. Great stuff!

Continue reading “Exploring Texas Instrument’s Forgotten CPU”

The 286 Gives Up One Of Its Final Secrets

Though it is largely forgotten today, the Intel 80286 was for a while in the 1980s the processor of choice and designated successor to the 8086 in the world of PCs. It brought a new mode that could address up to 16 Mb of memory, and a welcome speed boost over machines using an 8086 or 8088. As with many microprocessors, it has a few undocumented features, and it’s a couple of these that [rep lodsb] takes a look at. Along the way we learn a bit about the 286, and about why Intel had some of these undocumented instructions in the first place.

If you used a 286 it was probably as an end-user sitting in front of a PC-AT or clone. During manufacture and testing though, the processor had need of some extra functions, both for testing the chip itself and for debugging designs using it. It’s in these fields that the undocumented instructions sit, and they relate to an in-circuit emulator, a 286 with a debug port on some of its unused pins, which would have sat on a plug-in daughterboard for systems under test. The 286 was famous for its fancy extended mode taking rather a long time to switch to, and these instructions relate to loading and saving states before and after the switch.

The 286s time as the new hotness was soon blasted away by the 386 with its support for virtual memory, so for most of us it remains as simply a faster way that we ran 8086 code for a few years. They appear from time to time here, even being connected to the internet.

286 image: Thomas Nguyen (PttNguyen.net), CC BY-SA 4.0.

Down The Intel Microcode Rabbit Hole

The aptly-named [chip-red-pill] team is offering you a chance to go down the Intel rabbit hole. If you learned how to build CPUs back in the 1970s, you would learn that your instruction decoder would, for example, note a register to register move and then light up one register to write to a common bus and another register to read from the common bus. These days, it isn’t that simple. In addition to compiling to an underlying instruction set, processors rarely encode instructions in hardware anymore. Instead, each instruction has microcode that causes the right things to happen at the right time. But Intel encrypts their microcode. Of course, what can be encrypted can also be decrypted.

Using vulnerabilities, you can activate an undocumented debugging mode called red unlock. This allows a microcode dump and the decryption keys are inside. The team did a paper for OffensiveCon22 on this technique and you can see a video about it, below.

Continue reading “Down The Intel Microcode Rabbit Hole”

How The IBM PC Went 8-Bit

If you were around when the IBM PC rolled out, two things probably caught you by surprise. One is that the company that made the Selectric put that ridiculous keyboard on it. The other was that it had an 8-bit CPU onboard.  It was actually even stranger than that. The PC sported an 8088 which was a 16-bit 8086 stripped down to an 8 bit external bus. You have to wonder what caused that, and [Steven Leibson] has a great post that explains what went down all those years ago.

Before the IBM PC, nearly all personal computers were 8-bit and had 16-bit address buses. Although 64K may have seemed enough for anyone, many realized that was going to be a brick wall fairly soon. So the answer was larger address buses and addressing modes.

Intel knew this and was working on the flagship iAPX 432. This was going to represent a radical departure from the 8080-series CPUs designed from the start for high-level languages like Ada. However, the radical design took longer than expected. The project started in 1976 but wouldn’t see the light of day until 1981. It was clear they needed something sooner, so the 8086 — a 16-bit processor clearly derived from the 8080 was born. Continue reading “How The IBM PC Went 8-Bit”

AVX-512: When The Bits Really Count

For the majority of workloads, fiddling with assembly instructions isn’t worth it. The added complexity and code obfuscation generally outweigh the relatively modest gains. Mainly because compilers have become quite fantastic at generation code and because processors are just so much faster, it is hard to get a meaningful speedup by tweaking a small section of code. That changes when you introduce SIMD instructions and need to decode lots of bitsets fast. Intel’s fancy AVX-512 SIMD instructions can offer some meaningful performance gains with relatively low custom assembly.

Like many software engineers, [Daniel Lemire] had many bitsets (a range of ints/enums encoded into a binary number, each bit corresponding to a different integer or enum). Rather than checking if just a specific flag is present (a bitwise and), [Daniel] wanted to know all the flags in a given bitset. The easiest way would be to iterate through all of them like so:

while (word != 0) {
  result[i] = trailingzeroes(word);
  word = word & (word - 1);
  i++;
}

The naive version of this look is very likely to have a branch misprediction, and either you or the compiler would speed it up by unrolling the loop. However, the AVX-512 instruction set on the latest Intel processors has some handy instructions just for this kind of thing. The instruction is vpcompressd and Intel provides a handy and memorable C/C++ function called _mm512_mask_compressstoreu_epi32.

The function generates an array of integers and you can use the infamous popcnt instruction to get the number of ones. Some early benchmark testing shows the AVX-512 version uses 45% fewer cycles. You might be wondering, doesn’t the processor downclock when wide 512-bite registers are used? Yes. But even with the downclocking, the SIMD version is still 33% faster. The code is up on Github if you want to try it yourself.