C & hardware

[Ian Collins]

Interesting stuff. An attempt to come up with something broad enough to be
generally implementable on most hardware. But everything is described in
terms of C++ - will the C language follow?

Yes, the header name is a dead give-away!

 

[FredK]

Yes, the header name is a dead give-away!

When reading the actual standards being proposed, it turned out to be what
appears to be a marked up C++ spec. Some of the stuff implied C but then
some of what looked to be types had C++ stuff in them. So it wasn't clear
that this is a proposed C standard (as opposed perhaps something that will
show up in gcc - which I do not use).

 

[FredK]

My earlier citation to N1425 7.16, et al, was to a recent draft C
standard:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1425.pdf

Firefox hung on it when I fist clicked. So I didn't bother to look at it.
The Wiki page had mostly C++ references. Thanks for the pointer.

With any luck it won't require compiling in C99 mode to use

 

[Chris H]

You are right in that there are public software, in particular
libraries, which he can examine. On the other hand, the major part
of software is IMHO proprietary or else theoretically available
but not accessible without knowledge of its existance and of the
proper contact persons. So I doubt that the compiler writer could
obtain an accurate global picture of how the compiler is being used,
even if he cares to obtain that knowledge.

All the compiler writers I know have access to the information you talk
about and have direct contact with the silicon companies *before* MCU
are released. I have seen chips modified on the advice of compiler
writers.

 

[Chris H]

Technical standards change when there is a honest, rational and
reasonable need for them to change.
If no one can think of a reasonable issue and come up with a reasonable
proposal to tackle that
issue then there is absolutely no reason to change stuff. Change for
the sake of changing doesn't
do anyone any good. This isn't supposed to be a competition.

I would like to think that what you have said is true. Unfortunately I
know it isn't. Just look at C99 and the last Basic standard.....

 

[Mok-Kong Shen]

Mok-Kong Shen wrote: [snip]
What you describe here are quality of implementation optimisations
rather than something that should be included in a language standard.

[snip]

I rather doubt there is a very clear demarcation between what is
optional implementation optimalzation and what should unconditionally
be in a PL (considering that all computations could be done with a TM).

M. K. Shen

 

[Mok-Kong Shen]

All the compiler writers I know have access to the information you talk
about and have direct contact with the silicon companies *before* MCU
are released. I have seen chips modified on the advice of compiler
writers.

I was also saying above of the 'global picture'. Certainly I can't know
how the compiler writers access much of running software in practice.
But I am quite sure that at least the software there were developed
at the place that I previously worked were not accessible to outsiders.
And I doubt that e.g. the banks and assurance firms would let their
stuff into foreign hands.

M. K. Shen

 

[robertwessel2]

I was also saying above of the 'global picture'. Certainly I can't know
how the compiler writers access much of running software in practice.
But I am quite sure that at least the software there were developed
at the place that I previously worked were not accessible to outsiders.
And I doubt that e.g. the banks and assurance firms would let their
stuff into foreign hands.

