«

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 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

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

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+RponoG9QJ3 U79gwA3gCgocPV
i+uT6p9KvTdDDxy9Zi909qA=
=PYNO
-----END PGP SIGNATURE-----

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

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" <> wrote in message
news:X92dnUR-AbGxRs7fRVn-...
> 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 wrote:
> "Pete Becker" <> wrote in message
> news:X92dnUR-AbGxRs7fRVn-...
>
>>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?

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 wrote:


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

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