Want Energy Efficiency? Dude, You’re Getting A Dell!

With a title like “Intel Just Matched Apple Silicon. Seriously.“, the latest video from [Jeff Geerling] makes some pretty bold claims. But as we’d expect from [Jeff], he’s got the benchmarks up on GitHub for both the MacBook Neo and Dell’s latest XPS 13 to back it up.

We’ve embedded the full video below, which has [Jeff]’s comparative review of the two laptops. The Mac wins on iGPU, sound, and not shipping Windows, while the Dell gets points for being able to load Linux and having a backlit keyboard. But the figure we were hoping to see is the efficiency. After all, it’s ARM’s ability to crank out gigaflops on fewer watts that won them the mobile market and got Apple interested in that architecture in the first place. If Intel is catching up, that’s news.

On [Jeff]’s version of the Top500 benchmark — the same HPL Linpak test used for Supercomputers — the MacBook cranked out 57.012 Gflops at 10.6W, for 5.38 Gflops/W while the Dell managed 127.91 Gflops at 20.6W, for 6.21 Gflops/W. That’s just astounding, considering the historical data all goes the other way. This Dell also beats out both M4 and M3 Mac Studios, only failing to the M4 Mac Mini at 7.57 Gflops/W. Even when not crunching big numbers, say at idle or web browsing, the XPS matches the MacBook sip for sip in energy efficiency.

Some people have been saying for a few years now that ARM’s observed advantages in power consumption have more to do with the chips themselves than the instruction architecture, and it looks like the Core 5 320 chip in this Dell proves them right when it comes to x86.

While you might think you need to code in Assembly or C to maximize those efficiency gains, your choice of language may not be as important as you think.

Continue reading “Want Energy Efficiency? Dude, You’re Getting A Dell!”

Building An X86 Gaming PC Without Intel, NVIDIA Or AMD Parts

This is an interesting challenge from the “why not?” files — [GPUSpecs] over on YouTube built a gaming PC without using a single component from NVIDIA, Intel, or AMD. That immediately makes us think of the high-power ARM workstations or perhaps even perhaps the new “AI workstations” coming available with RISC V architecture, but the challenge here was specifically “gaming PC,” not workstation. A gaming PC, without a GPU by one of those three? To make it even more interesting, the x86 CPU isn’t Intel or AMD either.

If you’re of a certain vintage, you may remember Cyrix. Cyrix reverse-engineered the x86 ISA and made their own compatible chips in the 90s, before being bought out by National Semiconductor, and then VIA Technologies. VIA partnered with the Government of Shanghai to found Zhaoxin, and it is from Zhaoxin that the KaiXian KX 7000 CPU hails — an x86-64 device, that isn’t Intel or AMD. We’ve actually covered the company before. This particular chip benchmarks like an old i5, so not spectacular, but usable. 

Continue reading “Building An X86 Gaming PC Without Intel, NVIDIA Or AMD Parts”

CSS, Now It’s Got Your 8086

The modern web browser is now far more than a thing for rendering web pages, it’s a multi-faceted environment that can provide a home for almost any application you could imagine. But why should JavaScript or Wasm have all the fun? CSS is Turing complete now, right? Why not, as [Lyra Rebane] has done, write an 8086 emulator in pure CSS?

The web page at the link above may contain an 8086, but missing MMU aside, don’t expect it to run Linux just yet. Instead it has limited resources, just enough to run a demo program. It needs a Chrome-adjacent browser because it uses some CSS functions not available in for example Firefox, but we’ll forgive it that oddity. Its clock is provided by a small piece of JavaScript not because CSS can’t provide one, but because the JS version is more stable.

On one hand this is of little practical use, but to dismiss it as such is to entirely miss the point. It’s in the fine spirit of experimentation, and we love it. Perhaps a better way to look at it is to see what could be done more efficiently with the same idea. A 1970s CISC microprocessor might not be the best choice, but would for example a minimalist and optimized RISC design be more capable? We’re looking forward to where others take this thread.

It’s not the first unexpected computing environment we’ve found, who could forget the DOOM calculator!


Header: Thomas Nguyen, CC BY-SA 4.0.

Back To The 90s On Real Hardware

As the march of time continues on, it becomes harder and harder to play older video games on hardware. Part of this is because the original hardware itself wears out, but another major factor is that modern operating systems, software, and even modern hardware don’t maintain support for older technology indefinitely. This is why emulation is so popular, but purists that need original hardware often have to go to extremes to scratch their retro gaming itch. This project from [Eivind], for example, is a completely new x86 PC designed for the DOS and early Windows 98 era.

