Forem: Pʀᴀɴᴀᴠ

Xtensa: the CPU architecture you already use (without knowing it)

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 20:43:12 +0000

Xtensa is not a desktop CPU.
It is not meant to replace x86 or ARM.

But chances are very high that you already use Xtensa every day.

Xtensa is a configurable CPU architecture created by Tensilica (now owned by Cadence).

Its main idea is simple:

Build a CPU that can be customized for one specific job.

What Xtensa actually is

Xtensa is an instruction set architecture that can be modified and extended by chip designers.

Unlike fixed ISAs:
• x86
• ARM
• RISC-V

Xtensa allows companies to:
• add custom instructions
• remove unused features
• tune the CPU for a specific workload

This makes Xtensa very popular in embedded systems.

How Xtensa is different from normal CPUs

Normal CPUs try to be good at everything.

Xtensa tries to be excellent at one thing.

A company can design an Xtensa core that is:
• optimized for audio processing
• optimized for networking
• optimized for low power
• optimized for AI or signal processing

This reduces:
• power usage
• chip size
• cost

That matters a lot in embedded devices.

Where Xtensa is used

Xtensa is widely used in embedded hardware.

Very common places:
• Wi-Fi chips
• Bluetooth chips
• IoT devices
• audio processors
• networking chips

The most famous example:

ESP32 microcontrollers.

ESP32 chips use Xtensa cores and are extremely popular in IoT projects.

Xtensa in ESP32 (important example)

Many ESP32 chips contain:
• one or two Xtensa cores
• Wi-Fi and Bluetooth hardware
• low power design

These chips run:
• Arduino programs
• MicroPython
• FreeRTOS
• bare-metal firmware

Millions of devices ship with Xtensa every year.

Can Xtensa run an operating system?

Yes but with limits.

Xtensa can run:
• FreeRTOS
• Zephyr
• custom real-time operating systems

Linux:
• technically possible on high-end Xtensa cores
• rare
• not common in consumer devices

Xtensa is not designed for desktop operating systems.

Does Xtensa run Linux?

Yes, but only in special cases.

Some Xtensa implementations:
• support MMU
• have enough memory
• can boot Linux

However:
• tooling is complex
• ecosystem is small
• performance is limited

Most Xtensa systems use RTOS, not Linux.

Application support

Xtensa applications are usually:
• firmware
• embedded software
• device-specific code

There is no general app ecosystem like:
• Windows apps
• Android apps
• desktop Linux apps

Software is usually written specifically for the device.

Who should use Xtensa

Xtensa is ideal if:
• you design custom hardware
• you build IoT devices
• you need very low power usage
• you want custom CPU instructions

Xtensa is not ideal if:
• you want a desktop PC
• you need mainstream OS support
• you want a large app ecosystem

Xtensa vs ARM vs RISC-V (simple view)

Xtensa:
• configurable
• embedded-focused
• proprietary
• device-specific

ARM:
• fixed ISA
• licensed
• huge ecosystem

RISC-V:
• open
• flexible
• growing fast

Xtensa wins when custom instructions matter most.

Why Xtensa still matters

Xtensa shows that:
• not all CPUs need to be general-purpose
• specialization can beat raw power
• embedded systems drive huge volumes

You may never see “Xtensa” on a laptop box.

But it is already inside:
• routers
• smart devices
• IoT gadgets
• Wi-Fi chips

And that makes it one of the most widely deployed architectures today.

Final thoughts

Xtensa is not famous.

It doesn’t try to be.

It quietly does its job inside billions of devices and does it well.

That’s why it survived.

LoongArch: China’s homegrown CPU architecture that is now in real laptops

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 20:36:45 +0000

LoongArch is no longer just a research idea.

It is now:
• running Linux
• shipping in real laptops
• used by governments and companies inside China

LoongArch is a modern RISC-style instruction set created by Loongson.
Its main goal is simple:

Reduce dependence on foreign CPU architectures like x86, ARM, and MIPS.

What LoongArch actually is

LoongArch is an instruction set architecture (ISA).

It is:
• not x86 compatible
• not ARM compatible
• not RISC-V

It is a new, independent ISA, designed from scratch.

Loongson originally used MIPS.
Later, due to licensing and control issues, they moved away and created LoongArch.

LoongArch is RISC-like:
• fixed-length instructions
• load/store design
• clean register model
• modern 64-bit design

But it is not the same ISA as ARM or RISC-V.

Why LoongArch exists

LoongArch exists for three reasons:
• national technology independence
• long-term control over CPU evolution
• removal of foreign licensing risk

Performance was not the first goal.
Control and stability were.

LoongArch processors in use today

Modern LoongArch CPUs include:

Loongson 3A5000
Loongson 3A6000

These are:
• 64-bit CPUs
• desktop and laptop capable
• comparable to older Intel Core i5 generations
• not meant for gaming or high-end workloads

They are good enough for:
• office work
• development
• government desktops
• education systems

Real laptops using LoongArch

Yes real laptops exist.

Examples (mostly sold in China):

Loongson 3A6000-based laptops
• Often sold under local Chinese brands
• Used in government and enterprise environments
• Linux preinstalled

