C & hardware

[Rui Maciel]

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.

If no one even bothered to write a library to implement that particular feature then I believe that
that is a good indicator of the demand for that particular feature. Therefore, arguing for the
extension of the core language to implement an obscure feature which practically no one ever needs
is nothing more than a terribly impractical and cumbersome solution searching for a problem.


Rui Maciel

 

[James Dow Allen]

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

I've used rotates but really can't remember when, or
if it was much more purposeful than "because I can!" ;-)

BUT, unless I'm mistaken it was just a few weeks ago
in this ng that someone pointed out gcc actually *produces"
rol/ror opcode when it can recognize the appropriate
(x << N ) | (x >> 32 - N)
idiom!

(BTW, this reminds me of a minor point I thought of
mentioning in a nearby thread. I *like* that + and -
have precedence over >> and <<. That's far more likely
to be desired when << is used as bit-shift rather than
multiply. (And rather then write (x << 3) to multiply
by 8, it's better to write (x * 8) and, in the rare case
where tiny speed improvement matters, check the output,
redefining 'x' as necessary.))

James Dow Allen

 

[BartC]

I've used rotates but really can't remember when, or
if it was much more purposeful than "because I can!" ;-)

BUT, unless I'm mistaken it was just a few weeks ago
in this ng that someone pointed out gcc actually *produces"
rol/ror opcode when it can recognize the appropriate
(x << N ) | (x >> 32 - N)
idiom!

I think you've just made a case for including rol/ror in the language.

 

[Mok-Kong Shen]

If no one even bothered to write a library to implement that particular feature then I believe that
that is a good indicator of the demand for that particular feature.

At least there are several multiple-precision arithmetic libraries to
support my point on the carry-over, I suppose.

M. K. Shen

 

[Gene]

Ian Collins:

But only on platforms that support them![snip]

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

Again, it's not probably not best to clutter the syntax when the
compiler normally deduces the right instruction.

On my (32-bit) machine, gcc compiles the body of

unsigned rotate_left(unsigned x) { return (x << 1) | (x >> 31); }

into a rotation instruction, and the function inlines to the same
single instruction quite nicely.

Now and then it _would_ be good to have access to overflow information
re integer arithmetic. Compilers don't seem wired to translate
unsigned c=a+b; ... c < a || c < b ? ... into a check of the overflow
flag. But even there adding the support means that on some
architectures the standard would have to specify number reps and
arithmetic in a way that could have unintended consequences. The
essence here is that everything added to a standard has a true dollar
cost for implementers. Even if a change seems "easy," these costs can
be significant when considered over long periods of time and hundreds
or thousands of implementers. They have to be compared against the
dollar benefits of marginal utility gained, which are far harder to
estimate. How many people would choose some other language because C
lacks bit rotation or overflow access primitives? These are the
kinds of things that must drive standards decisions, however much we'd
like it to be otherwise.

 

[BartC]

On my (32-bit) machine, gcc compiles the body of

unsigned rotate_left(unsigned x) { return (x << 1) | (x >> 31); }

into a rotation instruction, and the function inlines to the same
single instruction quite nicely.

If there really is a use for it, then I'd rather there was a special
operator for it than having to write (x<<n) | ... or whatever it is for n
places, and having to hard-code the number of bits in a word.

Now and then it _would_ be good to have access to overflow information
re integer arithmetic. Compilers don't seem wired to translate
unsigned c=a+b; ... c < a || c < b ? ... into a check of the overflow
flag. But even there adding the support means that on some
architectures the standard would have to specify number reps and
arithmetic in a way that could have unintended consequences. The
essence here is that everything added to a standard has a true dollar
cost for implementers. Even if a change seems "easy," these costs can
be significant when considered over long periods of time and hundreds
or thousands of implementers.

I've implemented ROL/ROR and I can tell you the extra overhead is minimal,
once << and >> already exist. Possibly just another couple of entries in a
table.

