Hi and welcome to another in the Arm “What Is” program series. In each episode, we dive into a
tech topic to give you insight and perspective into some of today’s hottest design trends.
I’m Brian Fuller, editor-in-chief at Arm and today we’re going to find out what is
a CPU Architecture?
And to help us with that, I want to introduce Richard Grisenthwaite,
who is senior vice president, chief architecture
and Fellow with Arm. When he’s not helping us understand what is a CPU Architecture,
he enjoys skiing in the winter and spending time hiking in the mountains in the summer.
Let’s dive right in!
Richard, what exactly is a CPU architecture?
That's a great question actually because the term ‘architecture’ is very overused in this industry.
When at Arm we talk about a CPU architecture, we’re really talking about
the contract between the software and the hardware. It defines what a CPU
needs to do, not how it does it. We use the term microarchitecture to describe how it does it,
but the “what it does” is what a CPU architecture defines. And essentially for
a series of instructions that are presented by the software: what results can you expect from that,
what’s the limits of allowed behavior of caches into the memory system and so on.
Arm is a company that has one particular CPU architecture.
There are others out there. How do these architectures differ from each other?
That’s a really great question because it’s easy to imagine they will be radically different. In
reality while they are fundamentally difference like CISC versus RISC, which was a huge subject of
debate back in the ‘80’s – and Arm is very much a RISC architecture. In reality, the nature of
what you can do on any particular architecture is really not that different. There are bias
between them, Arm has a very rich collection of functionalities, which allows it to operate
very efficiently and is also historically was very good at code density with the Thumb
Instruction Set. That’s less important these days and we have concentrated that in 64-bit.
But in reality, the different architectures have quite a lot of similarities in terms
of functionalities they are able to offer. What makes an architecture successful is actually the
number of people that use it. You get this virtual circle that as more people use your architecture,
more people will want to use it and it becomes more popular. It’s a self-fueling
prophecy. And so whereas in the early ‘90’s when Arm started out, there were
tons of different architectures. Every computer company has their own.
In reality, it doesn’t make sense to go through the pain of developing your own architecture and
your own tool chains, keeping all your software running. What you end up wanting to do is amortize
your investment so having a widely licensed architecture that, everyone can make use of,
is easy to access. That actually has been a big part of the secret to Arm’s success.
We have a great deal of technical qualities in there. We got a lot of features,
but actually it’s the business model of Arm, making the architecture so widely available.
Many implementations by having different business models that has made Arm actually so successful in
this industry. And it’s effectively meant that a lot of other organizations saw no benefit in
having their own architecture, so you’ve seen what use to be tens of different
architectures collapse down to a very small number these days.
You covered my next question, which was: What’s unique about the Arm CPU architecture?
How has CPU architectures evolved
over the last twenty years or so? And how do you see them changing in the future?
Obviously, the big thing we did back in 2010 is we moved to being 64-bit wide
in terms of basic register organization. Prior to that people didn’t need that amount of address
space to work with. About twenty years ago, we were working with 32-bit architecture, people had
a smaller amount of memory to work with so things like code density were much more important and so
we had things like the Thumb Instruction Set back then. With a 64-bit architecture, we managed to
take all the learning we had from the 32-bit architecture and keep those features,
keep the goodness of that without carrying some of the legacy that have been designed actually for
some of original uses such as the ACORN computers. We’ve actually managed a tremendous trick of
building popularity around our architecture while having less baggage in it than for example the
x-86 architecture has got. And that’s been a big advantage for us going forward. We have mostly
functionality that everybody needs, we haven’t got a lot of baggage that was there from history,
which is really good. As we go into the future, we’re always interested in the new problems
that come along. What motivates us putting in new things into our architecture are. The new problems
that arise so a couple of years ago, there was a new format that appeared for machine learning,
bfloat. And we introduced instructions to support that. We’re increasingly adding features
to support security because security is a huge area. Security isn’t a problem you solve by doing
one thing. You got so many different aspects of security you got to work on. One of the big areas,
we work on continually with the architecture is adding features to meet computation more secure.
So lots in store. Well, thanks Richard! In just a few minutes you’ve illuminated a fascinating
world into CPU architecture. Check out all our other “What Is” episodes here and be sure to
subscribe to this channel because we’ll be adding more as the year progresses. Thanks for listening!