Re: [Evolution-win32-devel] ORBit2 status: Workaround for hang, but new alignment problems
- From: Tor Lillqvist <tml novell com>
- To: michael meeks novell com
- Cc: orbit <orbit-list gnome org>, evolution-win32-devel lists sourceforge net
- Subject: Re: [Evolution-win32-devel] ORBit2 status: Workaround for hang, but new alignment problems
- Date: Wed, 9 Feb 2005 00:13:12 +0000
michael meeks writes:
> + offset: should use 'ALIGN_VALUE' not ALIGN_ADDRESS.
OK.
> + get rid of the pointer kniptions :-)
> offset = ALIGN_VALUE (offset, tc...);
> *val = val0 + offset;
OK.
> + struct:
> + the separate offset += ORBit_gather_alloc_info:
> + rather slow; I liked the pre-align there
> + perhaps add a 'ulong &size' argument
> to marshal_value in due course (?)
I first tried to use tc->c_length instead of calling
ORBit_gather_alloc_info(), but apparently that is not set up for all
typecodes? Hmm, grepping for c_length in orb-core finds nothing?
> + not convinced by tk_union
> + we remove a pre-align, but I don't see an equivalent
> post-align:
True, have to add that. Unions behave like structs in this regard,
don't they? Will add a test case for that, too, to everything.idl and
associated test code.
> + in _marshal_value it seems to make little sense to
> do the GIOP & native alignment at different ends :-)
> can we bin all pre-aligns in favour of post ?
Maybe, but I didn't want to touch stuff that wasn't necessary to get
it working.
BTW, dropping the pre-aligns means that passing an unaligned pointer
to an int, for instance, on platforms that require alignment now
causes a crash, doesn't it? But OTOH, unaligned pointers wouldn't
happen except if done on purpose, or because of bugs in calling
software? So a crash is what such code is asking for then? (IMHO
garbage-in->garbage-out is no better than garbage-in->crash?)
> Finally, in the tests; I have a suspicion that on Linux & Win32 we are
> prolly loosing some useful alignment assistance by not having:
>
> volatile guchar dummy = <value>;
>
> members between structures on the stack (the volatile may/should force
> the optimiser to think twice about whacking them in registers / removing
> them altogether).
Hmm, could you elaborate more on this? Add volatile chars where?
--tml
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]