Stupid (?) question about... bits!

[nls]

Possibly something to add to the FAQ too.

Back in 8bit days, RAM was always 8bit/byte.

Then 16bits came and left, then 32bits and now we have 64bits in our desktops.

Of course if I get it correctly, this 64bit thing is just 64bit addressing. I am not sure if it changed the size of "words" to 64bits.

So I have possibly stupid question, I should have asked somebody 10 or 15 years ago.

Is RAM still 8bits/byte? I find no reference about it.
Is it 16bits? Is it 32bits? Since you can install on the same PC (with the appropriate specs of course) a 32 bit and a 64 bit OS... does this mean that if I install 64 bit OS I have half the RAM? (or better, will then apps use DOUBLE the RAM?)

If I get a 1GB RAM module (whatever module, I don't care at this point), will this be 8388608 bits? Or will it be 2 or 4 times that, or even 8?

To put this in yet an other perspective, if I store a "byte" variable in some compiler, will this really "eat" 1 byte? Or will in fact eat a 16bit, or 32bit or 64bit word (depending on the OS) - being able to use just the 8bits but in fact "loosing" the rest?

English is not my native language and I hope I am getting through.

 

[Xtreeme]

your looking at ram like it is Hard disk and cluser size. Its not. A hard disc MUST use the cluster size no matter what. So if you have a 2k cluster and drop a 1k file on it -it will use 2k of disc space. This is why net servers often use small cluster size and FTP from say desktop pc-500 small files takes a while.

A dword is still a dword from what I know. Addressing is the size it grabs in a chunk I doubt its the size it takes on ram. I mean that would be rediculous waisting all that ram space- its not a physical disc so diff limitations.

read these (it also show why a HIGHER number in refresh is better then lower the only timing that is that way) Hint the longer mem can keep data (less leakage) less time it waistes refetching and refreshing mem.

http://www.howstuffworks.com/ram.htm
http://en.wikipedia.org/wiki/Random_access_memory

bits and bytes
http://computer.howstuffworks.com/bytes.htm

 

[trapilales]

Yes one byte is still 8 bits. Always will be.
1 GB module will have 8 x 1Gbits. (or 8Gbits) no matter what os you use.

64bit CPU or OS refers to a cpu (or OS) that is able to address and use 2^64 bytes of ram. A 32 bit cpu/os can only address 2^32 bits or 4GB.

As far as bytes etc in compilers, this is programming language and compiler specific. You shouldn't have to worry about this.

 

[rallyimprezive]

a nybble is 4 bits

 

[The_Gremlin]

As long as you are talking about x86 computers, a byte is 8 bits. That hasn't change!

All this talk of 32-bit, 64-bit etc. has nothing to do with 1 byte being equal to 8-bits.

Your 1 GB of RAM has 1024*1024*1024*8 = 8,589,934,592 bits.

As things have progressed from 8-bit to 16 ... up to 64-bit, what is really changing is the size of data the hardware can handle. A 32-bit processor handles 32-bits of data at a time. Software to run on a 32-bit processor has to be written with instructions that are no longer than 32-bits.

Likewise, a 64-bit processor handles 64-bits of data at a time. Software to run on a 64-bit processor has to be written with instructions that are no longer than 64-bits.

To answer your question about storing a "byte" variable in memory, it will only "eat" a single byte. However, because of the way memory works, compilers will sometimes use up more than that single byte. There is a trade-off between optimizing the storage capacity of RAM or optimizing speed.

That's the simplified version, I hope it helps.

 

[Xtreeme]

So the trade off is compairable BUT differect from that of cluster sizes to disk. Just in this case its the programer, not the platter that makes this happen.

So like I was thinking, the way the data is stored on ram is diff from how its accessed (fetched). The cpu takes CHUNKS of that size....but the data in ram can be less then that 64bit chunk. If its more it just wont work.......Is that right?

 

[The_Gremlin]

So the trade off is compairable BUT differect from that of cluster sizes to disk. Just in this case its the programer, not the platter that makes this happen.

It's usually the compiler that makes it happen ... unless you're programming in Assembler, then the programmer has pretty much complete control. Generally, compilers today will treat memory like the clusters of a hard drive and save any size variable to one address column (64-bits). However, in the olden days, assembly programmers would compact data into memory by putting multiple variables into a single address column (for example, 8x1-bit binary variables into one 8-bit address space). Memory DOES have a "cluster size" per say, as in the smallest addressable size of data, which is 1 byte, but the bytes are arranged and accessed in columns that match the width of the memory bus (currently 64-bits).

So like I was thinking, the way the data is stored on ram is diff from how its accessed (fetched). The cpu takes CHUNKS of that size....but the data in ram can be less then that 64bit chunk. If its more it just wont work.......Is that right?

The mechanism by which data is written to and read from RAM is similar, but if you ask to read an 8-bit chunk of data, it will still return the entire memory column (64-bits).

 

[nls]

ok people thanks I get it

 

[Hozer]

Now read up on Mebibits, and Gigibytes.

There is a difference!
http://en.wikipedia.org/wiki/Mebibyte