Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Is Not a Low-Level Language

queue.acm.org

Post reply on HN
Print view View original

91–100 of 326 posts

Re: C Is Not a Low-Level Language

#91

Post by munificent »

School-Cotton wrote: post #49

The points made in the article are certainly valid, but C is low-level in an abstract sense: it is approximately the intersection of all mainstream languages. I.e. if a feature exists in C, it probably exists in every language most programmers are familiar with. (I worded this statement carefully to exclude exotic languages like Haskell or Erlang). Thus C, while not low-level relative to actual hardware, is low-level…

> if a feature exists in C, it probably exists in every language most programmers are familiar with.

I don't think that's true.

Off the top of my head, C has: array point decay, padding, bit fields, static types, stack allocated arrays, integers of various sizes, untagged enums, goto, labels, pointer arithmetic, setjmp/longjmp, static variables, void pointers, the C preprocessor.

Those features are all absent in many other languages and are totally foreign to users that only know those languages. A large part of C is exposing a model that memory is a freely-interpretable giant array of bytes. Most other languages today are memory safe and go out of their way to not expose that model.

Re: C Is Not a Low-Level Language

#92

Post by emilfihlman »

This article is completely clickbait.

C is low level. For example, with AVRs everything you do maps very clearly to what happens as opcodes.

It's like the author wants to blame C for whatever reason and conveniently forgets that C is also portable.

Re: C Is Not a Low-Level Language

#93

Post by munificent »

I really really liked this article, and reading the comments here is blowing my mind. Did we read the same thing?

I think it's a strong insight that insight that chip designers and compiler vendors have spent person-millenia maintaining the illusion that we are targeting a PDP-11-like platform even while the platform has grown less and less like that. And, it turns out, with things like Spectre and the performance cost of cache misses, that abstraction layer is quite leaky in potentially disastrous ways.

But, at the same time, they have done such a good job of maintaining that illusion that we forget it isn't actually reality.

I like the title of the article because many programmers today do still think C is a close mapping to how chips work. If you happen to be one of the enlightening minority who know that hasn't been true for a while, that's great, but I don't think it's good to criticize the title based on that.

Re: C Is Not a Low-Level Language

#94

Post by mattnewport »

greglindahl wrote: post #71
mattnewport wrote: post #23

Earlier quoted context omitted.

I think you can make a good case that the failure of the Itanium (and other similar attempts to un-hide some of this stuff like the IBM/Sony Cell used in the PlayStation 3) was precisely because they tried to shift optimization work from the CPU to the compiler / programmer.

Funny, the compiler people I've worked with complain that Itanium tried to do too much in hardware, like the hw support for loop unrolling, which made superpipelining optimizations in existing compilers much more complicated.

Loop unrolling is one of those optimizations that actually highlights the need for dynamic CPU optimizations like out of order execution and speculative execution. It's very difficult to statically make a good decision about the optimal amount of loop unrolling to do, especially if you want to generate code that will continue to perform well on future CPUs using the same ISA. Even when targeting a specific CPU model it's difficult however since you don't know statically how many iterations of the loop you're expecting, what's currently in cache, what other code might be running immediately before or after the loop, what's running at the same time on other threads, etc.

Re: C Is Not a Low-Level Language

#95

Post by dgreensp »

rhacker wrote: post #76

The article itself has 4 definitions or "attributes" for low-level languages that can be considered contradictory: * "A programming language is low level when its programs require attention to the irrelevant." * Low-level languages are "close to the metal," whereas high-level languages are closer to how humans think. * One of the common attributes ascribed to low-level languages is that they're fast. * One of the key…

I think the author's point is that despite being perceived as low-level, C doesn't really differ from, say, Java on the last bullet.

In other words, a programmer who sits down and uses C and not Java might think, "I am being forced to pay attention to irrelevant things and think in unnatural ways, but that's because I am writing fast code using operations that map to operations done by the physical machine. In a higher-level language like Java, more of these details are out of my control because they are abstracted away by the language and handled by the compiler."