Some vendors and models are not globally marketed, but commonly referenced examples include:
• Tongfang LoongArch laptops
• Loongson reference laptops
• Government-issued LoongArch notebooks

These are not consumer laptops like Dell or HP models.
They are policy-driven deployments.

Operating system support

This is where LoongArch became serious.

Linux
Linux
• Full kernel support for LoongArch
• Actively maintained
• Main OS for LoongArch systems

Linux distributions with LoongArch support include:
• Loongnix
• Kylin Linux
• OpenEuler (LoongArch builds)

These are Linux distros tailored for Chinese systems.

Windows support

There is no official Windows support for LoongArch.

Microsoft does not provide:
• Windows binaries
• drivers
• toolchains

Some experiments exist, but nothing production-ready.

BSD and others

BSD systems:
• experimental only
• not common
• not officially supported

LoongArch is clearly a Linux-first architecture.

Application support on LoongArch

This is the biggest limitation.

Native apps:
• must be compiled for LoongArch
• many open-source apps already work
• Linux desktop software mostly fine

Works well:
• Firefox
• LibreOffice
• GCC / Clang
• Python
• common Linux tools

Does not work natively:
• Windows apps
• proprietary x86-only software
• most commercial games

x86 app compatibility (important)

LoongArch does not run x86 apps natively.

Instead, it uses:
• binary translation
• compatibility layers

Performance:
• acceptable for light apps
• slow for heavy workloads

This is similar to how:
• Apple Rosetta works (but less polished)
• Elbrus runs x86 software

Good for transition.
Not good for power users.

Who actually needs LoongArch

LoongArch makes sense for:
• government systems
• public sector desktops
• education institutions
• long-term controlled environments
• national infrastructure

LoongArch does NOT make sense for:
• gamers
• creative professionals
• general consumers
• people who need Windows apps

LoongArch vs ARM vs RISC-V (simple)

LoongArch:
• independent
• Linux-focused
• regional use
• controlled ecosystem

ARM:
• global
• very mature
• licensed
• consumer-friendly

RISC-V:
• open
• fast-growing
• still maturing for desktops

LoongArch is not competing globally.
It is solving a local strategic problem.

Is LoongArch the future of PCs?

Globally? No.

Regionally? Yes.

Inside China:
• LoongArch adoption is increasing
• government mandates help
• software support is improving slowly

Outside China:
• almost no availability
• little reason to adopt

Final thoughts

LoongArch is not about speed or popularity.

It is about:
• control
• independence
• long-term planning

It proves that building a full CPU ecosystem from scratch is possible but very hard.

LoongArch laptops exist.
Linux runs well.
Apps mostly work.

That alone makes it worth understanding.

Elbrus (E2K): a CPU architecture that thinks like a compiler

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 20:27:44 +0000

Elbrus is one of the strangest CPU architectures still in use today.

It is not fast by modern standards.
It is not common.
But it is very interesting.

Elbrus (also called E2K) is a processor architecture developed in Russia, mainly for government and military systems.

Its most important idea is simple but risky:

Let the compiler do almost all the work.

What Elbrus (E2K) actually is

Elbrus uses its own instruction set called E2K ISA.

It is based on a design style called VLIW (Very Long Instruction Word).

That means:
• one instruction can contain many operations
• the compiler decides what runs in parallel
• the CPU does very little scheduling at runtime

This is very different from x86 or ARM.

ISA style: VLIW (important part)

Elbrus is not RISC and not CISC.

It is VLIW-based.

VLIW means:
• instructions are wide (many bits)
• each instruction contains multiple operations
• operations run in parallel if the compiler says so

Example idea (conceptual, not real code):

Instead of:
• add
• multiply
• load
• store

one by one…

Elbrus executes:
• add + multiply + load + store
at the same time, inside one instruction bundle.

The CPU trusts the compiler completely.

Why Elbrus chose VLIW

The goal was:
• predictable execution
• simpler CPU hardware
• more control over execution
• less complex silicon

This also helps with:
• security auditing
• deterministic behavior
• controlled environments

Perfect for government systems.

The big problem with VLIW

Real programs are messy.
• branches are unpredictable
• memory access is slow sometimes
• workloads change at runtime

A compiler cannot perfectly predict this.

So if the compiler guesses wrong:
• performance drops
• CPU sits idle
• parallel units are wasted

This is why VLIW failed in most consumer CPUs.

How Elbrus runs x86 software

This is the part people find surprising.

Elbrus can run x86 software, but not natively.

It uses binary translation.

How it works:
• x86 instructions are translated into E2K instructions
• translation happens dynamically or ahead of time
• translated code is cached and reused

This allows:
• running Linux x86 apps
• running legacy software
• avoiding full rewrites

But:
• performance is much slower than native x86
• heavy workloads suffer

Operating systems on Elbrus

Elbrus does not run mainstream Windows.

Supported systems include:

Linux
Linux
• Custom Linux distributions
• Used for desktops and servers
• Main OS for Elbrus systems

There is no official Windows support.

Everything is tightly controlled.

Where Elbrus is actually used

Elbrus is used mainly in:
• Russian government offices
• military systems
• secure research facilities
• controlled enterprise environments

It is not meant for:
• gaming
• consumer laptops
• app stores
• general-purpose PCs

Elbrus as a desktop CPU

