From: Richard Earnshaw <Richard.Earnshaw@buzzard.freeserve.co.uk>
To: Richard Earnshaw <Richard.Earnshaw@buzzard.freeserve.co.uk>,
gdb-patches@sources.redhat.com
Subject: Re: RFA fix conversion of little-byte big-word floats to doublest
Date: Sat, 04 Dec 2004 17:33:00 -0000 [thread overview]
Message-ID: <200412041725.iB4HPLUo003928@merlin.buzzard.freeserve.co.uk> (raw)
In-Reply-To: <200412041656.iB4Gui7G015398@merlin.buzzard.freeserve.co.uk>
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.
next prev parent reply other threads:[~2004-12-04 17:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 15:27 Richard Earnshaw
2004-12-04 15:47 ` Daniel Jacobowitz
2004-12-04 16:01 ` Richard Earnshaw
2004-12-04 16:57 ` Daniel Jacobowitz
2004-12-04 17:23 ` Richard Earnshaw
2004-12-04 17:33 ` Richard Earnshaw [this message]
2004-12-04 19:39 ` Daniel Jacobowitz
2004-12-05 1:51 ` Richard Earnshaw
2004-12-05 15:54 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200412041725.iB4HPLUo003928@merlin.buzzard.freeserve.co.uk \
--to=richard.earnshaw@buzzard.freeserve.co.uk \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox