C & hardware

[sandeep]

Good day,

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

For example, a command like
*t++ = *s++;
which would take many lines in other languages, in C is a single command,
because it is a single opcode on the PDP11.

Since then, hardware has changed A LOT! But C has hardly changed at all!

I would like to see C develop by adding new language features to match
modern CPU instructions. For example, there could be __packed_int,
__packed_float etc types to let programmers access SSE instructions. Just
like C has bitfields because that was what was going down in hardware
when K&R were active.

Otherwise, over time, C will become further and further removed from the
underlying hardware - and closeness to the hardware is C's main selling
point!

 

[Keith Thompson]

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.

Of the 4 combinations of prefix and postfix increment and decrement,
the PDP-11 only has direct support for two, but C makes no such
distinction.

 

[Ben Bacarisse]

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

No we don't:

"Thompson went a step further by inventing the ++ and -- operators,
which increment or decrement; their prefix or postfix position
determines whether the alteration occurs before or after noting the
value of the operand. They were not in the earliest versions of B, but
appeared along the way. People often guess that they were created to
use the auto-increment and auto-decrement address modes provided by
the DEC PDP-11 on which C and Unix first became popular. This is
historically impossible, since there was no PDP-11 when B was
developed."

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

<snip>

 

[Gene]

Good day,

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

For example, a command like
*t++ = *s++;
which would take many lines in other languages, in C is a single command,
because it is a single opcode on the PDP11.

Since then, hardware has changed A LOT! But C has hardly changed at all!

I would like to see C develop by adding new language features to match
modern CPU instructions. For example, there could be __packed_int,
__packed_float etc types to let programmers access SSE instructions. Just
like C has bitfields because that was what was going down in hardware
when K&R were active.

Otherwise, over time, C will become further and further removed from the
underlying hardware - and closeness to the hardware is C's main selling
point!

As others have said, the PDP11 was not the basis for C's statements.

Perhaps more relevant is that compiler technology has long since moved
past the point where there is any simple mapping between C statements
and instruction choice ... if it was ever there at all. For a simple
example with gcc -O, all of these

int foo(int i) { int j = i + 1; return j; }
int foo(int i) { i = i + 1; return i; }
int foo(int i) { return ++i; }
int foo(int i) { return i + 1; }

compile to identical code on my machine. And that code doesn't use an
x86 increment instruction as you might expect if "close to the
hardware" had any meaning to the compiler.

Hardware features are so proprietary and time-sensitive that the only
realistic way to handle them IMO is proprietary extensions. CUDA is
an example.

 

[Eric Sosman]

Good day,

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

We also know that the Moon is made of green cheese.

"[++ and --] were not in the earliest versions of B, but
appeared along the way. People often guess that they were
created to use the auto-increment and auto-decrement address
modes provided by the DEC PDP-11 on which C and Unix first
became popular. This is historically impossible, since there
was no PDP-11 when B was developed."

-- "The Development of the C Language," Dennis M. Ritchie

 

[jacob navia]

Le 09/10/10 22:51, sandeep a écrit :

Good day,

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

For example, a command like
*t++ = *s++;
which would take many lines in other languages, in C is a single command,
because it is a single opcode on the PDP11.

Since then, hardware has changed A LOT! But C has hardly changed at all!

I would like to see C develop by adding new language features to match
modern CPU instructions. For example, there could be __packed_int,
__packed_float etc types to let programmers access SSE instructions. Just
like C has bitfields because that was what was going down in hardware
when K&R were active.

Otherwise, over time, C will become further and further removed from the
underlying hardware - and closeness to the hardware is C's main selling
point!

You have a valid point with the vector additions. (Vectors of floats,
etc)

This group however, is composed of people that do not want any changes
to the language, the same as the C standards the committee. They have
been so far very successful, and the language is now completely
obsolete.

Many CPUs support truncated addition/subtraction, vectors of floats,
and many other features. So far C has successfully ignored all of them.

No plans are being developed for the next revision of the language
somewhen in 2020.

