[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Do I understand the storage formats?
- To: XTL list <firstname.lastname@example.org>
- Subject: Do I understand the storage formats?
- From: Angus Leeming <email@example.com>
- Date: Thu, 20 Apr 2000 15:50:29 +0100
- Delivered-To: mailing list firstname.lastname@example.org
- Mailing-List: contact email@example.com; run by ezmlm
This is a long and largely useless email. It's an attempt by me to understand
exactly how the different storage formats are meant to work so that I can cure
the problems with "unaligned access errors" on the Alpha. If, however, I've
got this wrong would somebody please put me straight!
All info is stored in xtl as one long character string.
An unaligned access error occurs if "type data" spans a word boundary but does
not begin at the start of the word, for some type (char, int, double etc). On 32
bit machines a word is 4 bytes long. On 64 bit machines such as the Alpha, a
word is 8 bytes long.
char a1, a2, a3, a4, a5, a6, a7, a8, a9, a10;
is Ok, because no variable crosses a word boundary. Similarly,
double a1, a2, a3, a4, a5, a6, a7, a8, a9, a10;
is also Ok, but attempting to store
double a2, a3, a4, a5, a6, a7, a8, a9, a10;
will result in unaligned access errors for each double if no effort is made to
pad the storage (this is what happens in raw_format).
This problem can be addressed in two different ways, as instatiated in xdr.h
XDR_format overcomes the problem by storing each variable in a space of size
WORDLENGTH (4 bytes on an Intel, 8 bytes on an Alpha).
Since the storage of all variables begins on a word boundary, no unaligned
access errors can occur. Bingo! However, the format is clearly very inefficient
at storing chars since each char is stored with (WORDLENGTH-1) bytes of padding.
GIOP_format is much more subtle. Padding is introduced only if storage will
cross a word boundary. Thus, storing:
char a1, a2, a3, a4, a5;
double a6, a7, a8, a9, a10;
on an Alpha machine will require 3 bytes of padding between a5 and a6.
Thereafter, no more padding is needed.
Clearly, this is the optimal storage format and is, therefore, the way that LyX
I think this is what the code in GIOP_format::req_align() is tyying to do,
but my brain is slowing down (long day). Am I correct?