www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9738] New: inline asm offset expression looks like array indexing

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9738

           Summary: inline asm offset expression looks like array indexing
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: code dawg.eu


--- Comment #0 from Martin Nowak <code dawg.eu> 2013-03-16 12:11:46 PDT ---
void foo()
{
    size_t[3] regs = void;

    asm
    {
        mov regs[1], RAX;
    }
}

regs[1] is interpreted as add the offset of regs to 1,
i.e. *cast(size_t)((cast(void*)&regs + 1).

This can already be expressed by one of the following two alternatives.
1[regs] or [regs + 1]

I think we should make this syntax an error, it's too easy to confuse with
array indexing. In the longterm we might consider to interpret this as array
indexing.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 16 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9738


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |WONTFIX
           Severity|normal                      |enhancement


--- Comment #1 from Walter Bright <bugzilla digitalmars.com> 2013-03-16
12:29:11 PDT ---
The inline assembler uses Intel syntax, and for better or worse, that's what it
is.

We need to either stick with it, as it is fairly well understood by asm
programmers, or use D syntax. Some hybrid in between will be liked by nobody.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 16 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9738


David Nadlinger <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |code klickverbot.at
         Resolution|WONTFIX                     |


--- Comment #2 from David Nadlinger <code klickverbot.at> 2013-03-16 17:24:36
PDT ---
Can't we just disallow it, and force people to use 1[regs] or [regs + 1] if
they really want the byte offset behavior?

The issue is not that Martin and I are not familiar with Intel syntax. It is
that the expression is both a valid D expression and AsmBrExp, and without
reading the grammar, there is no way of knowing what this will turn out to be.

Don't forget that nobody will be able to afford writing it things like regs[1]
anyway, because others reading the code could mistake it for the obvious
alternative – the meaning that the expression has everywhere else except for
asm blocks.

D has generally fared well with preventing unexpected behavior by outright
disallowing potentially ambiguous constructs (the "if it looks like C, it
behaves like C" rule, shadowing, …). I don't see why this approach should not
apply here.

(feel free to re-close as WONTFIX if you still don't think this merits further
discussion)

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