Microcontrollers memory

[brucehoult]

The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).

You mean the accumulator, which stores an operand for ALU?

Maybe...

I prefer to think of the ALU width because there could very well be an overwide accumulator.  I won't go into details but the 16 bit IBM 1130 had a 16 bit accumulator with a 16 bit extension.  True, the extension wasn't called the accumulator but it was coupled to the ALU and used for multiply and divide as well as some shifts.

8080 style CPUs have at least 4 double wide registers SP, BC, DE, HL for holding 16 bit values.  Sure, each register of the pair is only 8 bits but the DAD (double add) did a 16 bit addition in 8 bit chunks as in DAD BC which added BC to HL and left the result in HL.  I'm pretty sure the chip used the same 8 bit ALU.

ALU width doesn't seem like a very good measure to me.

Maybe the 8080 had an 8 bit ALU but I know for a fact the Z80 had a 4 bit ALU. Are you going to call the Z80 a 4 bit processor? That would be strange, as the Z80 runs all 8080 programs.

In the recent RISC-V SoftCPU Contest the 1st place winner VexRiscv uses an 8 bit ALU. The Creativity Prize winner, SERV, uses a bit-serial (i.e. 1 bit) ALU. So, apparently you'd call them an 8 bit processor and a 1 bit processor.

But they both implement exactly the same RV32I instruction set! They run the same programs.

[nctnico]

AFAIK the number of bits of a CPU is the width of the data bus.

[nForce]

Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

[legacy]

AFAIK the number of bits of a CPU is the width of the data bus.

