This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA fix conversion of little-byte big-word floats to doublest


On Sat, 04 Dec 2004 16:56:44 GMT, Richard Earnshaw wrote:
> On Sat, 04 Dec 2004 11:00:54 EST, Daniel Jacobowitz <drow@false.org>  
> wrote:
> > On Sat, Dec 04, 2004 at 03:46:24PM +0000, Richard Earnshaw wrote:
> > > On Sat, 04 Dec 2004 10:44:30 EST, Daniel Jacobowitz <drow@false.org>  
> > > wrote:
> > > > Could you summarize for me how this is supposed to work?  This means
> > > > that get_field treats littlebyte_bigword exactly the same as little.
> > > > There's another copy of get_field in libiberty (I don't know why there
> > > > are two) which treats it exactly the same as big, instead.  I don't
> > > > know how that works either, but it seems the two ought to agree.
> > > 
> > > The caller has pre-converted the word order into a pure little-endian 
> > > format.  See convert_format_to_doublest.
> > > 
> > > Similar tricks are played on the reverse conversion.
> > 
> > Huh; it looks like the copy in libiberty is just broken for this case.
> > 
> > Is the code which does the swapping correct for the 96-bit format?
> > It converts ABCD EFGH IJKL to EFGH ABCD IJKL; I would have guessed that
> > pure little-endian representation would have been IJKL EFGH ABCD.
> 
> I suspect it's completely broken.
> 
> > The swap-back code only swaps the first two words also.
> > 
> 
> It wouldn't surprise me in the least.
> 
> > Meanwhile, patch is OK; I'd appreciate it if you could add a comment in
> > get_field/put_field somewhere explaining what's going on.
> 
> Will do.

I've just been thinking.

The current code (for both conversions to and from doublest) tries to work 
by normalizing the word order to match the byte order.  This clearly makes 
things quite difficult when the number of words involved is variable.

I think it would be a more tractable problem to change all this around so 
that the byte order is normalized to match the word order.  This can be 
done by simply repeating a word-normalization step for each word in the 
value.

Thoughts?

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]