I think the article does a great job dismantling this point of view, and telling the story that C is not so different from Java, aside from being unsafe and ill-specified.

Re: C Is Not a Low-Level Language

#96

Post by admax88q »

pvg wrote: post #85
coldtea wrote: post #74

Earlier quoted context omitted.

Nope, also in the way the parent explains right after that sentence.

It's a pretty terrible analogy in nearly every obvious technical way. What an x86 cpu does with its instructions is almost but not entirely unlike what a JVM does.

None of the "registers" in x86 assembly are real. Few of the instructions are implemented in hardware, most are impelmented in software microcode.

Advanced hardware will re-order and pipeline instructions based upon data dependencies.

Sure it's not doing the exact same things the JVM does with bytecode but the point is that x86 assembly is not the language of the hardware. It's a language that the hardware+firmware knows how to interpret and optimize at runtime similar to what your JVM does with java bytecode.

Re: C Is Not a Low-Level Language

#97

Post by [deleted] »

admax88q wrote: post #58
mattnewport wrote: post #5

This article makes some valid points but is overall rather misleading I think. Almost all of the reasons given why C is "not a low-level language" also apply to x86/x64 assembly. Register renaming, cache hierarchies, out of order and speculative execution etc are not visible at the assembly / machine code level either on Intel or other mainstream CPU architectures like ARM or Power PC. If C is not a low level languag…

> If C is not a low level language then a low level language does not exist for modern CPUs I think that's a fair conclusion though, I don't think the article is misleading. x86 assembly is a high level language. It's analogous to JVM bytecode. Modern x86 processors are more like a virtual machine for x86 bytecode.

[deleted]

Re: C Is Not a Low-Level Language

#98

Post by dgreensp »

arghwhat wrote: post #54

It is correct that C is not really a low level language, but the points about how C limits the processor doesn't make much sense. It uses UltraSPARC T1 and above processors as an example for a "better" processor "not made for C", but this argument makes no sense at all. The "unique" approach in the UltraSPARC T1 was to aim for many simple cores rather than few large cores. This is simply about prioritizing silicon. H…

The point is specifically about parallel vs sequential programs. Legacy C code is sequential, and the C model makes parallel programming very difficult.

I met a guy back in college, a PhD who went to work at Intel, who told me the same thing. In theory, the future of general purpose computing was tons of small cores. In practice, Intel's customers just wanted existing C code to keep running exponentially faster.

Re: C Is Not a Low-Level Language

#99

Post by SomeHacker44 »

kevstev wrote: post #26
thinkling wrote: post #3

TLDR: C was close-to-the-metal on the PDP-11 but since then hardware has become more complex while exposing the same abstraction to the C programmer. That means that hardware features such as speculative execution and L1/L2 caching are invisible to the programmer. This was the cause of Spectre and Meltdown and it forces a lot of complexity into the compiler. GPUs achieve high performance in part because their program…

I was with you until the last sentence: "Processors would be able to evolve if they weren't hamstrung by having to support C." I don't think its fair or correct to say that C is the real issue. Recently there have been languages like erlang and support for more functional models that make concurrent code a lot easier to write. The first real consumer multicore processors were only released a bit over 10 years with In…

My Symbolics computers (running Symbolics Ivory processors) run Lisp really well, as well as C - they have a C compiler.

I have operational computers of a variety of architectures at home, including the oldest generations (6502, 680x0), Sparc, Symbolics, DEC Alpha, MIPS 32- and 64-bit, etc., and even an extremely rare (and unfortunately not-running) Multiflow, the granddaddy of VLIW.

My favorite part of the original article was the final section. I wish we had a modern CPU renassiance akin to what was going on in the 80s and 90s, but the market dominance of x64 and ARM seems to be squelching things, with optimizations to those architectures rather than novel new ones (with possibly novel new compiler technologies). 64-bit ARM was a nice little improvement, though.

Post reply on HN