(And once in place for integer values, for some languages they can then also
be applied to types such as strings and lists)

But making use of RCL/RCR versions, in general anything involving carry and
overflow, is awkward to add to a high-level language.

 

[Mok-Kong Shen]

........ Even if a change seems "easy," these costs can
be significant when considered over long periods of time and hundreds
or thousands of implementers. They have to be compared against the
dollar benefits of marginal utility gained, which are far harder to
estimate. How many people would choose some other language because C
lacks bit rotation or overflow access primitives? These are the
kinds of things that must drive standards decisions, however much we'd
like it to be otherwise.

It's my (though maybe wrong) impression that the standard of Fortran
is changing at a higher speed than C.

M. K. Shen

 

[Kenny McCormack]

It's my (though maybe wrong) impression that the standard of Fortran
is changing at a higher speed than C.

As the regs frequently point out - and in this, they are, basically,
right, although as usual, their emphasis, focus, and consequential
actions are all wrong - C mainly lives on today in the area of embedded
and kernels. Fortran, OTOH, still at least tries to be a desktop
language. Therefore, it makes sense for it to evolve, whereas with C,
it does not (sorry, Jacob).

--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

(Paul Krugman - Addicted to Bush)

 

[Mok-Kong Shen]

As the regs frequently point out - and in this, they are, basically,
right, although as usual, their emphasis, focus, and consequential
actions are all wrong - C mainly lives on today in the area of embedded
and kernels. Fortran, OTOH, still at least tries to be a desktop
language. Therefore, it makes sense for it to evolve, whereas with C,
it does not (sorry, Jacob).

Maybe I misunderstood, but in the field of embeded applications, I
suppose the development of ADA should not be ignored.

M. K. Shen

 

[Seebs]

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

What about them, I guess? Lots of compilers generate rotate instructions
when they're appropriate, on hardware which has them. Not all hardware
has them.

-s

 

[Seebs]

I think you've just made a case for including rol/ror in the language.

I don't. I think that's a case for not needing to include it as its own
construct, since where it matters, compilers are already doing it.

-s

 

[Seebs]

I did a mistake. Answering you is useless.

It can certainly be done successfully.

The problem here is not with any kind of crazy conspiracy against C -- it's
just that you're unwilling to respond in any way to the actual people you
keep maligning, rather than to the straw men you've invented for them. It's
pretty frustrating watching you consistently and repeatedly lie about what
other people in the group say, believe, or do. Why do you keep doing this?
What's in it for you? How are you better off with this theory that people
are militantly opposed to change when they have repeatedly and actively pushed
change forwards?

-s

 

[Seebs]

It's my (though maybe wrong) impression that the standard of Fortran
is changing at a higher speed than C.

Could be. I have no idea. Since I haven't actually seen or heard of anyone
using Fortran for new code since the 70s, the question has been of very little
interest to me.

I am not at all convinced that speed-of-change is a useful metric, though.
There are a couple of things I care about in a language spec's growth or
change:

1. Is the language doing a good job of meeting the needs the language is
designed for?
2. Are changes to the specification being widely adopted?

If changes are so sweeping that no one adopts them, they do me no good. If
changes are so minimal that, while they've been adopted, they don't improve my
life, they also do me no good. Many C99 features were, empirically, a bit too
sweeping -- they didn't get widely adopted, even a decade later.

No amount of wanting the language to change on behalf of the standardization
people can force compiler writers to care.

-s

 

[Mok-Kong Shen]

No amount of wanting the language to change on behalf of the standardization
people can force compiler writers to care.

That seems not to be true in case of e.g. ADA.

M. K. Shen

 

[BartC]

I disagree. How do you define rotate right?

Since the proposal was to mimic the operation of hardware rotates, this is
straightforward, eg. a rotation of 8, 16 or 32 bits for x86-32, regardless
of whether the values are signed or unsigned.

