# How does a 8 bit computer or 'cpu' interpret numbers larger than 255? [duplicate]

Ok so I've searched for this but I can't seem to find Anything related to this.
What I do know is that if the number is bigger than 255 the computer uses a new memory block of 8 bits(1 byte) to store the big number..

So let's say I want the computer to add 255 + 7. That would give me 262 in base 10 but in binary it would have to be:

00 00 <--before
01 06 <--after
(this is in hexadecimal form btw)

How would the computer decode these 2 bytes back to base 10 form/decimal form if the computer can't add 6 and 256 because 255 is the highest number it can add to. How would the computer make this 2 byte answer/result appear as 262 on the screen?

• It never has to become 262 to be displayed as that. It needs to calculate the first digit, a '2', then the second digit, etc. each digit can be calculated by staying below 255. – Aganju Dec 28 '16 at 2:49
• Thanks! That really helps a lot! (; but how would it calculate the first digit a 2, the second a 6, and the last one a 2, to form 262? How can u calculate those numbers with the 2 bytes that the computer is storing in memory. Of course in binary because computers can't understand base 10/decimal digits – CosnotraLF Dec 28 '16 at 3:09
• EDIT: Because the two bytes are: 01 and 06 so lets say the computer INTERPRETS the left most as 256 and the right most as a 6, when it tries to write it on the screen it would LOOK like this:.. 2566 which is not equal to 262, So of course its a more complicated calculation but i wanna know how the calculation is done so that i can implement it on a 8 bit computer that im currently making. – CosnotraLF Dec 28 '16 at 3:17
• This is called binary to decimal conversion in limited precision, one of the example is converting 16-bit number (just like your 0106) to decimal with only 8-bit ALU – Martheen Cahya Paulo Dec 28 '16 at 3:48
• haven't read your whole q 'cos i'm doing something simultaneously right now but bear in mind that in theory you can count past 9 or 10 despite just having 10 fingers. – barlop Dec 28 '16 at 4:13

First, see Aganju's comment below the question.

Now, as for how the computer can keep track of that, I can give you my knowledge from 16-bit programming. The concepts are likely the same. (However, the exact precise answer could be implementation-dependent. In other words, the people who design the chips could, at least in theory, make different decisions on how it works.)

When you add two numbers that are 8 bit, the biggest number you can get (0xFF + 0xFF = 1FE). In fact, if you multiply two numbers that are 8-bit, the biggest number you can get (0xFF * 0xFF = 0xFE01) is still 16 bits, twice of 8-bits.

Now, you may be assuming that an 8-bit processor can only keep track of 8-bits. That's not accurate. The 8-bit processor receives data in 8-bit chunks. (These "chunks" typically have a formal term: a "word". On an 8-bit processor, 8-bit words are used. On a 64-bit processor, 64 bit words can be used.)

So, when you give the computer 3 bytes:
Byte #1: The MUL instruction
Byte #2: the high order bytes (e.g., 0xA5)
Byte #3: the lower order bytes (e.g., 0xCB)
The computer can generate a result that is more than 8 bits. The CPU may generate results like this:
0100 0000 0100 0010 xxxx xxxx xxxx xxxx 1101 0111
a.k.a.:
0x4082xxxxD7
Now, let me interpret that for you:
0x just means the following digits are hexadecimal.
I will discuss the "40" in more detail momentarily.
82 is part of the "A" register, which is a series of 8 bits.
xx and xx are part of two other registers, named the "B" register and the "C" register.
D7 would fit in more bits, called the "D" register.
A register is just a piece of memory. Registers are built into the CPUs, so the CPU can access registers without needing to interact with the memory on a RAM stick.

So the mathematical result of 0xA5 times 0xCB is 0x82D7.

Now, why did the bits get split into the A and D registers instead of the A and B registers, or the C and D registers? Well, once again, this is a sample scenario that I'm using, meant to be rather similar in concept to a real Assembly language (Intel x86 16-bit, as used by the Intel 8080 and 8088 and many newer CPUs). There might be some common rules, such as the "C" register typically being used as an index for counting operations (typical for loops), and the "B" register being used for keeping track of offsets that help to specify memory locations. So, "A" and "D" may be more common for some of the common arithmetic functions.

Each CPU instruction should have some documentation, used by people who program in Assembly. That documentation should specify what registers get used by each instruction. (So the choice about which registers to use is often specified by the designers of the CPU, not the Assembly language programmers. Although, there can be some flexibility.)

Now, getting back to the "40" in the above example: that is a series of bits, often called the "flags register". Each bit in the flags register has a name. For example, there is an "overflow" bit that the CPU may set if the resulting is bigger than the space that can store one byte of the results. (The "overflow" bit may often be referred to by the abbreviated name of "OF". That's a capital o, not a zero.) Software can check for the value of this flag and notice the "problem". Working with this bit is often handled invisibly by higher-level languages, so beginning programmers often don't learn about how to interact with the CPU flags. However, Assembly programmers may commonly access some of these flags in a way very similar to other variables.
For instance, you might have multiple ADD instructions. One ADD instruction might store 16 bits of results in the A register and the D register, while another instruction might just store the 8 low bits in the A register, ignore the D register, and specify the overflow bit. Then, later (after storing the results of the A register into main RAM), you could use another ADD instruction that stores just the 8 high bits in a register (possibly the A register.) Whether you would need to use an overflow flag may depend on just what multiplication instruction you use.

(There is also commonly an "underflow" flag, in case you subtract too much to fit in the desired result.)

Just to show you how complicated things got:
The Intel 4004 was a 4-bit CPU
The Intel 8008 was an 8-bit CPU. It had 8-bit registers named A, B, C, and D.
The Intel 8086 was a 16-bit CPU. It had 16-bit registers named AX, BX, CX, and DX.
The Intel 80386 was a 32-bit CPU. It had 32-bit registers named EAX, EBX, ECX, and EDX.
The Intel x64 CPUs have 64-bit registers named RAX, RBX, RCX, and RDX.
The x64 chips can run 16-bit code (in some operating modes), and can interpret 16-bit instructions. When doing so, the bits that make up the AX register are half of the bits that make up the EAX register, which are half of the bits that make up the RAX register. So anytime you change the value of AX, you are also changing EAX and RAX, because those bits used by AX are part of the bits used by RAX.
There are more flags and registers than just the ones that I've mentioned.
Now, if you're on an 8-bit CPU, when you write to memory, you may find some restrictions about being able to refer to an address of 8-bits, not an address of 4 bits or 16-bits. The details will vary based on the CPU, but if you have such restrictions, then the CPU may be dealing with 8-bit words, which is why the CPU is most commonly referred to as an "8-bit CPU".

• Very helpful! +10000 – CosnotraLF Dec 29 '16 at 17:28