As you have seen, the people here will take *some* inexact statement of
your message, feast on that, and ignore the main point. This way, they
give the impression of answering without ever developing anything as a
real discussion.

I have tried for years to change this state of affairs. The result has
been that I received a lot of insults, and nothing else.

Good luck

 

[Ian Collins]

Good day,

Since then, hardware has changed A LOT! But C has hardly changed at all!

But compilers have!

The compiler abstracts the hardware from the programmer.

I would like to see C develop by adding new language features to match
modern CPU instructions. For example, there could be __packed_int,
__packed_float etc types to let programmers access SSE instructions. Just
like C has bitfields because that was what was going down in hardware
when K&R were active.

C has never given direct access to core CPU hardware (except on CPUs
with directly addressable registers). We have always had to fall back
to assembler or special optimised libraries to do this. On the platform
I use (Solaris) the native compiler and the standard library do use SSE
instructions or the equivalent for the current hardware.

There are too many differing hardware architectures out there for direct
access to be standardised. The standard would end up a bloated,
continuously changing monstrosity if it did.

Otherwise, over time, C will become further and further removed from the
underlying hardware - and closeness to the hardware is C's main selling
point!

I said above, C has only ever given direct access to memory mapped
hardware. This has always been the case.

 

[Ian Collins]

Le 09/10/10 22:51, sandeep a écrit :

You have a valid point with the vector additions. (Vectors of floats,
etc)

But only on platforms that support them! Even there, it's best to leave
such details to the compiler and library vendor. Most modern compilers
for appropriate hardware support OpenMP, which is where such
abstractions belong.

This group however, is composed of people that do not want any changes
to the language, the same as the C standards the committee. They have
been so far very successful, and the language is now completely
obsolete.

Obvious nonsense.

Many CPUs support truncated addition/subtraction, vectors of floats,
and many other features. So far C has successfully ignored all of them.

But not the clued up library vendors.

I have tried for years to change this state of affairs. The result has
been that I received a lot of insults, and nothing else.

You would have succeed if your extensions had gained widespread acceptance.

 

[Seebs]

This group however, is composed of people that do not want any changes
to the language, the same as the C standards the committee.

No, it isn't. The C standards committee has, in fact, been changing
the language. Heck, I was on it for a while and we changed it quite a
bit.

They have
been so far very successful, and the language is now completely
obsolete.
Nonsense.

Many CPUs support truncated addition/subtraction, vectors of floats,
and many other features. So far C has successfully ignored all of them.

That's a fascinating claim, given that I've not only done a bunch of vector
work in C, but worked with compilers which automatically vectorized
loops. It seems to me that you're missing a bit of the practice that's
made C such a useful and durable language: Rather than immediately
standardizing the first attempt anyone comes up with at solving a problem,
the committee sometimes waits for a few different approaches to get tried,
so that when it's time to standardize something, it can be something that's
actually decent.

This has worked okay thus far.

I have tried for years to change this state of affairs. The result has
been that I received a lot of insults, and nothing else.

Well, ultimately, it's up to you whether to sit around insulting everyone
else and misrepresenting what they say or do, or not. I would recommend
"not", though.

-s

 

[Mok-Kong Shen]

Ian Collins:

jacob navia wrote:

You have a valid point with the vector additions. (Vectors of floats,
etc)

But only on platforms that support them![snip]

A question of ignorance: Would it be unfavourable for C to support the
bit rotation?

M. K. Shen

 

[jacob navia]

Le 10/10/10 01:22, Ian Collins a écrit :

You would have succeed if your extensions had gained widespread acceptance.

More than 1.5 million downloads is not wide acceptance for people like you.

You confuse the people in this dscussion group with C users. But do not
let facts disturb you.

 

[Seebs]

Ian Collins:

You have a valid point with the vector additions. (Vectors of floats,
etc)

But only on platforms that support them![snip]

A question of ignorance: Would it be unfavourable for C to support the
bit rotation?

Some context seems to have been lost here. What do you mean?

