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 19:34

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 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.  It had 64 bits from the start, vector/SIMD
operations, symmetric multithreading (before intel), out of order operation,
multiple functional units, on chip memory controllers, multiple memory
channels, etc.  It didn't however have x86 compatibility, that and marketing
killed it.  Amusingly after many $B and many years of process improvements the
Itanium never really bested the alpha even with a much smaller process, much
better memory bandwidth, and embarrassing more transistors.  Sad, seemed like
the linux boom was a bit late for the alpha.  So Dec died, sold alpha to
compaq.... which died and sold alpha to HP which killed of pa-risc, alpha, and
for the most part itanium.  Amusingly arm is now looking at the same space
(servers and hpc).

Amusingly intel is trying to get some folks to migrate their very expensive
mainframe based services to itanium, but it seems like the market is mostly
interested in either staying where they are, of if they do bother to make the
huge outlay to port their software once they want to use a standard commodity
platform instead of a specialty CPU solution looking for a problem.

The alpha originally designed to deliver a factor of 1000 in performance over
it's lifetime (10 in clock, 10 in ipc, and 10 in parallel cores) with all of
the latest greatest architectural features.  They basically completely
designed a CPU from scratch (something that hasn't been done in awhile)
designed for general purpose use.

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.

[ Snipped Ken's proof of i386 byte addressability ]

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.