http://d.puremagic.com/issues/show_bug.cgi?id=2942

           Summary: asm fadd; accepted, but generates code for faddp.
           Product: D
           Version: 1.00
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid, wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: clugdbug@yahoo.com.au


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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2942





------- Comment #1 from clugdbug@yahoo.com.au  2009-05-06 03:55 -------
Created an attachment (id=352)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=352&action=view)
Patch against DMD 2.029

This simple patch comments out the problematic instructions.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2942





------- Comment #2 from clugdbug@yahoo.com.au  2009-05-08 14:48 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2942


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor


--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2009-09-30 23:03:03 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2942


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #4 from Don <clugdbug@yahoo.com.au> 2009-10-01 00:27:56 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------