Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: drow@false.org (Daniel Jacobowitz),  gdb-patches@sourceware.org
Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)
Date: Wed, 06 Dec 2006 21:21:00 -0000	[thread overview]
Message-ID: <m3lklkoh3n.fsf@codesourcery.com> (raw)
In-Reply-To: <200612061629.kB6GTROh021274@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Wed, 6 Dec 2006 17:29:27 +0100 (CET)")


That analysis of the current use of the r2v/v2r functions is really
helpful.  I feel very happy to have a thorough and detailed
explanation of what's going on.  Thank you, Ulrich.

It seems to me the hard case to deal with is the alpha STS/LDS
conversions.  If I understand properly, the alpha's issue here is as
follows:

- a 32-bit float stored in a floating-point register with LDS gets
  converted to a 64-bit floating-point value.  Extracting it with STS
  does the reverse, but in a way that preserves the exact bit pattern.
  So the LDS and STS instructions can be used to store 32-bit integers
  as well as 32-bit floats, although the integer's bits get
  re-interpreted as float fields and the value looks odd.  And this is
  the standard way to handle 32-bit integers stored in floating-point
  registers.

- a 64-bit structure can also be stored in a floating-point register,
  with no bit rearrangement.

So the alpha needs to distinguish three cases:

a) a 32-bit integer in a floating-point register, mangled as a float.

b) an integer of some size at some offset within the floating-point
  register, not mangled because it is part of a larger structure.

c) a 64-bit value stored in the register.

The alpha register_to_value function could represent a) as a value
with a bitpos of 64, indicating that special decoding is necessary.
It would represent b) and c) using normal bit positions and lengths.
Wouldn't this work?  Couldn't something similar be done for the 387?

I'm reluctant to get into storing original types and having reference
counts; it's a lot of complexity in the core code to handle
architectures that are doing odd things.

I've got unsubmitted patches for GDB that implement a new kind of
value, whose contents are read and written via functions provided by
the user, based on a generic closure pointer.  Future r2v / v2r
functions could produce values of this sort, instead of using odd
bitpos values.  So the kludge wouldn't last forever.


  parent reply	other threads:[~2006-12-06 21:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-11 18:38 Ulrich Weigand
2006-11-22 14:15 ` [PING] " Ulrich Weigand
2006-11-22 14:23 ` Daniel Jacobowitz
2006-11-22 19:25   ` Jim Blandy
2006-11-22 19:28     ` Daniel Jacobowitz
2006-11-22 19:55       ` Ulrich Weigand
2006-11-22 20:30         ` Daniel Jacobowitz
2006-11-22 20:43           ` Ulrich Weigand
2006-11-22 20:57             ` Daniel Jacobowitz
2006-11-22 22:13               ` Ulrich Weigand
2006-11-22 22:48                 ` Daniel Jacobowitz
2006-11-23 13:57                   ` Ulrich Weigand
2006-11-23 16:16                     ` Daniel Jacobowitz
2006-11-23 17:55                       ` Ulrich Weigand
2006-11-23 19:59                         ` Mark Kettenis
2006-11-24  2:08                           ` Daniel Jacobowitz
2006-11-24 15:51                             ` Ulrich Weigand
2006-11-28 14:56                               ` Daniel Jacobowitz
2006-11-27 19:31                         ` Jim Blandy
2006-11-27 22:06                           ` Ulrich Weigand
2006-11-27 22:31                             ` Jim Blandy
2006-11-27 23:23                               ` Ulrich Weigand
2006-11-27 23:59                                 ` Jim Blandy
2006-11-28  0:01                                 ` Daniel Jacobowitz
2006-12-06 16:29                                   ` Ulrich Weigand
2006-12-06 16:43                                     ` Daniel Jacobowitz
2006-12-06 17:10                                       ` Ulrich Weigand
2006-12-06 17:12                                         ` Daniel Jacobowitz
2006-12-07  6:34                                           ` Vladimir Prus
2006-12-06 21:21                                     ` Jim Blandy [this message]
2006-12-06 22:02                                       ` Daniel Jacobowitz
2006-12-06 23:24                                         ` Jim Blandy
2006-12-06 23:16                                       ` Ulrich Weigand
2006-12-06 23:39                                         ` Jim Blandy
2006-12-08 15:50                                           ` Ulrich Weigand

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=m3lklkoh3n.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.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