Searching \ for '[EE] DDR SDRAM 64 bits wide' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=dram
Search entire site for: 'DDR SDRAM 64 bits wide'.

Exact match. Not showing close matches.
PICList Thread
'[EE] DDR SDRAM 64 bits wide'
2009\07\07@124809 by solarwind

picon face
When (on a desktop computer) you compile a program and declare a
variable like this:

char a = 0;

a is 8 bits. However, DDR SDRAM is 64 bits wide per addressable
register (I believe). So what happens to the other 7 bytes in the
register? Do they just get wasted? Or does the compiler do some clever
bit manipulation to stuff more than one variable in the same register?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\07\07@130254 by Marcel Birthelmer

picon face
On Tue, Jul 7, 2009 at 9:47 AM, solarwind<spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:
> When (on a desktop computer) you compile a program and declare a
> variable like this:
>
> char a = 0;
>
> a is 8 bits. However, DDR SDRAM is 64 bits wide per addressable
> register (I believe). So what happens to the other 7 bytes in the
> register? Do they just get wasted? Or does the compiler do some clever
> bit manipulation to stuff more than one variable in the same register?

Depends on the compiler and settings. Sometimes they will put the
variables one after another (called 'packing'), sometimes not. For
example, if you have a structure as follows:
struct mystruct {
char a;
char b;
char c;
int d;
} foo;

then this can be either 12 bytes or 8 bytes in length (assuming a
32-bit int). One saves space, the other is better in performance
terms.

2009\07\07@130334 by M. Adam Davis

face picon face
The CPU can address bytes, words, etc.  So it'll shove it into a
memory address and pack other bytes around it.  Nothing is wasted
unless the compiler has decided to go for performance at the cost of
memory (sometimes aligned memory accesses - at the 32 or 64 bit
boundaries - are faster)

-Adam

On Tue, Jul 7, 2009 at 12:47 PM, solarwind<.....x.solarwind.xKILLspamspam@spam@gmail.com> wrote:
{Quote hidden}

> -

2009\07\07@131839 by Isaac Marino Bavaresco

flavicon
face
solarwind escreveu:
> When (on a desktop computer) you compile a program and declare a
> variable like this:
>
> char a = 0;
>
> a is 8 bits. However, DDR SDRAM is 64 bits wide per addressable
> register (I believe). So what happens to the other 7 bytes in the
> register? Do they just get wasted? Or does the compiler do some clever
> bit manipulation to stuff more than one variable in the same register?
>  

There are byte mask pins (DQMx), that tell the memory which bytes should
be read or written.


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\07\07@134506 by olin piclist

face picon face
solarwind wrote:
> When (on a desktop computer) you compile a program and declare a
> variable like this:
>
> char a = 0;
>
> a is 8 bits. However, DDR SDRAM is 64 bits wide per addressable
> register (I believe). So what happens to the other 7 bytes in the
> register? Do they just get wasted? Or does the compiler do some clever
> bit manipulation to stuff more than one variable in the same register?

Keep in mind that what the CPU acts on is a few layers removed from the bulk
RAM.  There are nowadays at least 2 levels of cache in there on real
systems.  If a single byte is modified, it may sit in a cache for a while
before it is written to its ultimate destination, and other writes may get
aggregated with it.  The other unwritten bytes may have been read from the
RAM to the cache in the first place, so re-writing them does no harm.  I
also expect (I haven't looked) that the RAM can be told to write only a
subset of the 8 bytes it could write at once.

What you're asking about is no different than updating a small piece of a
disk file even though the file is spread accross multiple disk sectors that
each must be read or written as a whole.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\07\07@150456 by Herbert Graf

picon face
On Tue, 2009-07-07 at 13:20 -0400, Olin Lathrop wrote:
> Keep in mind that what the CPU acts on is a few layers removed from the bulk
> RAM.  There are nowadays at least 2 levels of cache in there on real
> systems.  If a single byte is modified, it may sit in a cache for a while
> before it is written to its ultimate destination, and other writes may get
> aggregated with it.  The other unwritten bytes may have been read from the
> RAM to the cache in the first place, so re-writing them does no harm.  I
> also expect (I haven't looked) that the RAM can be told to write only a
> subset of the 8 bytes it could write at once.
>
> What you're asking about is no different than updating a small piece of a
> disk file even though the file is spread accross multiple disk sectors that
> each must be read or written as a whole.

Very true. To add to that, remember too that on a modern PC the memory
address a CPU gives to a program is virtual, it doesn't even have to
reside in the DIMM. Paging can mean that your data eventually ends up on
the disk as a virtualized page.

For even more abstraction, there is now a push toward virtual machines,
meaning your memory location might one day be virtualized multiple
times!

TTYL

2009\07\07@181735 by William \Chops\ Westfield

face picon face
On Jul 7, 2009, at 9:47 AM, solarwind wrote:

> DDR SDRAM is 64 bits wide per addressable register (I believe). So  
> what happens to the other 7 bytes in theregister [when you do a byte  
> operation]? Do they just get wasted? Or does the compiler do some  
> clever bit manipulation to stuff more than one variable in the same  
> register?

Other people have answered in more detail, but the KEY point is that  
this sort of thing is usually handled by the CPU HARDWARE rather than  
by the compiler (x86 assembler still has operations on byte-wide  
operands, for example.)
This is exactly similar to the bit instructions on a PIC, which are  
capable of modifying a single bit in byte-wide register without the  
programmer having to explicitly read the byte, modify the desired bit,  
and write the byte back.

BillW

2009\07\08@050255 by Rikard Bosnjakovic

picon face
On Wed, Jul 8, 2009 at 00:17, William "Chops" Westfield<westfwspamKILLspammac.com> wrote:

> modifying a single bit in byte-wide register without the
> programmer having to explicitly read the byte, modify the desired bit,
> and write the byte back.

Isn't that (reading a whole byte) exactly what a PIC does? If not,
what about the heavily documented bug/issue/flaw/feature regarding
read-modify-write-operations?


--
- Rikard.

2009\07\08@051427 by William \Chops\ Westfield

face picon face

On Jul 8, 2009, at 2:02 AM, Rikard Bosnjakovic wrote:

>> modifying a single bit in byte-wide register without the
>> programmer having to explicitly read the byte, modify the desired  
>> bit,
>> and write the byte back.
>
> Isn't that (reading a whole byte) exactly what a PIC does?

Yep.  Thus the phrases "the programmer" and "explicitly."

BillW

2009\07\08@053426 by Rikard Bosnjakovic

picon face
On Wed, Jul 8, 2009 at 11:14, William "Chops" Westfield<.....westfwKILLspamspam.....mac.com> wrote:

[...]
> Yep.  Thus the phrases "the programmer" and "explicitly."

Doh. Somehow my eyes missed "programmer".

Sorry for the noise.


--
- Rikard

2009\07\08@120540 by solarwind

picon face
On Wed, Jul 8, 2009 at 5:34 AM, Rikard
Bosnjakovic<EraseMErikard.bosnjakovicspam_OUTspamTakeThisOuTgmail.com> wrote:
> Sorry for the noise.

Don't worry about it. Olin's nagging to insert 0.1 uF decoupling caps
really paid off ;)

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...