Does the high bit of ((someexpression | 1) rotateright 1) become
(<typeofleftexpression>_MAX+1)/2? Does integer promotion make it
impossible to rotate right using a size less than int?

When I implemented rotate ops, they worked on 8, 16 or 32 bits depending on
the type of the left operand, as you might expect.

This causes a problem in C because intermediate results must be ints.

But this is responsible for all sorts of other problems too: eg.:

char c=0xC0;
int a = c<<1;

Should a be 0x80 or 0x180? There is a case for both results.

James's expression describes exactly what is produced, regardless of the
register size, assuming that the type of x is at least 32 bits long.

I think the main requirements will be to rotate entire bytes, shorts and
ints, rather than either the bottom N bits of a value, or an arbitrary
bitfield. The latter are always possible via the normal bit operations.

I like the gcc approach: the programmer codes the arithmetic result and
the compiler generates the shortcut where possible.

I think you've got that back to front: usually the source code uses the
simplest, most obvious expression, while the compiler generates the
nightmare code needed to achieve it.

Rotates can be generated for any supported word size for which the target
has a rotate instruction and the resulting code is more portable, not
depending on hardware specifics.

If it's that critical then rotates can be implemented as built-in functions
with 3 operands: value to rotate, shift count, and field width. I wouldn't
object to that, although it would be nice to be able to write:

a rol=1;

instead of:

a = rotateleft(a,1,32);

 

[Rui Maciel]

At least there are several multiple-precision arithmetic libraries to
support my point on the carry-over, I suppose.

Can you point out what libraries were written in the C programming language whose developers not
only had the need to implement any form of bit rotation but also complained that the C programming
language should be changed in order to offer that feature in the core language?


Rui Maciel

 

[Seebs]

That seems not to be true in case of e.g. ADA.

Of course not. ADA is in a very different market than C. ADA is being used
in cases where it is quite probable that the conditions for acceptance of
a program include verification that the compiler is certified to follow the
standard.

No one is going to stop using Linux on the grounds that gcc doesn't fully
implement C99, therefore the Linux kernel hasn't been compiled with a fully
validated compiler.

-s

 

[Thad Smith]

I think you've just made a case for including rol/ror in the language.

I disagree. How do you define rotate right? Does the high bit of
((someexpression | 1) rotateright 1) become (<typeofleftexpression>_MAX+1)/2?
Does integer promotion make it impossible to rotate right using a size less than
int?

James's expression describes exactly what is produced, regardless of the
register size, assuming that the type of x is at least 32 bits long. I like the
gcc approach: the programmer codes the arithmetic result and the compiler
generates the shortcut where possible. Rotates can be generated for any
supported word size for which the target has a rotate instruction and the
resulting code is more portable, not depending on hardware specifics.

 

[jacob navia]

Le 10/10/10 19:27, Rui Maciel a écrit :

Can you point out what libraries were written in the C programming language whose developers not
only had the need to implement any form of bit rotation but also complained that the C programming
language should be changed in order to offer that feature in the core language?


Rui Maciel

Microsoft implemented rotatel if memory serves. I added a similar
function to lcc-win.

C++ implements it in the STL.


And has been noted elsethread, gcc's developers implemented it in the
compiler. Intel implemented it in hardware together with most CPUs
implementors.

It must be a reason for that...

But maybe I misunderstood your statement. You meant maybe only in
multiple precision contexts?

jacob

 

[Ian Collins]

It can certainly be done successfully.

The problem here is not with any kind of crazy conspiracy against C -- it's
just that you're unwilling to respond in any way to the actual people you
keep maligning, rather than to the straw men you've invented for them. It's
pretty frustrating watching you consistently and repeatedly lie about what
other people in the group say, believe, or do. Why do you keep doing this?
What's in it for you? How are you better off with this theory that people
are militantly opposed to change when they have repeatedly and actively pushed
change forwards?

I don't think it is possible to get Jacob to engage in a technical
debate, he appears to take any disagreement with is position as a
personal insult.