1. 23
    C Is Not a Low-level Language c queue.acm.org
  1.  

    1. 3

      oops I didn’t find it with a quick search

    2. 5

      Neither is assembly. Processors do their own aggressive optimization (pipelining, reordering, …) internally.

      1. 10

        As far as I gather, that’s part of the point of this article. It argues that processors have evolved to accelerate code written for C, while not really doing that much to expose APIs to power newer, faster-than-C forms of computation. SIMD is one example of something that bucks this trend, but I think the article is saying that there’s much more that could be done for being able to more directly interface with the low level capabilities of our current and future processors.

        1. 1

          But it makes perfect sense for processor makers to do that. You optimize for what is, not what could be. Otherwise you (usually) find you’ve expended a lot of work on optimizing something that never sees use.

      2. 5

        Replying to a point made on the previous thread @tedu linked to:

        I enjoyed this, but it did make me wonder – what would a true low-level language designed today actually look like? I’ll hang up and take your answers over the air.

        How about Mill ConAsm? It exposes the number of execution units and their parallelism directly in the assembler code. It’s obviously a compiler target, because human beings do not want to screw with scheduling by hand, and the compiler will usually come up with a good schedule for you.

        1. 4

          One of the common attributes ascribed to low-level languages is that they’re fast. In particular, they should be easy to translate into fast code without requiring a particularly complex compiler.

          I don’t agree. Low-level is not well-defined, but I think people usually use it to mean ‘low abstraction’ (over assembly). Now, even with this definition you could argue that C is not a low-level language (since the assembly that compilers generate is not always straightforward), but I still think this is not a very good definition.

          1. 5

            The issue with defining “level of abstraction” relative to the native assembly language is that it implies Lisp and BASIC are very low-level languages on computers which define a comparatively high-level assembly (e.g. Lisp machines, BASIC chips, etc.)

            We can’t just say “hey, x86 assembly is the watermark for what constitutes a low-level language” without some further reasoning around why we pick specifically x86 assembly (or MIPS, or ARM, or whatever – but don’t pick an instruction set thats too RISC-y, because then x86 assembly will start looking like a high level language…)

          2. 1

            It is best to say that these days C is a lower level language, ie not exactly low, but not exactly high also. There was a time that even a journal dedicated to C translation existed. Not any more.

            1. 1

              Someone pointed out on the old thread that this argument is bunk. For example, caches already existed on the PDP11. It takes a certain kind of ego to think that hardware is catering to the software people, instead of doing it the same way for good reasons.

              No hardware guy hasn’t learned assembler. New instructions and instruction sets would be available, if they were thought to be good ideas.