After some debugging I've found the culprit behind my unaligned access
warnings. The problem lies in the file idom/IDDocumentImpl.cpp in the
implementation of the allocate function. The first issue is that the size
of a pointer is hard coded to be 4 bytes. This may not be directly
responsible for my problems but should be changed anyway. This is simple
enough to fix with:
*** IDDocumentImpl.cpp Wed Aug 1 15:19:13 2001
--- IDDocumentImpl.cpp.new Wed Aug 1 15:49:29 2001
***************
*** 884,890 ****
fFreePtr = 0;
fFreeBytesRemaining = 0;
}
! void *retPtr = (char *)newBlock + 4;
return retPtr;
}
--- 884,890 ----
fFreePtr = 0;
fFreeBytesRemaining = 0;
}
! void *retPtr = (char *)newBlock + sizeof(void *);
return retPtr;
}
The second issue is more general, and while I've found a work around, there
may be a better solution. The way this function is written it assumes that
the natural alignment of a char is adequate for all other types, which may
be true on 32-bit systems but not on 64-bit. For instance both longs and
pointers require 8 byte alignment whereas char uses 4 byte alignment. The
way I have worked around it is to check to make sure that a given address is
divisible by 8 before using that as the base for a allocation. This only
seems to be necessary when using an existing block. When creating a new
char array it seems that it starts on an 8 byte aligned address. This
change successfully eliminates all the unaligned access messages when
running the idom samples provided in the distribution.
*** IDDocumentImpl.cpp Wed Aug 1 15:19:13 2001
--- IDDocumentImpl.cpp.new Wed Aug 1 16:01:45 2001
***************
*** 910,915 ****
--- 910,920 ----
fFreeBytesRemaining = kHeapAllocSize - sizeof(void *);
}
+ #ifdef TRU64
+ int ptrOffset = ((unsigned long)fFreePtr)%sizeof(void *);
+ if ( ptrOffset != 0 )
+ fFreePtr = fFreePtr + sizeof(void *) - ptrOffset;
+ #endif
void *retPtr = fFreePtr;
fFreePtr += amount;
fFreeBytesRemaining -= amount;
Does someone have a better suggestion on how to handle this problem?
Thanks,
Kari Whitcomb
----- Original Message -----
From: "Martin Kalen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 12:26 AM
Subject: Re: Unaligned Access warnings in IDOM samples
> ----- Original Message -----
> From: "Tinny Ng" <[EMAIL PROTECTED]>
> Sent: Tuesday, July 31, 2001 5:28 AM
>
> > Ring some bells, but before going further, may be can you first explain
> to me
> > what does "-assume noaligned-objects" do? I am not familiar to TRU64
> Unix....
>
> It has to do with the Alpha 64bit architecture: correct aligned data (a
> "quadword" of 64bit) will be fetched directly from the MMU but misaligned
> data generates a fetch + mask + shift (eg. the CPU has to do some work as
> well).
>
> See
> http://csa.compaq.com/Dev_Tips/unalign.htm
> for some tips about why this happens and instructions on pinpointing what
> code that is generating the warnings.
>
> It's not neccessary any big downside of turning the warnings off with "uac
> p 0", but it's probably best to find out where in Xerces this is happening
> and see if it can easily be fixed. If it can, then other 64bit
> architectures such as HP-PA might also run faster.
>
> Regards,
> Martin.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