Yes, Elbrus can be used as a desktop.

But:
• software availability is limited
• performance is modest
• ecosystem is small
• hardware is expensive for what it offers

It exists because of political and strategic reasons, not performance.

Elbrus vs x86 vs ARM (simple view)

Elbrus:
• VLIW
• compiler-driven
• slow but controlled
• niche use

x86:
• CISC
• hardware-driven
• fast
• massive ecosystem

ARM:
• RISC
• balanced design
• efficient
• widely supported

Elbrus is not trying to win this race.

It is trying to avoid dependence.

Why Elbrus still exists

Elbrus exists because:
• countries want CPU independence
• source control matters
• predictable systems matter
• security matters more than speed

For those goals, Elbrus is “good enough”.

Final thoughts

Elbrus is not a failed CPU.

It is a purpose-built architecture.

It trades:
• speed
for
• control

It trades:
• ecosystem
for
• independence

That makes it unusual but also explains why it still exists.

Zilog Z80: the small CPU that powered an entire generation

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 20:20:34 +0000

Before powerful laptops and smartphones, there were small computers that felt magical for their time.

Many of them were powered by one chip:

Zilog Z80

The Z80 is one of the most important CPUs ever made not because it was fast, but because it was everywhere.

What the Z80 actually is

The Zilog Z80 is an 8-bit microprocessor released in the mid-1970s.

It was designed to be:
• simple
• cheap
• flexible
• easy to use

It was compatible with the older Intel 8080, but added many improvements. That made it very attractive to computer makers.

Why the Z80 became so popular

The Z80 succeeded because it solved real problems.

It had:
• more registers than the 8080
• built-in memory refresh support
• simple instruction set
• good performance for low cost

This meant:
• fewer extra chips needed
• cheaper computers
• simpler system design

For small companies and hobbyists, this mattered a lot.

Where the Z80 was used

The Z80 was used in a huge number of early computers and devices.

Famous examples:
• Sinclair ZX Spectrum
• MSX home computers
• TRS-80
• Amstrad CPC
• early arcade machines

If you used a home computer in the 1980s, there is a good chance it had a Z80 inside.

Z80 and operating systems

The Z80 was not meant for modern operating systems.

Instead, it ran:
• simple ROM-based systems
• BASIC interpreters
• CP/M operating system

CP/M was especially important.
Before MS-DOS became popular, CP/M on Z80 systems was very common.

Was the Z80 used in embedded systems?

Yes and this is why it still matters today.

Z80 chips are still used in:
• calculators
• industrial controllers
• test equipment
• communication devices

They are reliable, predictable, and easy to program.

Some Z80-based chips are still manufactured today.

Why the Z80 survived for so long

The Z80 lasted because:
• it was simple
• it was well documented
• engineers trusted it
• existing software kept working

Even when faster CPUs appeared, the Z80 stayed useful in small control systems.

Z80 today

You won’t find a Z80 in:
• modern laptops
• phones
• gaming PCs

But you will still find it in:
• embedded hardware
• education
• retro computers
• hobby projects

Many people still learn assembly language using the Z80 because it is easy to understand.

Why the Z80 still matters

The Z80 helped define:
• early personal computing
• affordable home computers
• how simple CPUs should be designed

*It proved that a small, well-designed processor can change the world.
*

Final thoughts

The Zilog Z80 didn’t try to be powerful.

It tried to be useful.

And for a very long time, it succeeded.

That’s why it’s still remembered and still used today

IBM Z: the computer that never learned how to die

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 20:15:46 +0000

Most computers are replaced every few years.

IBM Z systems are different.
They are designed to run for decades.

IBM Z is not a normal CPU platform. It is a mainframe architecture built for reliability, security, and massive workloads.

This is the kind of computer that banks and governments trust with everything.

What IBM Z actually is

IBM Z is both:
• a processor architecture
• a complete mainframe system

The instruction set used by IBM Z is commonly called s390x.

This architecture is designed for:
• extreme uptime
• huge input/output workloads
• running thousands of tasks at the same time
• backward compatibility across generations

Programs written decades ago can still run today.

What makes IBM Z different from normal CPUs

IBM Z does not try to be fast like a gaming CPU.

It tries to be:
• correct
• stable
• secure
• always available

Key design goals:
• systems that almost never go down
• hardware-level encryption
• fault tolerance built into the CPU
• predictable performance under heavy load

If a normal server fails, you reboot.
If an IBM Z system fails, something went very wrong.

Backward compatibility is sacred

One of the most impressive things about IBM Z is compatibility.

Software written:
• 20 years ago
• 30 years ago
• even older

can still run on modern IBM Z machines.

IBM treats backward compatibility as a rule, not a suggestion.

This is why companies never rush to replace mainframes.

Operating systems that run on IBM Z

IBM Z has real operating systems, not custom firmware.

z/OS

This is the main operating system for IBM Z.

Used for:
• banking systems
• airline reservations
• insurance databases
• government systems

It is built for:
• huge transaction volumes
• extreme reliability
• long uptime

Linux on IBM Z

Linux runs very well on IBM Z.

Linux on Z is used for:
• cloud workloads
• containers
• databases
• enterprise applications

Yes, you can run Docker and Kubernetes on IBM Z.

