digitalmars.D.bugs - [Issue 2942] New: asm fadd; accepted, but generates code for faddp.
- d-bugmail puremagic.com (37/37) May 05 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2942
- d-bugmail puremagic.com (7/7) May 06 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2942
- d-bugmail puremagic.com (12/12) May 08 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2942
- d-bugmail puremagic.com (12/12) Sep 30 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2942
- d-bugmail puremagic.com (20/23) Oct 01 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2942
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=2942 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALIDThese 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