From: Andrew Cagney <ac131313@cygnus.com>
To: Andreas Schwab <schwab@suse.de>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Long double support on m68k
Date: Tue, 24 Jul 2001 15:12:00 -0000 [thread overview]
Message-ID: <3B5DF2C3.6030609@cygnus.com> (raw)
In-Reply-To: <jehew2s3t1.fsf@sykes.suse.de>
> Andrew Cagney <ac131313@cygnus.com> writes:
>
> |> > This patch enables long double support for m68k.
> |> > Andreas.
> |> > 2001-07-23 Andreas Schwab <schwab@suse.de>
> |> > * config/m68k/tm-m68k.h (TARGET_LONG_DOUBLE_FORMAT): Define.
> |> > (TARGET_LONG_DOUBLE_BIT): Define.
> |> > (REGISTER_VIRTUAL_SIZE): Return 12 for floating point registers.
> |> > (MAX_REGISTER_VIRTUAL_SIZE): Increase to 12.
> |> > (REGISTER_VIRTUAL_TYPE): Return builtin_type_long_double for
> |> > floating point registers.
> |> > (REGISTER_CONVERTIBLE, REGISTER_CONVERT_TO_VIRTUAL,
> |> > REGISTER_CONVERT_TO_RAW): Remove.
> |> > * config/m68k/xm-linux.h (HOST_LONG_DOUBLE_FORMAT): Define.
> |> |> |> The patch changes something included by all the other config/m68k/tm-*.h
> |> header files. Can you explain why it won't break some of those targets.
>
> Well, that's how the m68k looks like on all targets (if they support
> floating point at all). All targets that make use of the fpu do it
> similar as m68k-linux and don't touch any of the macros I changed, so I
> think this should be safe. The patch only changes the representation of
> floating point values at gdb's point of view, not how the target is using
> it.
So, what you're saying is that:
o
only tm-m68k defines the current
REGISTER_CONVERT* macros. All
m68k targets import/use this.
o
the existing REGISTER_CONVERT* macro's
only work when the raw register buffer
is laid out using a specific format.
o
A target's FP only works when
the target has a raw register buffer
that correctly matches REGISTER_CONVERT*
o
If a target has somehow managed to get
a raw register buffer that doesn't match
REGISTER_CONVERT* then, even
before this change, it is broken.
So, if a target's raw FP registers are in the correct format for
REGISTER_CONVERT* then they are also in the correct format for this
change and such targets will continue to work. If a target's raw FP
registers were not in the correct format then, that target is already
broken and this change doesn't make things better or worse.
Correct?
Andrew
next prev parent reply other threads:[~2001-07-24 15:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-24 7:30 Andreas Schwab
2001-07-24 8:58 ` Andrew Cagney
2001-07-24 9:13 ` Andreas Schwab
2001-07-24 15:12 ` Andrew Cagney [this message]
2001-07-25 1:17 ` Andreas Schwab
2001-07-25 8:42 ` Andrew Cagney
2001-07-25 9:05 ` Andreas Schwab
2001-07-25 15:47 ` Andrew Cagney
2001-07-26 1:43 ` Andreas Schwab
2001-07-26 6:36 ` Andrew Cagney
2001-07-28 13:03 ` Andrew Cagney
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=3B5DF2C3.6030609@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=schwab@suse.de \
/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