Another inline assembly question

Discussion in 'C++' started by Johannes Bauer, Apr 6, 2005.

  1. Hi group,

    inspired by the other inline assembly thread a question popped up in my
    mind... Victor Bazarov mentioned in his response that the asm() clause
    was covered by the C++ standard, subclause 7.3.. Well, I couldn't find
    the C++ standard definition on the net, so I'm asking here:

    Why is a thing like assembly covered by the standard at all? According
    to Victor's response, it seems to be totally compiler dependent what's
    done with the char* I pass on to asm(). If that were true, usage of
    asm() would always yield undefined results (according to the standard).
    Doesn't that totally defy the purpose of a standard in the first place?

    And isn't usage of a highly object-oriented language mixed with
    _assembly_, a language not only dependant on the running OS (like
    implementation of system/library calls), but also to the very most
    extent dependant on the hardware a little bit odd?

    Well, just wondered... hope somebody can clear that up.
    Greetings,
    Johannes

    --
    PLEASE verify my signature. Some forging troll is claiming to be me.
    My GPG key id is 0xCC727E2E (dated 2004-11-03). You can get it from
    wwwkeys.pgp.net or random.sks.keyserver.penguin.de.
    Also: Messages from "Comcast Online" are ALWAYS forged.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFCUz2GCseFG8xyfi4RAuiQAJsG0juW41Uru5F/KNgPax88SEb65wCfYFqK
    Ty9+dh5y17fNfCVpi/32bbc=
    =NQhT
    -----END PGP SIGNATURE-----
     
    Johannes Bauer, Apr 6, 2005
    #1
    1. Advertising

  2. Johannes Bauer

    Artie Gold Guest

    Johannes Bauer wrote:
    > Hi group,
    >
    > inspired by the other inline assembly thread a question popped up in my
    > mind... Victor Bazarov mentioned in his response that the asm() clause
    > was covered by the C++ standard, subclause 7.3.. Well, I couldn't find
    > the C++ standard definition on the net, so I'm asking here:
    >
    > Why is a thing like assembly covered by the standard at all? According
    > to Victor's response, it seems to be totally compiler dependent what's
    > done with the char* I pass on to asm(). If that were true, usage of
    > asm() would always yield undefined results (according to the standard).
    > Doesn't that totally defy the purpose of a standard in the first place?


    No, it produces *implementation defined* results, just as is the case
    with, for example, system(). [Implementation defined != undefined]
    >
    > And isn't usage of a highly object-oriented language mixed with
    > _assembly_, a language not only dependant on the running OS (like
    > implementation of system/library calls), but also to the very most
    > extent dependant on the hardware a little bit odd?
    >

    See above.

    HTH and Cheers,
    --ag


    --
    Artie Gold -- Austin, Texas
    http://it-matters.blogspot.com (new post 12/5)
    http://www.cafepress.com/goldsays
     
    Artie Gold, Apr 6, 2005
    #2
    1. Advertising

  3. Johannes Bauer wrote:

    > Hi group,
    >
    > inspired by the other inline assembly thread a question popped up in my
    > mind... Victor Bazarov mentioned in his response that the asm() clause
    > was covered by the C++ standard, subclause 7.3.. Well, I couldn't find
    > the C++ standard definition on the net, so I'm asking here:
    >
    > Why is a thing like assembly covered by the standard at all? According
    > to Victor's response, it seems to be totally compiler dependent what's
    > done with the char* I pass on to asm(). If that were true, usage of
    > asm() would always yield undefined results (according to the standard).



    Implementation-defined.


    > Doesn't that totally defy the purpose of a standard in the first place?
    >
    > And isn't usage of a highly object-oriented language mixed with
    > _assembly_, a language not only dependant on the running OS (like
    > implementation of system/library calls), but also to the very most
    > extent dependant on the hardware a little bit odd?


    With C++ you can do both portable and system-specific programming.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Apr 6, 2005
    #3
  4. Artie Gold wrote:

    >> Why is a thing like assembly covered by the standard at all? According
    >> to Victor's response, it seems to be totally compiler dependent what's
    >> done with the char* I pass on to asm(). If that were true, usage of
    >> asm() would always yield undefined results (according to the standard).
    >> Doesn't that totally defy the purpose of a standard in the first place?

    >
    > No, it produces *implementation defined* results, just as is the case
    > with, for example, system(). [Implementation defined != undefined]


    Well, but isn't the sole purpose of a _standard_ that I can compile my
    programs with whichever compiler fulfills the standard's requirements
    and it always behaves the same? An "implementation defined" result would
    mean there could be compilers out there translating asm() into something
    comepletely weird, maybe some compilers ignore it completely. And they
    would all fulfill the standard's requirements, as the standard states
    it's up to the implementation to decide what to do.

    This seems awkward... are there more "implementation defined" places in
    the C++ standard?

    Greetings,
    Johannes

    --
    PLEASE verify my signature. Some forging troll is claiming to be me.
    My GPG key id is 0xCC727E2E (dated 2004-11-03). You can get it from
    wwwkeys.pgp.net or random.sks.keyserver.penguin.de.
    Also: Messages from "Comcast Online" are ALWAYS forged.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFCU8ryCseFG8xyfi4RAgClAJ9Q3n6CS+F+RponoG9QJ3U79gwA3gCgocPV
    i+uT6p9KvTdDDxy9Zi909qA=
    =PYNO
    -----END PGP SIGNATURE-----
     
    Johannes Bauer, Apr 6, 2005
    #4
  5. Johannes Bauer wrote:
    >
    > Artie Gold wrote:
    >
    > >> Why is a thing like assembly covered by the standard at all? According
    > >> to Victor's response, it seems to be totally compiler dependent what's
    > >> done with the char* I pass on to asm(). If that were true, usage of
    > >> asm() would always yield undefined results (according to the standard).
    > >> Doesn't that totally defy the purpose of a standard in the first place?

    > >
    > > No, it produces *implementation defined* results, just as is the case
    > > with, for example, system(). [Implementation defined != undefined]

    >
    > Well, but isn't the sole purpose of a _standard_ that I can compile my
    > programs with whichever compiler fulfills the standard's requirements
    > and it always behaves the same? An "implementation defined" result would
    > mean there could be compilers out there translating asm() into something
    > comepletely weird, maybe some compilers ignore it completely.


    Yes exacxtly.
    The problem for those writing the standard is as follows. There are
    always regions where the committee cannot rule down what has to be done,
    since those things are dependent on external influences. Take the system()
    command for example. The standard committee thought it to be neccessary
    to have some way to communicate with the operating systems command processor
    (if there is one). But the exact way how this should be done, which string
    to pass to create a specific reaction is outside their scope, mostly because
    it is not the C++ committee who defines what those command line syntax looks
    like. Or the exact format of file names or directory specifications in file
    names, or ...

    > And they
    > would all fulfill the standard's requirements, as the standard states
    > it's up to the implementation to decide what to do.
    >
    > This seems awkward... are there more "implementation defined" places in
    > the C++ standard?


    Sure.
    Whenever the standard needs to 'look across the borders of the language'
    and has to accept that it cannot control the behaviour of the underlying
    hardware and/or operating system.

    C++ defines a language in contrast to eg. Java. Java defines the whole
    platform, thus it has much better control over that platform. How that
    virtual platform is implemented in real hardware or in a real operating
    system is not the problem of Java per se.

    --
    Karl Heinz Buchegger
     
    Karl Heinz Buchegger, Apr 6, 2005
    #5
  6. Johannes Bauer

    Pete Becker Guest

    Johannes Bauer wrote:

    >
    > Well, but isn't the sole purpose of a _standard_ that I can compile my
    > programs with whichever compiler fulfills the standard's requirements
    > and it always behaves the same?


    No. The purpose is to give you a good shot at writing code that's
    reasonably portable, which means knowing which parts can move to a
    different system without change and which ones may need to be rewritten.
    If you like the myth of "write once, run anywhere," use Java and learn
    to love the undocumented changes in behavior.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 6, 2005
    #6
  7. Johannes Bauer

    Walter Guest

    "Pete Becker" <> wrote in message
    news:...
    > If you like the myth of "write once, run anywhere," use Java and learn
    > to love the undocumented changes in behavior.


    Certainly Java has no inline assember <g>, and Java has not 100% achieved
    the goal of write once, run anywhere. However, Java has made a major effort
    to remove things like implementation defined and undefined behavior from the
    language, and as a result it is intrinsically much more portable than C++.

    For example, Java has a defined order of evaluation of the components of an
    expression. Therefore, if those components have side effects, the expression
    will behave the same on different platforms. C++ does not, it's
    implementation defined, and the expression may behave differently, even
    using the same compiler (just by changing optimization switches).

    The reason for this flexibility in C++ is to allow more opportunities for
    optimizing an expression. But I've written an advanced optimizer for both
    C++ and Java compilers, and switching the "reorder the expression even if it
    has side effects" has no discernible advantage for real code.

    C++ would benefit from a pass through the spec and revisit each
    implementation defined and undefined behavior, to see if they are still
    justifiable given today's compiler technology rather than yesteryear's.
    Fixing the spec won't break existing code if that code is written to avoid
    relying on undefined and implementation defined code anyway <g>.

    And can't C++ just say that shorts are 16 bits? Does anyone care about
    programming the PDP-10 in C++? (I personally have a big soft spot for
    the -10, but let's face it, it's been obsolete for 20 years.) Anyone have 18
    bit shorts on the CPU drawing table? I'd be shocked if there was.

    -Walter
    www.digitalmars.com free C, C++, D compilers
     
    Walter, Apr 6, 2005
    #7
  8. Walter wrote:
    > "Pete Becker" <> wrote in message
    > news:...
    >
    >>If you like the myth of "write once, run anywhere," use Java and learn
    >>to love the undocumented changes in behavior.

    >
    >
    > Certainly Java has no [...] Java has not 100% achieved
    > [..] Java [...] much more portable than C++.
    >
    > For example, [...]
    >


    Java is a platform. C++ is a language. Can we move on now?
     
    Victor Bazarov, Apr 6, 2005
    #8
  9. Walter wrote:

    > And can't C++ just say that shorts are 16 bits? Does anyone care about
    > programming the PDP-10 in C++? (I personally have a big soft spot for
    > the -10, but let's face it, it's been obsolete for 20 years.) Anyone have 18
    > bit shorts on the CPU drawing table? I'd be shocked if there was.



    When people mention "Java" they are actually talking about two things. The Java language
    (syntax) and the Java framework (JVM). The last is open only to the Java language. So when
    you are programming form the JVM you are targeting only one platform, the JVM. That's why
    everything has fixed size.


    If JVM was available to other languages like C++, then C++ programmers would also target
    one platform when targeting the JVM, and thus would also have the same fixed size and
    other JVM facilities (like garbage collection etc).


    This is what is happening with other virtual machine frameworks, like .NET (a CLI
    compliant VM). My .NET applications are always targeting the framework and thus always
    have fixed sizes (int and long are always 32-bit, short is always 16) in 64-bit .NET
    frameworks too. They also have the garbage collection and other facilities of the framework.


    So in few words, C++ takes advantage of all facilities a system provides. If you target a
    virtual machine you get the type sizes and other facilities of the virtual machine, if you
    target a native machine you get the sizes of the native machine.


    I hope this makes things clear.




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Apr 6, 2005
    #9
  10. Ioannis Vranos wrote:


    > If JVM was available to other languages like C++,


    The JVM *is* available to other languages like C++.
     
    E. Robert Tisdale, Apr 6, 2005
    #10
  11. E. Robert Tisdale wrote:

    > The JVM *is* available to other languages like C++.



    May be I have missed that. May you provide more information on this? Is there a JVM C++
    compiler?



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Apr 6, 2005
    #11
  12. Johannes Bauer

    Walter Guest

    "Ioannis Vranos" <> wrote in message
    news:1112809414.369683@athnrd02...
    > Walter wrote:
    > > And can't C++ just say that shorts are 16 bits? Does anyone care about
    > > programming the PDP-10 in C++? (I personally have a big soft spot for
    > > the -10, but let's face it, it's been obsolete for 20 years.) Anyone

    have 18
    > > bit shorts on the CPU drawing table? I'd be shocked if there was.

    > When people mention "Java" they are actually talking about two things. The

    Java language
    > (syntax) and the Java framework (JVM).


    I'm talking about Java the language, of course, including its semantics as
    well as syntax.

    > So in few words, C++ takes advantage of all facilities a system provides.

    If you target a
    > virtual machine you get the type sizes and other facilities of the virtual

    machine, if you
    > target a native machine you get the sizes of the native machine.


    Are there any current or projected CPUs that have don't have 16 bit shorts?
    Are there any current C++ compilers where shorts aren't 16 bits? Where chars
    aren't 8 bits? Anyone have plans for one?

    (BTW, Java targetting a VM rather than a native CPU is not what makes it
    portable. What makes it portable is having more thoroughly defined semantics
    of the language than C++ has. Java the language can, and has been,
    implemented without a VM.)
     
    Walter, Apr 6, 2005
    #12
  13. Walter wrote:

    > Are there any current or projected CPUs that have don't have 16 bit shorts?



    There can be.



    > Are there any current C++ compilers where shorts aren't 16 bits?



    There can be.


    > Where chars
    > aren't 8 bits? Anyone have plans for one?



    Yes there are systems with 16-bit chars/bytes.


    > (BTW, Java targetting a VM rather than a native CPU is not what makes it
    > portable.



    Binary portability exists because of the JVM. Also all C++ programs compiled with
    /clr:safe are *binary* portable to all CLI VMs like Mono, when the common APIs are used.


    > What makes it portable is having more thoroughly defined semantics
    > of the language than C++ has. Java the language can, and has been,
    > implemented without a VM.)



    Source portability has not anything to do with fixed sizes. You cam make perfectly source
    portable code in C++.


    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Apr 7, 2005
    #13
  14. Ioannis Vranos wrote:
    >
    > Walter wrote:
    >
    >> Are there any current or projected CPUs that have don't have 16 bit
    >> shorts?

    >
    >
    >
    > There can be.
    >
    >
    >
    >> Are there any current C++ compilers where shorts aren't 16 bits?

    >
    >
    >
    > There can be.
    >
    >
    >> Where chars
    >> aren't 8 bits? Anyone have plans for one?

    >
    >
    >
    > Yes there are systems with 16-bit chars/bytes.
    >
    >
    >> (BTW, Java targetting a VM rather than a native CPU is not what makes it
    >> portable.

    >
    >
    >
    > Binary portability exists because of the JVM. Also all C++ programs
    > compiled with /clr:safe are *binary* portable to all CLI VMs like Mono,
    > when the common APIs are used.
    >
    >
    >> What makes it portable is having more thoroughly defined semantics
    >> of the language than C++ has. Java the language can, and has been,
    >> implemented without a VM.)

    >
    >
    >
    > Source portability has not anything to do with fixed sizes. You cam make
    > perfectly source portable code in C++.



    There can be = May exist


    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Apr 7, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    1,839
  2. \A_Michigan_User\

    Assembly included inside another assembly ???

    \A_Michigan_User\, Apr 18, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    398
    Spam Catcher
    Apr 18, 2006
  3. Abhi
    Replies:
    2
    Views:
    757
    E. Robert Tisdale
    Jul 3, 2003
  4. Alvin
    Replies:
    7
    Views:
    495
    E. Robert Tisdale
    May 6, 2005
  5. Replies:
    3
    Views:
    479
Loading...

Share This Page