Mail Archives: djgpp-workers/1999/06/23/12:31:28
Eli Zaretskii wrote:
> On Tue, 22 Jun 1999, Eric Rudd wrote:
>
> > There's not a one-to-one correspondence here, because of
> > assembler and Intel doc bugs!)
>
> IMHO, somebody should at least tell this to the GNU Binutils
> maintainers. From your description I understand that we cannot even
> be sure that Binutils 2.9.1 solves this problem.
The depressing reality is that the problem can't really be solved. If gas
is left as it is, it will continue to confuse assembler programmers, as it
did me. If gas is changed to "fix" the problem, it will break existing
code that has been written to work with the quirky gas. In particular,
gcc itself emits such code. I know that the gas authors are aware of this
anomaly, since in the gas source code there is an #ifdef BUSTED_OP_CODES,
or something like that, to enable alternative interpretations of them.
The whole business would bother me less if gas had a manual defining the
quirky mnemonics and their actions. However, I know of no such manual, so
we have to go back to the Intel docs, which are buggy in various ways.
Thus, there is really *no* documentation of what those mnemonics do. I'd
submit a bug report, but I honestly don't know what I should suggest that
they do.
> I don't think your versions of math functions add any mess at all. In
> fact, I think you shouldn't need to edit stubs.h at all, unless some
> of the ANSI/Posix functions that you wrote call non-ANSI/non-Posix
> functions. Since your code usually doesn't CALL anything, there
> should be no need for you to bother about the stubs.
I'm not aware of any external calls from my functions; AFAIK, the only
internal calls are in pow.s, and those labels are not global. In light of
your discussion, I don't think we need to add any stubs. However, I still
need to know what to do about exp2 and pow2. Currently these are multiple
global labels within pow2.s, so that the same code can be called by either
name. A corresponding situation exists with exp10 and pow10. One
alternative solution is to use a macro in math.h. I haven't thought
through the problems the various schemes would cause.
> Did the explanation above make any sense?
Yes, but see above.
> But you don't have to bother about this, since I already made the
> necessary changes in math.h and libm/math.h; I will check the new
> versions into the CVS
> when I check in the modified sources.
I am relieved not to have to worry about things like that.
> My concern was the same as in the case of hypot: if the result
> overflows a double (but not a long double), it seemed to me that the
> code would not set errno. Perhaps I missed something.
I checked ldexp(1., 2000), and it returned +inf with ERANGE, just as I
expected.
> Please upload them.
I will, as soon as I hear from you what I should do about that exp2 and
pow2 stuff, and have a chance to fix the routines appropriately.
> Is the docs I sent to you correct in describing the behavior of the
> new version (except for the comment about the rounding mode which I
> understand I can remove)?
I have found a few errors relating to error returns, which I will amend,
but most of the descriptions appeared correct. I will submit some
suggested alternative wording to the description of atan2, which you can
incorporate or ignore, at your option. I will zip up the corrected docs
along with the new source.
> And thanks for the hard work.
You're welcome. I'm looking forward to the release.
-Eric Rudd
- Raw text -