In Randall Hyde's Art of Assembly it says the 8088 CPU was 8 bits whilst the 8086 was 16 bits solely because of the width of the data bus.
I have always thought that the address size determined the size of the CPU.
Please shed some light on this issue.
From Wikipedia
The 16-bit registers and the one megabyte address range were unchanged, however. In fact, according to the Intel documentation, the 8086 and 8088 have the same execution unit (EU)—only the bus interface unit (BIU) is different.
So the processor is functionally identical, but the memory bus is smaller. The main purpose was for compatibility with 8-bit interfaces. If a 16-bit interface was wanted, then it would take 2 CPU cycles to accomplish what the 8086 could do in one.
There was a greater availability of 8-bit chips at the time.
I can't find any official definition of the property "x-bit cpu", i suppose it does not exist.
I would say that "x-bit cpu" property indicates that the cpu can manipulate the data (inside the chip) with the size of "x-bits" at once. To be more specific it has so called general registers with the size of "x"bits. So it can add (subtract, divide, multiply, xor etc) the data of "x-bits" length at once.
8086 has 16-bit general registers = 16-bit cpu
8088 has 16-bit general registers = 16-bit cpu
80510 has 32-bit general registers = 32-bit cpu
Again, the official definition of the property is unknown.
the wiki about ia-32 says =
The primary defining characteristic of IA-32 is the availability of
32-bit general-purpose processor registers (for example, EAX and EBX),
32-bit integer arithmetic and logical operations, 32-bit offsets
within a segment in protected mode, and the translation of segmented
addresses to 32-bit linear addresses.
I prefer to think that the bitnes of general registers is enough to determine the x-bit cpu property.
The funny thing is intel itself defines cpu bitness by using different criteria from time to time. if you look at the official intel doc it says
8088 is 8-bit hmos microprocessor
( i suppose they defined 8-bit cpu based on 8-bit data bus interface. remember this criteria). At the same time they say at the same document that the cpu has
16-bit internal architecture
Thats funny.. 8-bit cpu with 16-bit internal architecture.
Okey. Lets look at another example Intel pentium 510.
They say it is
32-bit microprocessor
the cpu has 64-bit data bus, so based on previous example we would need to say that intel 510 is 64-bit cpu however it is wrong.
The conclusion - to determine cpu bitness look at the size of general registers.
Related
In 8086 microprocessor, we segment the memory into segments of 64K each because of the 16 bit registers (Since a 20 bit address cannot be stored in the 16 bit register). These segments are categorized as code segment, data segment, stack segment and extra segment. This structure is similar to that of created by a process in operating system. Does that mean each process takes up memory equivalent to 4 segments which will be equivalent to 4*64K in case of 8086 ? And if this is true then by doing some more math we can say that only 4 process will be handled by a 8086 microprocessor at a time (i.e. one of the process will be running state and others would be in block or ready state) since maximum of 16 segments are possible (Total memory size / size of each segment = 1MB/64K = 16).
I have just started studying this and saw this equivalence between process and segments. Does any such connection between the segments of the memory and the memory structure of the process actually exists or it's just my crazy imagination ?
A little history helps. Early UNIX(tm) ran on the Digital pdp minicomputer family. The first circulated versions were V6 & V7, which were exclusive to the pdp-11 family. That family could support a whopping 256K of RAM; but the gp register set (used for address formation) were 16bits wide. There was a limited memory protection scheme in the processor, which permitted the kernel (supervisor) to have a separate address space from user (user); and instructions (addresses generated by pc) to be separate from data (generated by other means). This will probably get edited into the dust by pdp-11 fanbois.
At around this time, intel was rolling what was to become the 8086. Current 8-bit CPUs were already straining at a 64K address space limitation, and were using a concept called bank switching to increase that. In bank switching, some sub-ranges of the 64K address space could be re-pointed into a larger memory bank; so although you could carefully address much more memory. The Hitachi 64180 was one of the CPUs that incorporated this into its silicon; most used external memory controllers.
The 8086 addressing scheme was an amalgamation of these notions. You could produce an Operating System which supported dynamically relocated processes and shared text with up to 64K Instruction + 64K Data. The general idea was you take the segment registers out of the programming model, thus if the OS has to relocate the process, it knows that the process had no saved copy of the old segment value. The commercial OS QNX 1.x, 2.x provided this as a model; the later using the 286 extensions to protect against programs that played with the segment registers.
For programs that didn't care about such subtleties (Lotus 123, ...), you could use the segment registers to effectively create a 2^20 address space on the 8086. It is an ugly programming model in this mode because address formation is A=Seg*16+Base, so Seg=1,Base=0 and Seg=0,Base=16 resolve to the same address.
So, you aren't hallucinating, it was quite intentional, if more than a little half-arsed.
I was wondering what is the reason behind branding a MCU as 32 bit or 64 bit. In the simplistic architecture like Harvard or Neumann architecture it used to be width of data bus. But in the market I have seen MCUs which have 64 bit data lines and yet marketed as 32 bit MCUs. Can somebody explain?
It is not true that the bit width of a processor was defined by the data bus width. Intel 8088 (used in the original IBM PC) was a 16bit device with an 8 bit data bus, and Motorola 68008 (Sinclair QL) was a 32bit device with an 8 bit bus.
It is primarily defined by the nature of the instruction set (width of operands) and the register width (necessarily the same).
When most devices had matching bus and instruction/register widths (i.e. prior to about 1980), there was no need for a distinction and that it was unclear whether it refered to bus or register/insttruction width was of little consequence, when narrow bus width bus versions of wide instruction/register devices were introduced it represented a marketing dilemma. The QL was widely advertised as having a 32 bit processor despite its 8 bit bus, while the 8088 was sometimes referred to as an 8/16 bit part. The 68008 could trivially perform 32bit operations in a single instruction - the fact that it took 4 bus cycles to get the operand was transparent to software, and the total number of instruction and data fetch cycles was still far fewer than it would take an 8 bit processor to perform the same 32 bit operation.
Another interesting architecture in this context is ARM architecture v4 that supports a 16 bit mode known as "Thumb" in addition to the 32bit ARM mode, In Thumb mode both the instruction and register set is 16 bit. This has higher code density than ARM mode. Where an external memory interface is used, most ARM v4 parts support both a 16 or 32 bit external bus - either ARM or Thumb may be used with either, but when a 16 bit bus is implemented, Thumb mode generally runs more efficiently than the 32 bit instruction set due to the single bus cycle per instruction or operand fetch.
Given the increasing variety of architectures instruction/register sets and bus widths, it makes sense now to characterise an architecture by its instruction/register set.
Can a 32-bit application utilize more than 4GB between system RAM and video RAM?
Context: Some games (for instance, Skyrim) are compiled under 32-bit architectures. I am running a 64-bit system with 16GB of DDR3 on the motherboard and 4GB of GDDR5 on the graphics card. Does the 32-bit architecture of the program limit its address capability to 4GB of total space, or is the graphics memory (which is on-board the graphics card) in a separate address space, thus neatly allowing the total sum of addressable memory to be greater than 4GB?
I ask because I have no way of knowing whether the paged amount in task manager and the amount of graphics memory used in GPU-Z are independent sets (which would seem to indicate that they are separately addressed, as the sum can be greater than 4GB), or if there is overlap between them.
It does not matters in which the game is compilled. It depends on your OS architecture. As you are uing 64 bit it will utilise all the memory
I have a small confusion.
When we talk about 32-bit architecture and 64-bit architecture what do we actually mean. Do we mean that a 32 bit architecture has 32 bit registers OR 32 bit address-bus OR 32-bit data bus.
What is generally implied?
I would say that usually, this would mean that a 64-bit system has 64-bit address registers. In modern systems, data registers are usually at least as large as the address registers, so the data registers and data bus would likely be equivalently sized.
A 64-bit system, however, usually does not have a 64-bit address bus. There's no point, since there hasn't been enough RAM manufactured in the history of the planet to need a full 64 bit physical address bus. A given system will have a maximum amount of physical RAM that it can address, based on the width of its address bus.
We mean that we have 64 bit of address space for programs.
This usually means that we have 64 bit registers in the CPU (makes sense to have the registers in pointer size) and so on...
a 32 bit architecture means that the ALU (description) is capable of computing 32-bit words. The databus (width) and the registers are included in this definition, as well as adressing.
It means that the registers and stack (!) have a width of 32/64 bits. Address-spaces are often much smaller, see here:
In principle, a 64-bit microprocessor can address 16 exabytes of memory. In practice, it is less than that.
For example, the AMD64 architecture as of 2011 allows 52 bits for physical memory and 48 bits for virtual memory.
wikipedia-link
Well! Thanks a lot for your inputs.
After reading through a lot of articles and online material, I think now I my confusion is no more.
So I would like to briefly summarize.
n-bit CPU:
An n-bit CPU only means that it has n-bit registers which implies an n-bit word size. Don't give a second thought on address/data bus size.
As an example, consider Motorola 68000 processor - which comes in a 32-bit variant ie it is called a 32-bit processor but it has 16-bit data bus and 24-bit address bus. Due to its 24-bit address bus, it can address only 2^24 ie 16 MB of RAM.
Address bus only tells how much RAM can be addressed whereas data bus tells how many units of data can be transferred in one cycle.
68000 processor can thus transact only 2 Bytes of data due to 16 bits in data bus.
Reading through the following instruction table manual I see that integer multiplication is often much faster for 8-bit registers.
In the context of a normal desktop cpu, what does 8-bit register mean? That the value stored within ie a 32-bit register simply happens to be within an 8-bit range? There aren't actual 8-bit registers, right?
There are actual 8-bit registers, and they are just a part of the full register. For example, on Intel cpus:
AL 8-bit
AH 8-bit
AX 16-bit
EAX 32-bit
RAX 64-bit
In pictures:
63 32 24 16 8 0
|-------|-------|-------|-------|-------|-------|-------|-------|
|<- AL->|
|<- AH->|
|<----- AX ---->|
|<------------ EAX ------------>|
|<---------------------------- RAX ---------------------------->|
See this excellent answer to a similar question. Basically, with the Intel x86 architecture, you can access parts of a register. You are right that there aren't actual 8 bit registers, but there are ways to access only parts of a full register. This is a quirk of Intel, due to the 8086 wanting to be as compatible with 8080 as possible. And that quirk was then carried on to newer generations, as the architecture transitioned from 16-bit through 32-bit to 64-bit. Usually, CPUs only support full register access so this partitioning is a bit odd.
In x86 you can address the High and Low halves of a 16-bit register as 8-bit register