(but referred to the data bus inside the CPU, because ... there are CPUs with 128-bit data bus and it's used to increase the bandwidth with the RAM, but clearly, data are 32 bit, thus transferred as 4 x 32bit words during  boost cycles

yesterday, at the 452123213768240909232433439-th attempt, I understood I'd better avoid asking my colleagues about the energy of the empty space since the only true thing is that quantum mechanics is easier to be clarified as "you'd better don't question(1)"

The same applies to attempts of trying to classify a CPU ...


(1) the question was: WTF is the energy of an empty box containing dark and empty space at -272C?
I would say "zero": if there is neither light (electromagnetic things) nor matter then there is no energy. Easy like a cake! But no & NO! *they said* that it contains a lot of fluctuating pairs of quantum particles thus it has *A LOT* of energy X___X ... and it can also degrade to an not empty universe, where "not empty" is in the meaning of pure energy particles that can get a mass thanks to Higgs field which has no problem at working at -272C (WTF!?!?!? oh, well .. at this point my brain was going to evaporate)


in short: * What * The * Frog *?!?! What does make a 32bit CPU a "32bit" thing?
don't question! unless you are not really afraid of the answers  )

[nctnico]

AFAIK the number of bits of a CPU is the width of the data bus.

(but referred to the data bus inside the CPU, because ... there are CPUs with 128-bit data bus and it's used to increase the bandwidth with the RAM, but clearly, data are 32 bit, thus transferred as 4 x 32bit words during  boost cycles

I wrote the CPU. Not the memory interface!

[legacy]

I wrote the CPU. Not the memory interface!

you wrote "data bus". Technically even the memory interface is a "data bus"
mine was an attempt to make a nice and funny point(1), nothing serious.

(1) specifically, I was laughing about a comment made by guys on a 68080 prototype made around a large FPGA with a 128bit interface to the DRAM ... it happened that someone really asked if it was a new member of the 68k family at 128 bit ...  thanks God he was not a blog-writer

[NorthGuy]

It is often better to avoid classifying things. Classification is only useful when the results of the classification are needed for other things.

[rstofer]

Every attempt to classify something will probably fail.  Why would anybody build a bit-serial ALU?  Beats me but it was done a long time ago when memory was an mercury magnetostrictive delay line 1 bit wide and 320(?) bits deep on some numerical control equipment I was working on.

Why would the Z80 use a 4 bit ALU when the predecessor 8080 used an 8 bit ALU?  Clearly this isn't a 4 bit processor (although I might claim it is!).

We can't use the datapath width and it isn't useful to use the address width.  For every metric that could be chosen, there will be an exception.

So, let's just use whatever the manufacturer chose and move on.

[nForce]

Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

[ataradov]

Why would anybody build a bit-serial ALU?

But even with split ALUs, they still perform an atomic operation on some number of bits.

That VexRiscv with 8-bit ALU, still does only 32-bit computations. It just takes multiple cycles to complete. That ALU as an actual unit takes 32-bit numbers and provides 32-bit outputs. It does not matter how it is done inside.

So that classification holds.

Although I do agree, classifications are arbitrary for a task and useless in abstract.

[coppice]

Why would anybody build a bit-serial ALU?

Bit serial is very gate efficient for low to medium speed requirements. As the speed requirement goes up you either need to move to serial by parallel or full parallel architectures, or have a lot of bit serial hardware working in parallel. When gates were expensive things like entry level PDP8s were available in bit serial form. A number of massively parallel machines (MPP, ASPRO. etc) were built with thousands of bit serial ALUs working in parallel. These had a very low chip count for the throughput they could achieve. However, as geometries became finer things like propagation delays, and clock tree structures began to make these massively parallel structures fail badly. In the late 70s I used to implement DSP solutions with a mix of parallel, serial by parallel and bit serial hardware in the same design, handling aspects of the problem with different throughput requirements. A lot of modest speed DSP in ASICs is still implemented with bit serial arithmetic (e.g. in CD player chips).

[nForce]

I will be happy if someone answers my question. 

[brucehoult]

I will be happy if someone answers my question. 

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.

[nForce]

I will be happy if someone answers my question. 

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.

No, the other one, here:

Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

[rstofer]

I will be happy if someone answers my question. 

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.

No, the other one, here:

Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

As pointed out above, the Z80 uses a 4 bit ALU with 8 bit registers so even ALU width is meaningless as a descriptor.  I never realized the ALU was only 4 bits but, sure enough, it is.

[nForce]

Oh, thanks rstofer.

But what is then ALU width, if the registers width is different?

And another question what is the width of the memory word in a modern computer? Is it 64 bits? Or is it still 8 bits, and the CPU when fetching (fetch cycle) reads 8 words?

[NorthGuy]

But what is then ALU width, if the registers width is different?

There are wires coming into ALU. Some of these wires are supplying operands. The number of wires supplying a single operand would be the width of the ALU.

And another question what is the width of the memory word in a modern computer? Is it 64 bits? Or is it still 8 bits, and the CPU when fetching (fetch cycle) reads 8 words?

Modern PCs use DDR4 memory. Each data wire of the memory chip supplies/accepts data in bursts of 8 bits at a time. DIMM has 64 data wires, which means a memory transaction deals with 8x64 = 512 bits. This is demultiplexed as needed to fit a cache line, which is, coincidently, 64 bytes - the same as DDR4 burst from DIMM. There are multiple levels of cache, which are then interconnected in a fancy way to multiple cores.  The core can fetch as much as it needs. Since some of the registers are 512-bit now, it should be able to fetch the entire 512-bit cache line at a time.

It is all changing at a fast pace. What I write might be already obsolete

[rstofer]

Oh, thanks rstofer.

But what is then ALU width, if the registers width is different?

I would expect modern chips to have an ALU width that is more in line with the nomenclature for the chip.  Most ARMs would have a 32 bit ALU and 32 bit registers.  A modern x64 would have a 64 bit ALU and 64 bit registers but the architecture supports 32 bit subregisters.

To really discuss things like ALU width and memory width, we need to talk about a specific architecture because there are all kinds of variations.

Even IBM, back in the 360 mainframe days differentiated the models by memory path width.  The low end machine had an 8 bit data path and I believe the high end machine had a 64 bit data path. 

And another question what is the width of the memory word in a modern computer? Is it 64 bits? Or is it still 8 bits, and the CPU when fetching (fetch cycle) reads 8 words?

The word length doesn't change, just the number of words read per operation.  If gets complicated due to cache lines and multiword fetch.  See response above re: cache lines.

[westfw]

There are wires coming into ALU. Some of these wires are supplying operands. The number of wires supplying a single operand would be the width of the ALU.

I'm not sure that that explains the z80, unless you are real careful about defining where the edges of the ALU are.
Normally, the ALU is a section of  purely combinatorial logic that has a couple of inputs, and output, and some gates that select what operation should be preformed on the inputs to get the outputs.  To add two numbers, you need a "full adder" circuit (which is about 6 gates) for each bit of the number, and maybe a fast carry lookahead circuit.  The number of full adders implemented would be the "true" width of the ALU.

[brucehoult]

I will be happy if someone answers my question. 

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.

No, the other one, here:

Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

As pointed out above, the Z80 uses a 4 bit ALU with 8 bit registers so even ALU width is meaningless as a descriptor.  I never realized the ALU was only 4 bits but, sure enough, it is.

I don't think any of those hardware-based statistics is the proper measure of 8-bit, 16-bit, 32-bit, 64-bit. They are all just implementation details that could change on a newer compatible processor with a different architecture but that runs all the same programs.

Ok, that basically never happened with microcomputers in the 1970s. Every new processor ran a completely different instruction set. At most -- and even in the 1980s -- at most a new microprocessor could run (most) programs from an older one, but not vice versa.

That wasn't the case with mini-computers and mainframes, even then.

In the 1960s IBM made dozens of different machines that all ran every program for the 32 bit IBM 360 instruction set. Some of them had 8 bit memory busses and some had 64 bit. Some executed most instructions in one clock cycle, and some used a little interpreter program (microcode) that took five or maybe even ten clock cycles to execute even simple instructions.

DEC made a wide range of CPUs that all could run the same PDP-11 programs -- and then a wide range of CPUs that all could run the same VAX programs. Data General and PR1ME did the same. Newer CPUs weren't necessarily faster than older ones -- they also pushed the compatible range down to smaller and cheaper (but slow) machines as time went on.

I think the only meaningful measure is something like "What is the largest data size that a program can use in a single instruction?" (you obviously need to not count things like the x86 "rep" prefix) The bit-ness is a property of the instruction set (and the programs), not of a particular micro-architecture implementing that instruction set.

That can be hard to understand for old instruction sets that only had a single implementation and then were abandoned.

And, yes, I think that means some old CPUs should be reclassified now, and in particular many of the "8 bit" CPUs should be reclassified as 16 bit -- pretty *poor* 16 bit CPUs, but 16 bit nonetheless.

For example the Z80 had single instructions to take the 16 bit contents of HL or IX or IY, add the contents of BC, DE, SP or itself, and put the result back in the original register. You could also add or subtract with carry any of BC, DE, HL or SP to HL, and as these set the flags according to the 16 bit result you could then branch directly according to that. You could directly load a 16 bit constant into any of BC, DE, HL, IX, IY, or SP or load or store a 16 bit value directly to/from any of those to an absolute memory location. You could also add an 8 bit constant to the contents of IX or IY and use the 16 bit result as a memory address to load or store any 8 bit register (A, B, C, D, E, H, L). You could push BC, DE, HL, IX or IY onto the stack, or pop them from the stack.

The only things you couldn't do directly with 16 bit values were to copy from one 16 bit register to another (but something like PUSH DE; POP BC is just two bytes of program code) or to load or store them via a pointer (which also needs two instructions).

The Z80 has a 16 bit instruction set. A pretty inconvenient one, in many ways, but the 8 bit instructions aren't exactly convenient to use either!

[brucehoult]

There are wires coming into ALU. Some of these wires are supplying operands. The number of wires supplying a single operand would be the width of the ALU.

I'm not sure that that explains the z80, unless you are real careful about defining where the edges of the ALU are.
Normally, the ALU is a section of  purely combinatorial logic that has a couple of inputs, and output, and some gates that select what operation should be preformed on the inputs to get the outputs.  To add two numbers, you need a "full adder" circuit (which is about 6 gates) for each bit of the number, and maybe a fast carry lookahead circuit.  The number of full adders implemented would be the "true" width of the ALU.

The Z80 has four full adders.

To add something wider than that it needs to store each 4 bit result into output latches and then go back and read a new set of 4 bit operands from input latches.

[hamster_nz]

... and let us not get started on all the weird and exotic memory addressing models that differentiated 16-bit and 32-bit Operating System environments (esp in x86 land).

[westfw]

The Z80 has four full adders.
To add something wider than that it needs to store each 4 bit result into output latches

Sure, that's fine.  But if you define "the ALU" a bit wider (ie including the output latches, and the circuitry that routes the half-bytes), then you have a "box" that has two 8-bit inputs and a latched 8bit output. Might as well call the whole thing "ALU" - it's not like there were any instructions to do 4bit operations...
(OTOH, I said that the ALU should be merely combinatronic, which would nix that definition.)

[brucehoult]

The Z80 has four full adders.
To add something wider than that it needs to store each 4 bit result into output latches

Sure, that's fine.  But if you define "the ALU" a bit wider (ie including the output latches, and the circuitry that routes the half-bytes), then you have a "box" that has two 8-bit inputs and a latched 8bit output. Might as well call the whole thing "ALU" - it's not like there were any instructions to do 4bit operations...
(OTOH, I said that the ALU should be merely combinatronic, which would nix that definition.)

Not just 8 bit. The Z80 instruction set has instructions to add or subtract two 16 bit values.

[westfw]

instructions to add or subtract two 16 bit values.

Is there a particular name for architectures that let you combine their native-sized registers into larger operands (or conversely: lets you use partial registers as separate smaller registers)?  (Examples being: well, many of the "8bit" CPUs have at least some 16bit instructions, and the 8086 had its whole AL, AH, AX thing.)I've always been a little annoyed that using byte operands on ARM (for example) "wastes" 75% of the register...