The main problem with running older games on modern hardware is the lack of an ISA bus, which is where the sound cards on PCs from this era were placed. This build uses a Vortex86EX system-on-module, which has a processor running a 32-bit x86 instruction set. Not only does this mean that software built for DOS can run natively on this chip, but it also has this elusive ISA capability. The motherboard uses a Crystal CS4237B chip connected to this bus which perfectly replicates a SoundBlaster card from this era. There are also expansion ports to add other sound cards, including ones with Yamaha OPL chips.

Not only does this build provide a native hardware environment for DOS-era gaming, but it also adds a lot of ports missing from modern machines as well including a serial port. Not everything needs to be original hardware, though; a virtual floppy drive and microSD card reader make it easy to interface minimally with modern computers and transfer files easily. This isn’t the only way to game on new, native hardware, though. Others have done similar things with new computers built for legacy industrial applications as well.

Thanks to [Stephen] for the tip!

Continue reading “Back To The 90s On Real Hardware”

The 386's main register bank, at the bottom of the datapath. The numbers show how many bits of the register can be accessed. (Credit: Ken Shirriff)

The Convoluted Way Intel’s 386 Implemented Its Registers

The fact that modern-day x86 processors still pretty much support the same operating systems and software as their ancestors did is quite a feat. Much of this effort had already been accomplished with the release of the 80386 (later 386) CPU in 1985, which was not only the first 32-bit x86 CPU, but was also backwards compatible with 8- and 16-bit software dating back to the 1970s. Making this work transparently was anything but straightforward, as [Ken Shirriff]’s recent analysis of the 80386’s main register file shows.

Labelled Intel 80386 die shot. (Credit: Ken Shirriff)
Labelled Intel 80386 die shot. (Credit: Ken Shirriff)

Using die shots of the 386’s registers and surrounding silicon, it’s possible to piece together how backwards compatibility was implemented. The storage cells of the registers are implemented using static memory (SRAM) as is typical, with much of the register file triple-ported (two read, one write).

Most interestingly is the presence of different circuits (6) to support accessing the register file for 8-, 16- or 32-bit writes and reads. The ‘shuffle’ network as [Ken] calls it is responsible for handling these distinct writes and reads, which also leads to the finding that the bottom 16 bits in the registers are actually interleaved to make this process work smoother.

Fortunately for Intel (and AMD) engineers, this feat wouldn’t have to be repeated again with the arrival of AMD64 and x86_64 many years later, when the 386’s mere 275,000 transistors on a 1 µm process would already be ancient history.

Want to dive even deeper in to the 386? This isn’t the first time [Ken] has looked at the iconic chip.

Mockup of a printed copy of the Little OS Book

One Book To Boot Them All

Somewhere in the universe, there’s a place that lists every x86 operating system from scratch. Not just some bootloaders, or just a kernel stub, but documentation to build a fully functional, interrupt-handling, multitasking-capable OS. [Erik Helin and Adam Renberg] did just that by documenting every step in The Little Book About OS Development.

This is not your typical dry academic textbook. It’s a hands-on, step-by-step guide aimed at hackers, tinkerers, and developers who want to demystify kernel programming. The book walks you through setting up your environment, bootstrapping your OS, handling interrupts, implementing virtual memory, and even tackling system calls and multitasking. It provides just enough detail to get you started but leaves room for exploration – because, let’s be honest, half the fun is in figuring things out yourself.

Completeness and structure are two things that make this book stand out. Other OS dev guides may give you snippets and leave you to assemble the puzzle yourself. This book documents the entire process, including common pitfalls. If you’ve ever been lost in the weeds of segmentation, paging, or serial I/O, this is the map you need. You can read it online or fetch it as a single 75-page long PDF.

Mockup photo source: Matthieu Dixte

Faster Integer Division With Floating Point

Multiplication on a common microcontroller is easy. But division is much more difficult. Even with hardware assistance, a 32-bit division on a modern 64-bit x86 CPU can run between 9 and 15 cycles. Doing array processing with SIMD (single instruction multiple data)  instructions like AVX or NEON often don’t offer division at all (although the RISC-V vector extensions do). However, many processors support floating point division. Does it make sense to use floating point division to replace simpler division? According to [Wojciech Mula] in a recent post, the answer is yes.

The plan is simple: cast the 8-bit numbers into 32-bit integers and then to floating point numbers. These can be divided in bulk via the SIMD instructions and then converted in reverse to the 8-bit result. You can find several code examples on GitHub.

Continue reading “Faster Integer Division With Floating Point”