z/VM

This is a virtualization operating system.

It allows:
• thousands of virtual machines
• strong isolation
• efficient resource sharing

IBM Z was doing large-scale virtualization long before it became popular elsewhere.

Who actually uses IBM Z today

IBM Z is not rare.

It is used by:
• banks
• stock exchanges
• airlines
• governments
• large insurance companies
• telecom providers

If you:
• withdraw money
• book a flight
• swipe a credit card

There is a good chance IBM Z was involved.

Why companies still use IBM Z

Main reasons:
• downtime is extremely expensive
• security is critical
• systems must scale reliably
• rewriting software is risky

IBM Z systems can:
• process millions of transactions per second
• encrypt data without slowing down
• run for years without shutdown

For some workloads, nothing else compares.

Modern IBM Z systems

IBM Z is not old hardware running forever.

IBM still releases new machines.

Example:
• IBM z16 (modern generation)

Each generation improves:
• performance
• energy efficiency
• security features

But still keeps old software working.

Is IBM Z outdated?

No.

It is specialized.

IBM Z is not for:
• gaming
• personal laptops
• hobby projects

It is for:
• mission-critical computing
• workloads where failure is not allowed

Different tools for different jobs.

Why IBM Z will not disappear like DEC Alpha

DEC Alpha died because the company behind it disappeared.

IBM Z survives because:
• IBM is still committed
• customers depend on it
• the ecosystem is stable
• migration costs are huge

IBM Z is not trendy and that is its strength.

Final thoughts

IBM Z is the opposite of modern tech hype.

It changes slowly.
It breaks nothing.
It keeps running.

While most computers chase speed, IBM Z chases trust.

And that is why it is still here.

DEC Alpha: the fastest CPU architecture you probably never used

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 20:06:33 +0000

DEC Alpha is one of those technologies that makes engineers quietly sad.

Not because it was bad.
But because it was too good and still disappeared.

DEC Alpha was a CPU architecture that was far ahead of its time. For a while, it was the fastest general-purpose processor in the world.

And yet, almost nobody talks about it today.

What DEC Alpha was

DEC Alpha was a 64-bit RISC architecture created by Digital Equipment Corporation (DEC) in the early 1990s.

At a time when:
• most CPUs were still 32-bit
• clock speeds were low
• software was not ready for 64-bit

Alpha arrived fully 64-bit and unapologetic.

It was designed for:
• servers
• workstations
• scientific computing
• enterprise UNIX systems

Why Alpha was special

Alpha followed one clear rule:

Keep the architecture simple so it can scale forever.

Key ideas:
• very clean instruction set
• no legacy baggage
• designed for very high clock speeds
• simple pipeline-friendly design

DEC even planned Alpha to scale up to extremely high frequencies years in advance. And it did.

For a long time, Alpha CPUs were faster than anything Intel had.

Alpha was built for speed

Alpha processors regularly broke performance records.

Reasons:
• aggressive clock speeds
• large register files
• no complicated instructions
• excellent compiler support

Unlike some architectures, Alpha did not try to be clever at runtime.
It trusted the compiler and clean hardware design.

That worked.

Operating systems that ran on Alpha

Alpha had serious operating system support.

It ran:
• OpenVMS
• Tru64 UNIX
• Linux
• BSD variants (experimental)

Linux on Alpha existed early and worked surprisingly well.

Alpha was never locked to one OS. It was a real platform.

Where Alpha was actually used

Alpha systems were used in:
• scientific research
• simulations
• enterprise servers
• high-end UNIX workstations

These were machines for:
• engineers
• researchers
• large organizations

Not home users.

Why DEC Alpha died (and it wasn’t technical)

This part matters.

Alpha did not fail because it was slow or flawed.

It failed because of business decisions.

What happened:
• DEC was acquired by Compaq
• Compaq later merged with HP
• HP decided to focus on Itanium instead
• Alpha development was stopped

Alpha was sacrificed for corporate strategy.

Many engineers still believe this was a mistake.

Alpha vs Itanium (the painful comparison)

Alpha:
• simple
• fast
• already working
• strong ecosystem

Itanium:
• complex
• compiler-dependent
• required software rewrites
• struggled in real workloads

History chose Itanium.

History was wrong.

Does Alpha exist today?

No.

DEC Alpha is fully discontinued.

You will not find:
• new Alpha CPUs
• modern hardware
• active development

But:
• old systems still exist
• hobbyists emulate Alpha
• its design ideas live on

Why Alpha still matters

Alpha proved that:
• clean RISC design scales
• 64-bit was the future
• simplicity beats clever tricks
• business decisions can kill good technology

Many ideas in modern CPUs feel familiar because Alpha did them first.

Final thoughts

DEC Alpha didn’t lose because it was bad.

It lost because the company behind it disappeared.

If Alpha had survived, the CPU world might look very different today.

And that’s why engineers still talk about it quietly, with respect.

MIPS architecture: simple, clean, and quietly everywhere (once)

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 19:57:07 +0000

MIPS is one of those architectures everyone learns about, assumes is dead, and then accidentally uses without realizing it.

It never dominated desktops.
It never won mobile.
But it quietly powered huge parts of the internet.

MIPS is a classic RISC instruction set that focused on simplicity, predictability, and clean design long before those became buzzwords again.