You don't need access to every bit of software in the world. It's not
even remotely practical - how could anyone deal with that deluge of
data? Analysis of that isn’t something that can be automated either
(if you had a program that could automatically determine that a
compiler was generating inefficient code for a particular sequence,
why didn't you ship that instead of the compiler you did ship?). And
the customers with the biggest needs for high performance tend to be
somewhat vocal about it.

 

[Seebs]

The fact that lots of compilers generate shows that an essential need
has been identified by a number of compiler writers but that would also
mean that maybe some compiler writers may have missed that. On hardware
that does not have the rotation instructions, the compiler writer can
implement with shifts (in which case it saves the user the trouble to
write the shifts himself).

I suppose, but this doesn't strike me as evidence that we need a change.
On hardware which has rotates, they appear to get used when they are
appropriate.

Anyway, I consider it a rather unusual and
lucky result that the compiler writers have reacted to this issue.

I don't.

(They normally have no knowledge of users' programs and presumably must
have obtained some suggestions from the users.)

This is a fascinating theory. However, I am regularly besieged by user
code, so I'm pretty sure it's not true. Users love nothing more than
presenting code to compiler maintainers and demanding that it should
behave differently and do so faster.

-s

 

[BartC]

I suppose, but this doesn't strike me as evidence that we need a change.
On hardware which has rotates, they appear to get used when they are
appropriate.

That's like saying we don't need a multiply op in the language, because the
adds and shifts that are otherwise needed, get converted into a hardware
multiply by a super-clever compiler.

It is much easier to add a few extra ops into a language and not use them
very often, than to leave them out and have to rely on tricks by programmers
and compiler writers.

 

[Keith Thompson]

That's like saying we don't need a multiply op in the language, because the
adds and shifts that are otherwise needed, get converted into a hardware
multiply by a super-clever compiler.
Perhaps.

It is much easier to add a few extra ops into a language and not use them
very often, than to leave them out and have to rely on tricks by programmers
and compiler writers.

[Context: bit rotation operators]

Really? You might have a valid argument in favor of adding rotation
operators to the language at the beginning. But at this point,
I think it would require a tremendous effort with little payoff.
We'd have to define symbols for the new operators and define their
precedence (and survive the inevitable flame wars, because plenty
of people are going to think the new syntax is ugly and/or "not
in the spirit of C"). If the new symbols are new keywords such
as "rol" and "ror", then we break existing code that uses those
identifiers (possibly the very code that would benefit from the
operators). Then the new operators would have to be included in a
new C standard. If we're *extremely* optimistic, we might imagine
them being standardized in C201X.

And then programmers will have to wait for C201X, or at least this
feature, to be supported by all the compilers their code might be
used with before they can safely use them.

I suppose they could start now by writing pre-C201X and C201X
versions of the code, controlled by #if or #ifdef. But then
they'll have to maintain both versions for a very long time --
and one version or the other might get very little testing.

Changing a compiler to implement the new operators (even for systems
that don't support the operations in hardware) is the easy part.

If you think I'm being overly pessimistic, please convince me.

 

[jacob navia]

Le 12/10/10 21:49, Keith Thompson a écrit :

Really? You might have a valid argument in favor of adding rotation
operators to the language at the beginning. But at this point,

I think the right solution is just to add a library function... Not a
great deal.

 

[Keith Thompson]

Le 12/10/10 21:49, Keith Thompson a écrit :

I think the right solution is just to add a library function... Not a
great deal.

That makes sense.

It's already easy enough to add system-specific library functions for
bitwise rotations, and the can take advantage of compiler-specific
extensions so they expand to single instructions where possible.
(I don't know whether many library providers have done this;
if not, it might suggest that there's really not much demand for
the feature.)

On the other hand, adding such library functions to the standard
would still present most of the problems I mentioned in my previous
post.

(BTW, thank you for not accusing me of wanting the language to
stagnate and die.)

 

[Bill Cunningham]

We know that C was originally designed as a highlevel language to
abstract the opcodes of the PDP11.

[...]

No, it wasn't. The ++ and -- operators were introduced in C's
ancestor language B, which predates the PDP-11.

Yep. B to NB to C.

Bill

 

[Seebs]

That's like saying we don't need a multiply op in the language, because the
adds and shifts that are otherwise needed, get converted into a hardware
multiply by a super-clever compiler.

I don't think so. The relation between shifts and rotates is trivial, the
relation between shifts and multiplies is not.

It is much easier to add a few extra ops into a language and not use them
very often, than to leave them out and have to rely on tricks by programmers
and compiler writers.

In general, yes, but I think at this point, there's a massive cost to adding
the hypothesized new operators, and very little benefit for a LONG time.
I'm not inalterably opposed, but I'm not seeing much immediate benefit, and
I'm not even sure the long-term benefit would be there. I dunno. Maybe we
should, on the off chance that C is still in use 70 years from now, by which
time most compilers will have implemented at least half of the new features
of C99.

-s

 

[Ben Bacarisse]

We know that C was originally designed as a highlevel language to
abstract the opcodes of the PDP11.

[...]

No, it wasn't. The ++ and -- operators were introduced in C's
ancestor language B, which predates the PDP-11.

Yep. B to NB to C.

What's NB?

 

[Lew Pitcher]

We know that C was originally designed as a highlevel language to
abstract the opcodes of the PDP11.
[...]

No, it wasn't. The ++ and -- operators were introduced in C's
ancestor language B, which predates the PDP-11.

Yep. B to NB to C.

What's NB?

"New" B

 

[Ben Bacarisse]

Keith Thompson wrote:
We know that C was originally designed as a highlevel language to
abstract the opcodes of the PDP11.
[...]

No, it wasn't. The ++ and -- operators were introduced in C's
ancestor language B, which predates the PDP-11.

Yep. B to NB to C.

What's NB?

"New" B

I though that might be it. Seems hardy worth mentioning as a language:

"NB existed so briefly that no full description of it was written"

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

 

[Nick]

That makes sense.

It's already easy enough to add system-specific library functions for
bitwise rotations, and the can take advantage of compiler-specific
extensions so they expand to single instructions where possible.
(I don't know whether many library providers have done this;
if not, it might suggest that there's really not much demand for
the feature.)

It would also cope with the things that you might want to put in there,
that are available on some hardware, and are not easy to write.
Population count springs to mind.

In fact, when you look how many poor bit manipulation macros and
functions there are floating around out there, it's slightly surprising
a "bits.h" with rotate, population count, bit set and test, exclusive OR
and the like hasn't been proposed/implemented.

On the other hand, adding such library functions to the standard
would still present most of the problems I mentioned in my previous
post.

Although you can at least avoid including the header if you don't want
them in the namespace.

 

[Mok-Kong Shen]

[Context: bit rotation operators]

Really? You might have a valid argument in favor of adding rotation
operators to the language at the beginning. But at this point,
I think it would require a tremendous effort with little payoff.
We'd have to define symbols for the new operators and define their
precedence (and survive the inevitable flame wars, because plenty
of people are going to think the new syntax is ugly and/or "not
in the spirit of C"). If the new symbols are new keywords such
as "rol" and "ror", then we break existing code that uses those
identifiers (possibly the very code that would benefit from the
operators). Then the new operators would have to be included in a
new C standard. If we're *extremely* optimistic, we might imagine
them being standardized in C201X.

And then programmers will have to wait for C201X, or at least this
feature, to be supported by all the compilers their code might be
used with before they can safely use them.

I suppose they could start now by writing pre-C201X and C201X
versions of the code, controlled by #if or #ifdef. But then
they'll have to maintain both versions for a very long time --
and one version or the other might get very little testing.

Changing a compiler to implement the new operators (even for systems
that don't support the operations in hardware) is the easy part.

If you think I'm being overly pessimistic, please convince me.

There are already usages in the literature of the symbols <<< and >>>
for bit rotations, which seem to be appropriate IMHO.

jacob navia in his follow-up suggested having library functions for
rotations, though operator symbols would seem to be more convenient.

M. K. Shen