Jump to content


Check out our Community Blogs

Register and join over 40,000 other developers!


Recent Status Updates

View All Updates

Photo
- - - - -

Intel CPU question... Seriously, WTF?

intel x86 address bus

This topic has been archived. This means that you cannot reply to this topic.
3 replies to this topic

#1 DarkLordCthulhu

DarkLordCthulhu

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 422 posts

Posted 21 February 2015 - 11:59 AM

Okay, so I don't know where to put this.  It seems the CodeCall admins have done away with the hardware forum, and I don't know of any good forums for computer hardware outside of CodeCall.  I know of CNet, but I also know that most of the people there are just purely pragmatically minded hardware enthusiasts or techies who obsess over the cache size and clock speed of the latest Intel or AMD CPUs and have probably never heard of such concepts as D flip-flops and RISC architectures.  You know, the kind of people you meet in your A+ class.  I don't know of a better place to ask a question about CPU architecture or implementation, so I'm posting this here.

 

I was reading The Art of Intel x86 Assembly Programming when I came across something that made me go "WTF?"  Apparently 16-bit Intel CPUs address memory in 2-byte chunks and 32-bit Intel CPUs address memory in 4-byte chunks.  Okay, that's not that weird.  But here's where it starts to get really strange: Addresses on the address bus are always even for 16-bit CPUs and a multiple of 4 for 32-bit CPUs.  Anyone who has even a fragmentary understanding of the binary number system knows that if a binary number is always even or a multiple of 4, then the lower-order bit or two bits are always zero.  So one or two lines of the address bus are never used.  Isn't that rather uneconomical?

 

The other weird part is how the CPU accesses data.  16-bit Intel CPUs divide memory into even and odd banks.  The lower-order byte on the data bus has to come from the even bank and the higher-order byte on the data bus has to come from an odd bank.  The book explains how if a 2-byte word is stored at an odd address, say 125, it takes two memory accesses - an access of 124 for the lower-order byte and an access of 126 for the higher-order byte.  Of course, since the even half of the data bus holds the higher-order byte and the odd half holds the lower-order byte, it has to perform an extra operation to exchange them.

 

Nowhere does the book explain what happens when a one-byte value is stored at an even or odd address.  Of course the CPU accesses the entire two-byte word that it's stored on, but how does it know which byte holds the value in question?  And another thing: using this system, doesn't a byte value take up just as much memory as a word value?  Why use bytes at all?  You should just always use 16-bit values.

 

The addressing scheme for a 32-bit CPU is even more convoluted.  Memory is divided into four banks: 0 mod 4, 1 mod 4, 2 mod 4, and 3 mod 4.  You can imagine how ugly this gets.

 

Yes, I know that x86 is a convoluted CISC architecture, and it has many superfluous features that don't make sense because Intel tries to make it backwards-compatible with earlier CPUs.  But that doesn't explain this.  This is not a backwards-compatibility thing.  This is a brand new feature that Intel introduced in their 16-bit CPUs.

 

What practical benefit does this have?  The book doesn't explain this at all.  It basically says "If you look at this diagram more closely, you can see there is a problem with storing a word at an odd address."  It treats it like it's an inherent problem that any CPU will suffer from, that is unavoidable.  The reality is it isn't.  This is something that Intel chose to do.  They didn't have to divide the memory this way, and frankly, they shouldn't have.

 

I am at a loss for words to describe how mind-bogglingly stupid and nonsensical and illogical this is, and also to express my frustration with such a reputed book for not providing a satisfactory explanation.  I have only one question:  Why?


Programming is a journey, not a destination.

#2 0xDEADBEEF

0xDEADBEEF

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 790 posts

Posted 22 February 2015 - 12:32 AM

Interesting.

 

I suspect the answer is along the lines of its more effecient/cheaper - rather than it can't be done. So if we assume the data bus is 16-bits wide, but we can access memory in 8-bit intervals (which is the convention), then both sides of the bus have to be wired to the same point - so what I mean is, the memory 'bank' will be 8-bits wide, and both the lower part and higher part would have to be wired to this. To get our actual value out, the memory would have to put the lower bit on the bus, then switch and put the higher part on - this would involve some tricky synchronisation - and would be twice as slow as having two separate banks. A solution might be to store 16-bit values, but then we lose byte addressing.

 

In regard to '1 or 2 lines of the address bus are never used' - maybe they don't even exist? Sounds like a resonable design choice - with this design we save 1 line and X transistors etc...

 

 


Nowhere does the book explain what happens when a one-byte value is stored at an even or odd address.  Of course the CPU accesses the entire two-byte word that it's stored on, but how does it know which byte holds the value in question?

finding the 1 byte would be up to the programmer/compiler. If you store at an even address you know its the first byte, the odd the second. Most likely the CPU will just fetch the 2 bytes and let you pull the right byte side out of the register.

 

 

 

 And another thing: using this system, doesn't a byte value take up just as much memory as a word value?  Why use bytes at all?  You should just always use 16-bit values.

 
Yes and no. In C/C++ when declaring a structure the memory is laid out sequentially - but crucially padding is often added for alignment. So in this case, if you declared a structure like:
struct {
    char a,
    short b,
    char c
};
You'd waste 2 bytes, however the compiler can be clever and pack things correct, so if you re-arranged it to be:
struct {
    char a;
    char c;
    short b;
}
 
You wouldn't waste it at all.

Edited by 0xDEADBEEF, 22 February 2015 - 03:49 AM.

Creating SEGFAULTs since 1995.


#3 DarkLordCthulhu

DarkLordCthulhu

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 422 posts

Posted 23 February 2015 - 09:22 AM

Thank you for your reply.  You have illuminated a lot of things that were confusing, and I am now a better programmer because I know how to optimize storage space for structs.  I suspected that the lines for the lower bits might not exist, but without the book specifically saying so, I couldn't be sure.  Some of this information may not be available to the public since Intel CPU organization isn't an open platform.  Makes it really frustrating for me, because I hate not understanding things.


Programming is a journey, not a destination.

#4 0xDEADBEEF

0xDEADBEEF

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 790 posts

Posted 23 February 2015 - 01:07 PM

If you are interested in the hardware aspects; I can recommend:

http://www.amazon.co...charles petzold

 

and

 

http://www.amazon.co...tion and design

 

The code book is good; After reading that the fundamental structures that I knew about clicked (i.e going from Transister circuits to logic circuits) - when I did hardward at uni, it started at to high a level to make enough sense.

 

The other book is great and very detailed about how a cpu is designed.

 

 

Most likely the book skipped over saying what one particular hardware implementation would do, is that would be out of scope for the book :)


Creating SEGFAULTs since 1995.





Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download