What MIPS actually is

MIPS is a RISC instruction set architecture.

Its core ideas:
• simple, fixed-length instructions
• load/store design
• large register file
• compiler-friendly execution

It was designed so well that it became the teaching ISA for computer architecture courses for decades.

If you learned pipelining, hazards, or instruction scheduling in college, you probably learned it using MIPS.

Where MIPS was heavily used

MIPS never targeted consumer desktops seriously. Instead, it dominated embedded and infrastructure systems.

Common real-world uses:
• routers and switches
• network appliances
• Wi-Fi access points
• set-top boxes
• digital TVs
• storage controllers
• printers and industrial devices

Companies used MIPS because:
• the architecture was clean
• implementations were cheap
• performance per watt was good
• long-term stability mattered

For many years, a large number of home and office routers ran Linux on MIPS chips.

You used MIPS without knowing it.

Was MIPS used in computers or laptops?

Yes but not mainstream.

MIPS appeared in:
• university workstations
• research systems
• experimental consumer devices

There were early Chromebooks built using MIPS processors.

These never became popular products, but they did exist.

Chromebooks later moved fully to ARM and x86.

Does MIPS still exist today?

Yes, but mostly in old or long-life systems.

Today, MIPS is found in:
• older networking equipment
• legacy embedded devices
• systems that are expensive to replace

New products usually choose ARM or RISC-V instead.

MIPS is slowly fading, not suddenly dead.

Operating system support for MIPS

Linux

Linux has very strong historical support for MIPS.

Linux on MIPS was used in:
• routers
• embedded boards
• networking devices

Today:
• Linux still supports MIPS
• but fewer developers work on it
• updates are slower than ARM or RISC-V

Linux works, but MIPS is no longer a main focus.

BSD systems

NetBSD supports MIPS very well.

NetBSD is famous for running on many architectures, and MIPS was one of its strong ones.

OpenBSD also supported MIPS, mostly for embedded systems.

These are still possible, but niche.

Desktop operating systems

Modern desktop operating systems do not support MIPS.

No support from:
• Windows
• macOS
• mainstream desktop Linux distros

MIPS was never aimed at normal desktop users.

Did Android support MIPS?

Yes. You are right.

Android did support MIPS in the past.

Important points:
• Android once supported ARM, x86, and MIPS
• MIPS Android devices existed, but very few
• App support was poor
• Google dropped MIPS support after Android 5.x

Today:
• Android supports ARM
• x86 exists mostly for emulators
• MIPS is no longer supported

Why MIPS lost to ARM and RISC-V

Several things happened at once.
• ARM improved fast and took over phones
• Embedded companies standardized on ARM
• MIPS licensing became confusing
• Developers moved away
• Tooling stopped improving

Then RISC-V appeared.

RISC-V offered:
• the same clean RISC idea
• no license fees
• modern ecosystem growth

That made MIPS less attractive for new designs.

Who should use MIPS today?

Realistically, only a few cases.

MIPS makes sense if:
• you maintain old routers or devices
• you work with legacy firmware
• replacing hardware is too risky
• you study computer architecture

MIPS does not make sense for:
• new products
• phones
• desktops
• long-term projects

ARM or RISC-V are better choices today.

MIPS today in one sentence

MIPS is no longer the future, but it is still part of the present.

Why MIPS still matters

MIPS taught the industry:
• how clean RISC design works
• how pipelines should be built
• how compilers and CPUs cooperate

ARM and RISC-V learned a lot from MIPS.

Even if the architecture fades, the ideas live on.

Final thoughts

MIPS didn’t fail loudly.

It just quietly stepped aside.

If you understand MIPS, you understand:
• modern CPUs
• why RISC works
• why simplicity matters

And that knowledge is still valuable today.

RISC-V Architecture: how a clean instruction set became a serious threat

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 19:36:54 +0000

What an architecture actually defines

An instruction set architecture defines:
• the instructions a CPU understands
• register layout
• privilege levels
• memory ordering rules
• how software talks to hardware

It does not define:
• pipeline depth
• cache design
• clock speed
• manufacturing process

Two RISC-V CPUs can run the same program and still be completely different internally.

Why RISC exists

RISC means Reduced Instruction Set Computing. The idea is to keep instructions simple and predictable so compilers and hardware can be efficient.

Compared to this:
• x86 is complex and full of legacy behavior
• ARM is RISC but controlled and licensed

RISC-V keeps the RISC philosophy but removes ownership .

The base instruction set

Every RISC-V CPU starts with a base ISA.

RV32I and RV64I are the foundations.

RV32I is a 32-bit integer instruction set.
RV64I is a 64-bit integer instruction set.

The base includes:
• integer arithmetic
• control flow
• memory load and store
• 32 general-purpose registers

There is no multiplication, floating point, or atomics in the base. Those are added only if needed.

This is why RISC-V works well for tiny chips.

Extensions are how RISC-V scales

RISC-V is modular. Features are added using extensions.

Common extensions:
• M for multiply and divide
• A for atomic instructions
• F and D for floating point
• C for compressed instructions
• V for vector processing

A Linux-capable system usually supports:
RV64IMAFDC

This means the CPU includes only what it needs. No wasted complexity.

