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.
Created attachment 352 [details] Patch against DMD 2.029 This simple patch comments out the problematic instructions.
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.
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.
(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.