As usual you address the question with more intelligence then the flippant
comment warranted. So I will attempt to respond in kind. Your last comment
None of these problems exist when reading a single byte from an odd
address, because one byte is not big enough to span any boundaries
like a word could be.
seems to me to be very byte centric. The only difference between reading at
an even boundary and odd one is one bit. The as far as the boundaries being
set up as dwords/words/bytes is just a matter of convenience, mainly for
programmers. The hardware can have 7 or 12 bit bytes or whatever seems
appropriate for the task (and has done so in the past). The boundaries are
arbitrary, and with the micro programming available in cpu's, frivolous . I
agree with your points though, however my current task to move between
processors, and this forced optimization (which is what it is), is very
restricting. Consider the following code sample (off the top of my head, so
excuse any minor syntax errors):
struct Index
{
char Key1;
long FileOffset;
};
long GetOffset(char SearchKey1)
{
struct Index idx;
FILE *f = fopen("Index.dat","r");
while(!feof(f))
{
read(f,&idx);
if (idx.Key1 == SearchKey1)
{
fclose(f);
return ide.FileOffset; <<<< this would be an error?
}
}
fclose(f);
return -1; // marker for not found
}
This bottle neck in this code is definitly not the processor. The
processor will be sitting there waiting on the file read. The optimization
does nothing (except save a really small amount of power?). This code
though, is not portable to this processor because it returns FileOffset
which will start at an odd address. The code is designed to be optimized for
disk space, not processor speed. (consider adding many keys each 1 byte
wide). There are times when space is at a greater premium then speed.
I do agree that it may cause 2 memory accesses instead of one, which will be
slower, and there may be cache hits due to this as well. However if this is
of concern to the programmer, then he can optimize with that in mind.
Instead the above code would have to be written as reading it in, and then
moving the tightly packed structure into a looser packed one before the
program can carry on. That is a much greater waste of cpu cycles and memory.
Programmers don't always have a choice on how the data is packed on the
disk. So in my mind this is a design flaw, as the hardware is dictating how
the software is written so that the software must be written in a round
about way.
Just my 2 cents :)
Chris
Personally I think this is a really stupid limitation for a cpu, since
it can obviously read odd addresses for characters, why can't it read it
for integers.
The processor's memory bus is wider than a character, so if you allow it
to read things that are unaligned, then three bad things happen:
(1) The processor's logic becomes more complicated, which increases
costs and power consumption a little.
(2) The value you read might span the boundary between one word and
another, causing you to have to do two memory accesses where
one would've been sufficient if it were aligned.
(3) The same problem with spanning boundaries can reduce cache
performance because (a) one word may require a hit on two
cache lines, which is half as likely to occur than a hit on
just one cache line, and (b) to the extent that words span
cache line boundaries, you are using two cache lines for what
you should only need one for, which makes your cache perform
like it is half as big as it actually is.
None of these problems exist when reading a single byte from an odd
address, because one byte is not big enough to span any boundaries
like a word could be.
So basically, processors can be and have been made that support
unaligned reads, but adding that feature adds to the cost and reduces
performance if you actually use the feature.
- Logan
--
For information on using the PalmSource Developer Forums, or to
unsubscribe, please see http://www.palmos.com/dev/support/forums/
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
