l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2010 Jun 22 20:04

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Memory addressing?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Memory addressing?

On Tue, 2010-06-22 at 18:05 -0700, Bill Broadley wrote:
> On 06/22/2010 09:46 AM, Chanoch (Ken) Bloom wrote:
> > On Tue, Jun 22, 2010 at 09:11:44AM -0700, Brian Lavender wrote:
> >> Can someone confirm what is correct? 
> >>
> >> Tim and I were discussing memory addressing at Crepeville last night
> >> and we had a disagreement about how memory is addressable. I say that
> >> on today's common intel i386 32 bit architecture (in case you are one of
> >> those souls who builds your hardware from scratch), that memory is byte
> >> (octet) addressable. You can load a byte from memory into the lower 8
> >> bits of a register. Tim says that memory is only addressable on 32 bit
> >> word boundaries.
> Heh, there are many tiny details that depending on your perspective could
> justify either answer.
> Ken is of course correct that a pointer can address a byte.  There are
> performance penalties for unaligned byte accesses, but they work.
> On the other hand from the offchip view you can't load less than a cache line
> from main memory and that's usually 64-128 bytes.  Additionally those requests
> have to be aligned on cache line boundaries.
> Kinda related to the question "is an i386 a 32 bit architecture?"  Well it can
> address 40 bits (with PAE), read/write 64 bit values from main memory
> (doubles), and allow for machines with over 4GB ram.  Granted PAE is gross,
> the segment register bites again.
> > (I don't know of any modern architectures that aren't
> > byte addressable, though MIPS takes some shortcuts in its various jump
> > instructions because the instructions have to be word-aligned.)
> Well, depending on your definition of modern ;-).  The alpha architecture is
> IMO rather modern... even if dead.
> [SNIP the history of the Alpha platform]
> To allow for increased CPU performance they simplified the CPU so they could
> not restrict the clock rate and spend the transistors where they would help
> performance the most.  The original didn't have byte addressing.  To write a
> byte on the original alpha you had to read 64 bits, modify the byte you wanted
> and write 64 bits.
> BTW, I believe this wasn't that a pointer addresses 2^64 64 bit quantities,
> but that the bottom 6 bits of a pointer were mandated by the architecture to
> be zero.

Alpha has the BWX instructions designed to make it easy to load 8-bit
and 16-bit values into memory, but those instructions came to the
architecture 4 years into the product line.

MIPS (the first assembly language a lot of CS students learn) likewise
has special instructions for reading characters, halfwords, and
unaligned parts of words into memory as well. It also requires the
lowest bits of a pointer to be 0 when you use the lw instruction, but
can uses those for the (slower) instructions involved in smaller reads.

All of these fall into the category of what are called alignment
requirements -- you need to use special, slower instructions to read
unaligned data.

The Alpha sounds unique in omitting those features for the first 4
years, but even they had to bow to C's char in the end.

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.