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


Walter Bright <bugzi...@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzi...@digitalmars.com
         Resolution|                            |WONTFIX


--- Comment #1 from Walter Bright <bugzi...@digitalmars.com> 2010-04-28 
09:18:18 PDT ---
The trouble with the idea of, say:

   a = b + 2;
   c = carry();

where carry() is a compiler intrinsic that reads the CPU carry flag, is that
there's nothing that says the previous statement even sets the carry flag in
any consistent manner. For example:

   a = b + 1;

may be implemented with an INC instruction, which does not set the carry flag
on overflow. Many optimizations may transform the code to not set the carry
flag, or to have the carry flag set by some other operation.

While this idea looks portable, it would be completely non-portable in
practice. Even its behavior with one compiler can arbitrarily depend on the
code mix surrounding it, and be highly sensitive to any changes in it in ways
that would be impractical for the user to track.

In its proposed form, the idea is not workable.

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

Reply via email to