Discovered in LDC/DMD consistency comparisons.
asm {
fadd;
fmul;
fsub;
fdiv;
fsubr;
fdivr;
}
is accepted, but I don't think it should be. The AMD and Intel manuals don't mention it, they only have
asm {
faddp;
fmulp;
fsubp;
fdivp;
fsubrp;
fdivrp;
}
DMD's behaviour _is_ what DOS "debug" does, but it's error prone and confusing -- why isn't fadd; the same as fadd ST, ST(1); How the heck did it become faddp ST(1), ST;???
The bare forms without 'p' and with no arguments should simply be made illegal.
Comment #1 by clugdbug — 2009-05-06T03:55:03Z
Created attachment 352
Patch against DMD 2.029
This simple patch comments out the problematic instructions.
Comment #2 by clugdbug — 2009-05-08T14:48:47Z
It gets worse. DMD also copies some hideous DEBUG bugs. This garbage compiles:
void main() {
double x;
asm {
fld x, ST(6);
}
}
Even though there's no such instruction, you can't load into ST(6).
This wasn't included in my patch.
Comment #3 by bugzilla — 2009-09-30T23:03:03Z
These pseudo-ops *are* documented in older Intel manuals, like the 387 DX User's Manual. I'm reluctant to change it. The last issue should be in a separate report.
Comment #4 by clugdbug — 2009-10-01T00:27:56Z
(In reply to comment #3)
> These pseudo-ops *are* documented in older Intel manuals, like the 387 DX
> User's Manual. I'm reluctant to change it. The last issue should be in a
> separate report.
Interesting. They aren't present in any manual which is still available. I found a website with material which was copied from the 386 manual (not 387), but it said that even in 1997, the manual was no longer officially available.
I suspect that a lot of those pseudo-ops were bugs in DEBUG. (DEBUG also accepts fld addr, ST(6);).
However, I just checked MSVC, and it _does_ accept fadd;
(But it doesn't accept the legal faddp; !!)
Pretty useless, and I think they should be abandoned, but no big deal if you want to keep them.