FADD and FADDP instructions Q&A

[Intel_Software_Netw1]

Here isa Q&Asubmitted byour Application Engineers in response to an inquiry we received. We hope thisinformation ishelpful:

In the Borland BASM newsgroup we have a discussion regarding the existence of a parameter-less FADD. I claim that no such instruction exists. I also claim that assemblers are buggy when translating FADD into FADDP ST(1), ST(0) (DE C1).

In the latest instruction set reference manuals no such instruction is seen in the tables.

In the instruction set reference for the 486 from 1992 FADD = DE C1 is mentioned in the table. The description says "Add ST to ST(1) and pop ST".

I believe this is a typo because FADDP ST(1), ST(0) also has the opcode DE C1.

The latest instruction set reference says "DE C0+i FADDP ST(i), ST(0) Add ST(0) to ST(i), store result in ST(i), and pop the register stack".

The latest instruction set reference also says "DE C1 FADDP Add ST(0) to ST(1), store result in ST(1), and pop the register stack".

I understand this as it was a simple typo in the old manuals that the P was missing in FADD. This unfortunately led to the implementation of FADD = FADDP in the two assemblers I have tried, Intel C++ Compiler for Windows version 4.5 and Delphi 6 and 7.

In the 486 reference some inconsistency exist because FADD (noparam) and FMUL (noparam) are defined, but FSUB (noparam) and FDIV (noparam) are not defined. FADD & FMUL are said to pop the stack and so are FSUBP & FDIVP.

This is fixed in later manuals.

To me it is very clear that the P says pop and if it is not appended to the mnemonic no popping is done. But it seems that I am alone with that view.

I hope you can help me settle the discussion.

Our Intel Developer Services Application Engineers responded:

In the 2003 edition of the IA-32 Intel Architecture Software Developers Manual, Volume 2: Instruction Set Reference, the following sentences appear in the third paragrpah under the Description heading for the FADD instruction:

The no operand version of the floating point add instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FADD rather than FADDP.

Sentences that are virtually identical to this appear for FSUB, FMUL, and FDIV. What this means is that no matter how the no operand version of the instruction is implemented, be it FADD, or FADDP, it will pop the stack. This means that even though some assemblers choose to support the FADD mnemonic, it will always act like the FADDP instruction. You can expect similar behavior for FSUB, FMUL, and FDIV. Good luck!

==
Lexi S.

IntelSoftware NetworkSupport

http://www.intel.com/software

Contact us

Message Edited by intel.software.network.support on 12-07-2005 04:51 PM

[Intel_Software_Netw1]

Here is a followup to the Q&A above:

Yes, I have read this too, but it does not answer my questions. Why do some assemblers accept FADD (no parameters), if it is not a valid mnemonic?

It seems to me that there were some typos in the older reference manuals, which have been corrected around 1993. These typos misled some assembler implementers to accept FADD. By comparing the instruction set reference manual entries for FADD, FSUB, FSUBR, FMUL, FDIV & FDIVR in the older manuals, it is seen that inconsistencies are present. This leads me to the conclusion that the missing P in FADD was just a typo. Assemblers should never have accepted FADD (noparam). They still support FADD, because if this support was removed it would break old code.

I believe that the parameter-less FADD, FSUB, FSUBR, FMUL, FDIV & FDIVR should be rejected by assemblers. The solution in existence now, that we get a pop behind our backs when not asking for one, is no good. It is more logical to understand FADD as FADD st(0), st(1) than as FADDP (to me at least ;-)).

I need some deeper explanations to be able to settle the discussion.

Our Application Engineers responded:

The no operand form of the FADD (and the other mathematical functions) mnemonic will always pop the register stack. While this allows these instructions to have functionality that is not intuitive (from the mnemonic itself), it does not make the mnemonic invalid. The manual clearly allows this form of the mnemonic, and therefore, it cannot be invalid. The functionality is certainly non-intuitive in this case. It is possible that this functionality is the result of the requirement for legacy support. It may be that in the early years, the no operand form of the FADD instruction popped the register stack, and programs were written using this functionality. It is certainly true that many programs have been written over the years which rely on this mnemonic. If all assemblers were to change to a more intuitive form of the mnemonic (FADDP with no operands), then all those legacy programs would fail. This is counter to the guarantee that legacy code will assemble and run seamlessly. We do not know why this form of the mnemonic originally appeared, but we have to support it and any legacy programs which use it. The short answer is, therefore, that some assemblers accept the no operand form of the FADD mnemonic because someone else did in the early years and they wish to maintain compatibility with those earlier assemblers. Exactly which assemblers that was and when that originally happened is not known.

==
Lexi S.

IntelSoftware NetworkSupport

http://www.intel.com/software

Contact us

Message Edited by intel.software.network.support on 12-07-2005 04:54 PM