Re: What factors influence required memory alignment?
- From: Brett Davis <ggtgp@xxxxxxxxx>
- Date: Sat, 13 Jun 2009 04:13:38 GMT
In article
<bc0c7aa3-94fe-4c0d-85b4-1d811143f5c8@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
MitchAlsup <MitchAlsup@xxxxxxx> wrote:
On Jun 12, 7:27 am, joshc <josh.cu...@xxxxxxxxx> wrote:
I'm wondering what factors influence the alignment required when
accessing data from memory. For example, ARMv5 processors require that
32-bit accesses are 32-bit aligned to get the intended result (not
shifted). What dictates this requirement for alignment?
It was thought that creating a requirement that all items be aligned
would be a good thing and eliminate a tiny amount of delay and
hardware in the critical Agen->Cache->LoadAlign path. I designed and
built several of these and was a vocal proponent of same (circa
1980-1993-ish).
It ends up that there is no good way to enforce this kind of
requirement. Indeed, FORTRAN common blocks are notorious for
preventing such alignment on DOUBLE PRECISION operands (also COMPLEX).
Lately, graphics processing algorythms have made it necessary to
support minimally aligned data to satisfy the requirements of short
vector operations (ala SSE, MMX) where several integers, or floating
point values are packed into a single register and/or memory location.
The ability to trap misaligned accesses was added to various x86
processors (on request of MS) so the MS could take a couple of years
and banish the misaligned accesses from their OS(s). This proved to be
impossible en-the-large.
The actual penalty in cycle time is about one 2-input multiplexer
delay compared to a normal aligned-only cache access path, a second
carry chain in the AGEN adder, and when misalignment spans a cache
bank boundary, more power. I consider this a much better solution than
traping and fixing the problem in SW.
Thus, it is my considered opinion that; in this day and age, one
should simply build the misaligned data access path through the first
level cache, and have hardware solve the boundary conditioin problems.
This is one thing we RISC designers got wrong.
Mitch
As a software engineer I thought you got it right back in the 1980s.
Its slightly easier to catch bugs when an odd address read immediately
traps on your CPU.
On the other hand I have worked on vector processors that required
alignment but did not provide useful swizzle operations to enable me to
work around issues in an efficient manner.
For Larrabee I would want odd byte address quad vector loads, (16
floats) I dont know if that is going to happen, but I assume so.
That does bring back bad memories of working on compressed data and
wanting to read lots of 16 bit shorts from odd addresses. PowerPC
provides a neat merge instruction so this is "only" three instructions.
(Two reads and a shifted merge.)
You are right, odd address loads and stores are the way to go.
That was a quick conversion, I started this reply to tell you I liked
enforced load alignment. Then I changed my mind. ;)
In the grand scheme of things it did not matter, had it mattered then
the RISC chips would have quickly relaxed alignment requirements in
newer chips.
The real thing that mattered in all this is to check the high bits of
addresses and enforce addresses exception even if you dont have a proper
MMU. Trying to debug when the CPU is going crazy loading from gibberish
address that wrap around to real memory is insane.
Brett
.
- References:
- What factors influence required memory alignment?
- From: joshc
- Re: What factors influence required memory alignment?
- From: MitchAlsup
- What factors influence required memory alignment?
- Prev by Date: Re: Is Itanium the first 64-bit casualty?
- Next by Date: Re: What factors influence required memory alignment?
- Previous by thread: Re: What factors influence required memory alignment?
- Next by thread: Re: What factors influence required memory alignment?
- Index(es):
Relevant Pages
|
