Another inline assembly question

[Johannes Bauer]

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

 

[Artie Gold]

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

 

[Ioannis Vranos]

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.

 

[Johannes Bauer]

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

 

[Karl Heinz Buchegger]

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.

 

[Pete Becker]

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.

 

[Walter]

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

 

[Victor Bazarov]

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?

 

[Ioannis Vranos]

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.

 

[E. Robert Tisdale]

Ioannis Vranos wrote:

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

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

 

[Ioannis Vranos]

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?

 

[Walter]

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

 

[Ioannis Vranos]

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]

There can be.






There can be.





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





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.





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

There can be = May exist