Registers and calling conventions

RISC-V has 32 integer registers.

Some examples:
• x0 is always zero
• x1 is the return address
• x2 is the stack pointer

Nothing is hidden. Nothing is special without documentation. This makes compilers, debuggers, and OS kernels simpler.

Privilege modes and operating systems

RISC-V defines three privilege levels:
• machine mode for firmware
• supervisor mode for the kernel
• user mode for applications

This matches modern OS design perfectly.

Because of this, Linux support was straightforward.

Linux runs natively on RISC-V with full kernel support.

Memory model

RISC-V uses a relaxed memory model. Instructions may be reordered unless explicitly prevented.

This improves performance and scalability but requires correct synchronization.

The design is similar to ARM, not x86.

Microarchitecture freedom

RISC-V does not force one CPU design.

Implementations can be:
• in-order or out-of-order
• single-core or many-core
• tiny microcontrollers or server CPUs

The same software can run on all of them.

Operating systems that support RISC-V

Fully supported operating systems:
• Linux
• FreeBSD
• Zephyr
• RTEMS

Experimental or partial support:
• Android
• research Windows ports

Linux support is the most important signal of maturity.

Real RISC-V processors available today

Embedded and microcontroller level:
• ESP32-C3
• ESP32-C6
• Microchip PolarFire SoC

Linux-capable processors:
• SiFive Performance series
• Alibaba T-Head Xuantie

These are real chips that boot Linux and run real workloads.

Who should use RISC-V

RISC-V is ideal for:
• custom silicon designers
• embedded and IoT devices
• governments and public infrastructure
• research and education
• long-term platforms avoiding vendor lock-in

It is not ideal yet for:
• high-end consumer desktops
• gaming systems
• proprietary driver-heavy environments

Why RISC-V is succeeding where others failed

Unlike Intel Itanium, RISC-V does not try to replace everything at once.

It grows gradually.
It coexists.
It does not force migration.

That is why it is working.

Final thoughts

RISC-V is not exciting because it is fast today.
It is exciting because it is free, simple, and stable.

It is an architecture designed to last decades.

That alone makes it one of the most important CPU designs of our time.

Intel Itanium: the CPU architecture that tried to replace x86 (and didn’t)

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 19:31:56 +0000

Before we talk about why Intel Itanium failed,
we need to talk about something most people skip:

👉 instruction sets and CPU philosophy

Because Itanium didn’t just lose a market.
It lost a philosophical argument.

First: what is an instruction set (ISA)?

An Instruction Set Architecture (ISA) is the language a CPU understands.

Not C.
Not Java.
Not Python.

But the lowest-level commands like:
• load this value
• add these registers
• jump if condition fails

Examples:
• x86
• ARM
• RISC-V

Every operating system, compiler, and kernel is built around an ISA.

Change the ISA → rewrite everything.

RISC vs CISC (quick, practical explanation)

CISC Complex Instruction Set Computing

Example: x86
• Instructions do a lot
• Variable instruction length
• Decades of backward compatibility
• Hardware does heavy lifting at runtime

Pros:
• Older software keeps running
• Easier compiler targets

Cons:
• Complex CPU design
• Hard to reason about internally

RISC Reduced Instruction Set Computing

Examples: ARM, RISC-V
• Simple, fixed-size instructions
• Fewer instruction types
• Compiler handles complexity
• Hardware stays simpler

Pros:
• Efficient
• Predictable
• Scales well

Cons:
• Relies on good compilers

Where Itanium fits: neither RISC nor CISC (really)

Itanium introduced something else:

EPIC

EPIC = Explicitly Parallel Instruction Computing

The idea:

“Stop guessing at runtime.
Let the compiler explicitly tell the CPU what can run in parallel.”

So instead of the CPU dynamically:
• reordering instructions
• guessing dependencies
• speculating aggressively

The compiler:
• analyzes the program
• finds parallelism
• bundles instructions together

The CPU executes exactly what it’s told.

On paper?
Beautiful.

IA-64: Itanium’s instruction set

Itanium used IA-64, a completely new ISA.

Key characteristics:
• Very large instruction words
• Explicit parallel instruction bundles
• Massive register files
• Aggressive reliance on compile-time analysis

This makes IA-64:
• closer to RISC in simplicity
• but stricter than RISC
• and far less forgiving

If the compiler messes up → performance collapses.

Why EPIC struggled in the real world

The real world is messy.
• branches are unpredictable
• memory latency varies
• workloads change dynamically
• modern software is huge

Compilers cannot perfectly predict runtime behavior.

So CPUs like x86:
• speculate
• reorder dynamically
• recover from mistakes

Itanium couldn’t adapt well once compiled.

The design assumed:

“We can know enough ahead of time.”

Reality said:

“No, you can’t.”

Meanwhile… x86 cheated (successfully)

While Itanium bet everything on clean design,
x86-64 did something sneaky:
• kept the ugly CISC ISA
• translated instructions internally into RISC-like micro-ops
• used massive runtime scheduling logic

So x86 became:
• internally RISC-ish
• externally backward compatible

That hybrid approach won.

Not elegant.
But effective.

Who used Itanium anyway?

Only environments where:
• software was rewritten specifically for IA-64
• hardware costs didn’t matter
• long-term stability mattered more than ecosystem