If you mean "bit rotation" as opposed to "addition", the phrase "vector
additions" referred, not to calculating several sums at once, but to
adding new vector features (including sums, multiplication, division,
bit rotation, and so on) to C.

-s

 

[jacob navia]

Le 10/10/10 08:44, Mok-Kong Shen a écrit :

Ian Collins:

jacob navia wrote:

You have a valid point with the vector additions. (Vectors of floats,
etc)

But only on platforms that support them![snip]

A question of ignorance: Would it be unfavourable for C to support the
bit rotation?

Or even the overflow indicator, that is almost universal.

 

[Seebs]

Le 10/10/10 01:22, Ian Collins a ??crit :

More than 1.5 million downloads is not wide acceptance
True.

for people like you.

This qualifier is unnecessary.

Widespread acceptance would, usually, imply the existance of a second
implementation, or consensus among other implementations that a proposed
feature was well-designed and worth copying.

"Downloads" are meaningless. How many of those "1.5 million" downloads
represent even *distinct* users? How many of them are using each of these
features? Why are these features not yet found in other implementations?
Heck, how many of the people who have downloaded your compiler *even
know these extensions exist*? I would guess it's not something most
of them are aware of -- most people don't pay that much attention, so far
as I can tell.

If you answer these questions, you may get closer to a useful understanding
of "widespread acceptance".

-s

 

[Ian Collins]

Le 10/10/10 01:22, Ian Collins a écrit :


More than 1.5 million downloads is not wide acceptance for people like you.

I see you have taken *some* inexact statement of my message, feasted on
that, and ignored the main point. This way, you give the impression of
answering without ever developing anything as a real discussion.

By the way, what am I? In the context of this group I'm a C programmer
with a 30 years experience on more platforms than I care to member.

You confuse the people in this dscussion group with C users. But do not
let facts disturb you.

So where are the alternative implementations? Which embedded compilers
support them? Where are the drivers and kernel modules that use them?

Come on, get real. Embedded and kernels is where C matters the most
these days.

 

[Nobody]

I said above, C has only ever given direct access to memory mapped
hardware.

Not even that.

Some implementations may provide it, but C itself doesn't, due to the
reliance upon the "abstract machine" concept.

To have the C language support memory-mapped hardware, the standard would
need to either more precisely define the meaning of "volatile" or add
memory barriers.

 

[Mok-Kong Shen]

Mok-Kong Shen wrote:

Some context seems to have been lost here. What do you mean?

If you mean "bit rotation" as opposed to "addition", the phrase "vector
additions" referred, not to calculating several sums at once, but to
adding new vector features (including sums, multiplication, division,
bit rotation, and so on) to C.

I meant simply ROL and ROR of Intel's assembler.

M. K. Shen

 

[jacob navia]

Le 10/10/10 10:03, Seebs a écrit :

True.

I did a mistake. Answering you is useless.

Sorry, it wont happen again

 

[BartC]

I meant simply ROL and ROR of Intel's assembler.

I use a language that has rol and ror operators, but I don't recall they
have ever been used (unlike shl/shr/sar which are used all the time in the
form of << and >>).

But what about rcl and rcr, or shld and so on? Sometimes it's simpler to
rely on a bit of (inline) assembly on the rare occasions that these are
needed.

 

[Mok-Kong Shen]

BartC wrote:
in message

I use a language that has rol and ror operators, but I don't recall they
have ever been used (unlike shl/shr/sar which are used all the time in
the form of << and >>).

But what about rcl and rcr, or shld and so on? Sometimes it's simpler to
rely on a bit of (inline) assembly on the rare occasions that these are
needed.

If certain feature is generally available on hardware and it is useful
in some fields of practical applications, then I think that it could be
eligible for consideration to be included in a general purpose PL. Bit
rotation could be a convenient operator in e.g. some encryptions
algorithms. Another feature that IMHO could be quite useful is the
carry-over of adding two unsigned int, for that facilitates coding of
multiple-precision arithmetics.

M. K. Shen