Re: Installing debian on Highscreen Alpha 5000 / Alpha PC 164LX
At 05:26 PM 8/20/98 +0200, Paul Slootman wrote:
>> I ... see some "unaligned traps"
>> > kernel: unaligned trap at fffffc00003c228c: fffffc00000514be 28 1
>> > kernel: unaligned trap at fffffc00003c22a0: fffffc00000514d2 28 2
>> but I don´t know what it is?
>It's a bug in the kernel sources, which don't have any bad effect
>besides slowing the machine somewhat; the unaligned traps are, uhm, trapped,
>and the access to the unaligned data is emulated by the kernel. This is a
>lot slower than aligned accesses (where if you want to read a 4-byte
>value, that value needs to be at a multiple of 4, etc.).
This is not necessarily a bug in the code. The alignment or padding of data
and instructions can be specified to some compilers in order to force
proper and efficient alignment in memory. So I believe this is a problem
created by the build process and not a problem with the source.
When I developed for Digital UNIX, I inadvertently produced code that
caused this behavior. My solution was not to change the code, which was
portable to numerous OSs, but to specify to the compiler that it should pad
data and instructions to 32bit boundaries, which is the smallest
addressable granularity on the Alpha memory bus. The alignment trap is the
kernel's exception handler that magically corrects for unaligned memory
accesses, and yells at whoever trips over them.
Which module is causing this behavior? What compiler was used? I presume
'gcc' was the compiler. Does it support padding?
It will be some time before my noname is up far enough for me to
investigate and build this sort of thing. It doesn't seem to be a
significant problem, although it can be scary to those who don't know what
it is. When I'm all the way up and running I'd like to tackle an issue like
Peter Mott | mailto:email@example.com | Voice: 508.647.7375
| http://www.mathworks.com | FAX: 508.647.7002
PGP fingerprint: AAB3 CC97 3045 15F1 A9CC ECA2 0207 FB0A 0997 8F31