Mostly running:
• HP-UX
• OpenVMS
• NonStop OS

Not general-purpose systems.
Not desktops.
Not startups.

Which operating systems supported IA-64?

Fully supported (historically)
• HP-UX
• OpenVMS
• NonStop OS

Partial / abandoned
• Linux
• Windows (briefly, then abandoned)

Once Windows dropped Itanium, the future was sealed.

The last Itanium processors

The final generation:
• Itanium 9700
• Released around 2017
• Minor refreshes only
• Officially discontinued in early 2020s

No successors.
No revival.

Who needs Itanium today?

Short answer: nobody new.

Long answer:
• legacy enterprise systems still running
• migrations planned but slow
• hardware kept alive via contracts

If you’re designing anything today:
• x86-64
• ARM
• RISC-V

All better choices.

The real lesson of Itanium

Itanium proves something uncomfortable:

The best architecture doesn’t always win.
The one that breaks the least stuff does.

Clean-slate designs are beautiful.
Backward compatibility is ugly.

But ugly survives.

Final thought

Itanium wasn’t a mistake.

It was a perfectly logical design built on a flawed assumption:
that software, compilers, and humans would adapt fast enough.

They didn’t.

And that’s why IA-64 is history and x86 is still here.

SkyOS: a Non-POSIX operating system built by one stubborn person

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 19:21:53 +0000

Most operating systems are built by:
• companies
• foundations
• committees
• or very tired mailing lists

SkyOS was built mostly by one guy.

That alone makes it worth talking about.

Not Linux. Not Windows. Not a clone.

SkyOS wasn’t trying to be:
• a Linux distro
• a Windows replacement
• a Unix philosophy rehash

*It wanted to be a complete desktop OS, designed as a single product.
*
Kernel.
Drivers.
Filesystem.
GUI.
Apps.

All under one vision.

That vision belonged to Robert Szeleney.

SkyOS cared about the desktop experience (early)

This was early–mid 2000s.

At that time:
• Linux desktops felt fragmented
• Windows XP was functional but clunky
• macOS was still finding itself

SkyOS focused hard on:
• visual consistency
• smooth animations
• responsive UI
• clean defaults

Not “hackable first”.
Not “power user first”.

User experience first.

And honestly?
It showed.

A real GUI, not an afterthought

SkyOS didn’t borrow GTK.
Didn’t borrow Qt.
Didn’t wrap X11.

It built:
• its own window manager
• its own UI toolkit
• its own desktop environment

Everything looked like it belonged together same spacing, same behavior, same logic.

That’s rare even today.

The filesystem experiment

SkyOS also experimented with its own filesystem design.

It focused on:
• metadata
• searchability
• structure over raw compatibility

Again: cohesive idea over standards compliance.

SkyOS constantly chose:

“Does this make sense?”
over
“Is this what everyone else does?”

Where SkyOS started hurting

Here’s the part every indie OS hits.
• Closed development model
• Very small user base
• One main developer
• Limited hardware support
• No long-term sustainability

Operating systems aren’t just code.
They’re ecosystems.

Drivers need contributors.
Apps need developers.
Users need trust that it won’t disappear.

SkyOS couldn’t grow that fast enough.

Eventually, development slowed… and then stopped.

Why SkyOS didn’t fail (really)

SkyOS didn’t fail technically.

It failed logistically.

It proved that:
• a single developer can build a serious desktop OS
• cohesion beats feature sprawl
• UX matters even at the OS level

That’s not failure.

That’s a successful experiment with an expiration date.

Why SkyOS still matters

SkyOS is a reminder that:
• desktops don’t have to be messy
• operating systems can feel intentional
• indie systems can push ideas big players ignore

If Oberon taught restraint, SkyOS taught ambition.

Both are necessary.

Final thought

SkyOS didn’t die because it was bad.

It stopped because building an OS alone is brutal.

But for a while, SkyOS showed what happens when one person says:

“I’ll build the whole thing. Properly.”

And honestly that’s kind of legendary.

Oberon OS: A system built by people who hated unnecessary things

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 19:19:05 +0000

Every few years someone says:

“Modern operating systems are too bloated.”

Most of the time, that sentence ends with a Linux distro recommendation.

But Oberon didn’t complain.
It simply chose not to become bloated in the first place.

And it did that decades ago.

A system built by people who hated unnecessary things

Oberon was developed at ETH Zurich, led by Niklaus Wirth the same person who created Pascal and Modula-2.

This matters because Oberon wasn’t “let’s build an OS”.
It was:

“Let’s see what happens if we design everything together, correctly.”

Kernel.
Compiler.
Language.
UI.
Applications.

All one idea.

No POSIX checkbox.
No legacy compatibility guilt.
No “someone might need this later”.

**The Oberon language is the operating system

Oberon is written almost entirely in the Oberon language.**

Not “mostly”.
Not “with some C”.

Almost everything.

Why? Because Wirth believed that if the language is simple, safe, and expressive, the entire system benefits. No impedance mismatch between layers. No glue code nightmares.

The result:
A full OS that is shockingly small.

Small enough that you can actually understand it.

The UI idea that still feels weird (and smart)

