www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2942] New: asm fadd; accepted, but generates code for faddp.

reply d-bugmail puremagic.com writes:
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.


--
May 05 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2942






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.


--
May 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2942






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.


--
May 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2942


Walter Bright <bugzilla digitalmars.com> changed:

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



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: -------
Sep 30 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2942


Don <clugdbug yahoo.com.au> changed:

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





 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: -------
Oct 01 2009