C & hardware

Discussion in 'C Programming' started by sandeep, Oct 9, 2010.

  1. sandeep

    sandeep Guest

    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!
     
    sandeep, Oct 9, 2010
    #1
    1. Advertisements

  2. [...]

    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.
     
    Keith Thompson, Oct 9, 2010
    #2
    1. Advertisements

  3. 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>
     
    Ben Bacarisse, Oct 9, 2010
    #3
  4. sandeep

    Gene Guest

    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.
     
    Gene, Oct 9, 2010
    #4
  5. sandeep

    Eric Sosman Guest

    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
     
    Eric Sosman, Oct 9, 2010
    #5
  6. sandeep

    jacob navia Guest

    Le 09/10/10 22:51, sandeep a écrit :
    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
     
    jacob navia, Oct 9, 2010
    #6
  7. sandeep

    Ian Collins Guest

    But compilers have!

    The compiler abstracts the hardware from the programmer.
    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.
    I said above, C has only ever given direct access to memory mapped
    hardware. This has always been the case.
     
    Ian Collins, Oct 10, 2010
    #7
  8. sandeep

    Ian Collins Guest

    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.
    Obvious nonsense.
    But not the clued up library vendors.
    You would have succeed if your extensions had gained widespread acceptance.
     
    Ian Collins, Oct 10, 2010
    #8
  9. sandeep

    Seebs Guest

    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.
    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.
    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
     
    Seebs, Oct 10, 2010
    #9
  10. Ian Collins:
    A question of ignorance: Would it be unfavourable for C to support the
    bit rotation?

    M. K. Shen
     
    Mok-Kong Shen, Oct 10, 2010
    #10
  11. sandeep

    jacob navia Guest

    Le 10/10/10 01:22, Ian Collins a écrit :
    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.
     
    jacob navia, Oct 10, 2010
    #11
  12. sandeep

    Seebs Guest

    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
     
    Seebs, Oct 10, 2010
    #12
  13. sandeep

    jacob navia Guest

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

    Or even the overflow indicator, that is almost universal.
     
    jacob navia, Oct 10, 2010
    #13
  14. sandeep

    Seebs Guest

    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
     
    Seebs, Oct 10, 2010
    #14
  15. sandeep

    Ian Collins Guest

    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.
    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.
     
    Ian Collins, Oct 10, 2010
    #15
  16. sandeep

    Nobody Guest

    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.
     
    Nobody, Oct 10, 2010
    #16
  17. I meant simply ROL and ROR of Intel's assembler.

    M. K. Shen
     
    Mok-Kong Shen, Oct 10, 2010
    #17
  18. sandeep

    jacob navia Guest

    Le 10/10/10 10:03, Seebs a écrit :
    I did a mistake. Answering you is useless.

    Sorry, it wont happen again
     
    jacob navia, Oct 10, 2010
    #18
  19. sandeep

    BartC Guest

    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.
     
    BartC, Oct 10, 2010
    #19
  20. BartC wrote:
    in message
    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
     
    Mok-Kong Shen, Oct 10, 2010
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.