Skip to main content

CPUs and instruction set architecture (ISA)s - Introduction

As programmers we often work several layers above cpu instructions, working with tools that make our lives simple, easy, and stress free!

Hahah, of course that isn't the case. We face different challenges at different levels in the system.

It really is amazing to think about what goes into a typical appliation level software stack, for example:

These millions+ lines of code that a Linux, Windows, or web application is running on top of means the details of the hardware and processor are abstracted to a far away land. Processor features and the Instruction Set Architecture (ISA) often don't matter from a functional perspective. Tools, OSes and other systems take care of lower level details.

You might choose a particular processor or processor family for specific attributes, but often as long as you've got a compiler and other tools for that processor you don't really care what ISA is being used.

Goal Care about CPU and ISA?
Application development Nope
Low power Nope
DSP selection I don't think so
Microprocessor device drivers Nope
Microprocessor debugging Yes
OS/RTOS development Yes (sometimes)
Note: These are generalizations, your needs may vary

Application development

Almost all application development (Linux, Windows, OSX, iOS etc) is done using higher level tools. We don't need to concern ourselves with the CPU or ISA.

Low power cpu

If you are targetting low power consumption you'll very likely end up with an ARM or other non-x86 CPU. Do the particular instructions matter? Not really. We'll be writing our software in C/C++/golang/rust etc, and we'll be using an OS or RTOS.

Choosing a DSP

I have no idea. I've never worked on DSPs, however if you are implementing an algorithm that requires high performance mathematical operations, and you are writing it in assembly, then you might care about the ISA of your processor. If it matches up with the mathematical operations you are using that could be a bonus.

Writing device drivers for microprocessors

Perhaps surprisingly, writing a device driver for a piece of hardware, for example the UART device in an STM32 microcontroller, doesn't require knowing anything about a processor's ISA. You will however have to know the details of the hardware and its registers and function. To interact with the hardware you'll be reading and writing memory using C/C++ etc but likely won't need to know about the processor's ISA, except of course if you've got to debug your driver or application on said microprocessor...

Debugging on a microcontroller

When debugging faults and crashes on a microprocessor you'll need to know about the CPU and processor ISA. Processor details like the CPU fault registers and how the CPU detects and handles faults can be necessary to efficently debug your application. Understanding assembly instructions can lead to tracing faults back to what your software is doing and locating faults like reads from misaligned addresses, null pointer dereferences, stack overflows etc.

Developing an RTOS/OS

OSes need to be CPU/ISA aware as they often provide features like thread synchronization through atomic memory access, and this requires the use of specific instructions/registers. OSes such as Linux and Windows that run on more capable processors will make use of processor MMUs for paging, exceptions, and protection, things like execution rings to protect the OS from applications, virtualization features, and countless other processor features.

What's next?

I'd like to learn more about the internals of processors. What better way thank by designing, implementing, and testing our own toy processor and instruction set for fun!

Upcoming posts will cover how this goes!

Labels:

Comments

Post a Comment

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr
5 comments
Read more

Graco Swing By Me - Battery to AC wall adapter modification

If you have one of these Graco battery powered swings you are probably familiar with the cost of C batteries! The swing takes four of them and they only last a handful of days. I'm not sure if the newer models support being plugged into the wall but ours didn't. If you are a little familiar with electronics and soldering, here is a rough guide on how you can modify yours to plug in! I wasn't sure how exactly to disassemble the swing side where the batteries were. I was able to open up the clamshell a bit but throughout this mod I was unable to determine how to fully separate the pieces. I suspect that there is some kind of a slip plate on the moving arm portion. The two parts of the plastic are assembled and the moving arm portion with the slip plate is slid onto the shaft. Because of the tension in that slip plate it doesn't want to back away, and because of the mechanicals that portion of the assembly doesn't appear accessible in order to free it. I was
Post a Comment
Read more

Memory efficient queuing of variable length elements

In embedded environments memory can be a critical driver of the design of data structures and containers. Computing resources have been expanding steadily each year but there are still a wide range of systems with far less than a megabyte of memory. On systems with tens of kilobytes of memory, structures are often designed to be compact to maximize data density. Rather than splurging on memory aligned elements that would be faster for the processor to access, a developer will typically use types with minimal sizes based on the known range of values that the element is intending to hold. Fixed sized buffers At my day job a fixed size pool of messages was implemented to hold message data. While this achieved one design goal of using statically allocated buffers, avoiding dynamic allocations that might fail at runtime, it isn't efficient if there is a wide range of message sizes. It isn't efficient because each message uses a message buffer. With small message sizes the buff
2 comments
Read more