Oberon didn’t really believe in traditional GUIs.

Instead, it believed in text.

Commands weren’t hidden behind menus they lived directly inside documents. You’d click a command written as text, and it would execute.

Documentation wasn’t separate from interaction.
The UI wasn’t separate from content.

This sounds alien today but it quietly solves a lot of problems modern systems keep reinventing.

No config screens.
No “where is this option”.
The system explains itself as you use it.

Performance by subtraction

Oberon wasn’t fast because of clever optimizations.

It was fast because:
• there was less code
• fewer abstractions
• fewer layers pretending to be helpful

Memory management was tight.
Scheduling was predictable.
The system did exactly what it said it would do.

Nothing more.

Nothing hidden.

Why Oberon never became mainstream

Short answer: it didn’t want to.

Longer answer:
• No POSIX compatibility
• No easy way to port existing Unix software
• Academic focus instead of ecosystem growth
• Required users to learn Oberon’s way

Oberon wasn’t designed to win adoption wars.
It was designed to prove a point.

And it succeeded at that.

Why Oberon still matters (especially now)

In a world of:
• multi-GB OS installs
• undocumented behavior
• layers on top of layers on top of layers

Oberon asks an uncomfortable question:

What if most of this isn’t actually necessary?

It reminds us that:
• simplicity scales
• correctness compounds
• small systems are easier to trust

You don’t need to run Oberon daily to learn from it.
You just need to study how unapologetically focused it was.

Final thought

Oberon didn’t fail.

It finished its experiment.

And left behind a blueprint most of us are still too afraid to follow.

RISC OS: A Non-POSIX Operating System That Grew With ARM

Pʀᴀɴᴀᴠ — Tue, 30 Dec 2025 19:15:27 +0000

Most desktop operating systems were adapted to new processors.

They started on one architecture, then were ported, patched, and abstracted to survive hardware change.

RISC OS followed the opposite path.

It was designed for ARM from the beginning, and in doing so, it shaped both a processor family and a desktop operating system around each other.

RISC OS is not Unix.
It is not Linux.
It is not POSIX at its core.

It is a desktop OS that evolved alongside ARM, not on top of it.

What This Operating System Is

RISC OS is a graphical desktop operating system originally developed for Acorn computers.

It provides:
• a native windowing desktop
• a coherent GUI toolkit
• its own application model
• a tightly integrated system design

RISC OS is a complete, standalone OS.
It is not a distribution, not a compatibility layer, and not derived from Unix ideas.

Why RISC OS Exists

In the 1980s, Acorn needed an operating system for a new kind of processor.

Existing CPUs were complex and power-hungry.
Acorn wanted something simpler and faster.

That decision led to:
• the creation of the ARM architecture
• an operating system designed specifically to exploit it

RISC OS exists because its designers believed:

software should match the hardware, not fight it.

Instead of adding abstraction to hide hardware details, RISC OS was built to work with the processor’s strengths.

Kernel

RISC OS uses a monolithic kernel, but with a very compact and efficient design.

Kernel responsibilities include:
• task scheduling
• memory management
• interrupt handling
• core system services

The kernel is small and fast, reflecting the simplicity of early ARM processors.

Many system features are implemented as modules rather than being permanently embedded in the kernel.

POSIX Status

RISC OS is not POSIX-compliant.

It does not implement:
• POSIX system calls
• Unix process and signal models
• fork / exec semantics
• Unix permissions

Some POSIX-like environments have existed as optional layers, but they are not central to the OS.

RISC OS follows its own application and system model.

Processor Architecture

RISC OS primarily targets:
• ARM processors

Historically, it ran on:
• Acorn ARM systems

Today, it runs on:
• Raspberry Pi
• modern ARM-based boards

The OS is tightly coupled to ARM’s design:
• simple instruction set
• fast interrupt handling
• low power usage

This tight coupling is a strength, not a limitation.

File System

RISC OS uses a distinct filesystem model that differs from Unix conventions.

Characteristics include:
• file types stored as metadata, not extensions
• simple permission handling
• desktop-oriented file access

The filesystem is designed for:
• personal computing
• local storage
• clarity and speed

It is not aimed at:
• large multi-user systems
• enterprise storage
• complex permission hierarchies

Hardware Requirements

RISC OS has modest hardware requirements.

Typical expectations:
• CPU: ARM processor
• RAM: low to moderate
• Storage: small local disk or SD card
• Graphics: basic ARM-compatible display hardware

It runs well on:
• Raspberry Pi
• low-power ARM desktops
• embedded ARM systems

It does not require powerful GPUs or large memory pools.

Who Should Use RISC OS

RISC OS makes sense for people who:
• enjoy alternative desktop computing models
• work with ARM hardware
• value responsiveness and simplicity
• explore OS history that is still usable today

It is especially useful for:
• hobbyist desktops
• educational environments
• low-power ARM systems

Where RISC OS Does Not Make Sense

RISC OS is not suitable for:
• modern commercial desktop software
• gaming
• POSIX-dependent applications
• enterprise environments

Its ecosystem is small and focused, by design.

RISC OS remains relevant because it proves something rare:

a desktop operating system does not need Unix heritage to survive decades.

It survived because it matched its hardware closely, stayed small, and avoided chasing trends it did not need.