Live data from Hacker News

C Is Not a Low-Level Language

queue.acm.org

111–120 of 326 posts

Re: C Is Not a Low-Level Language

#111

Ok, w/o dipping into machine code, show me a low level language. Any snippet of C-code is transparent in that you know roughly how it is going to be translated into machine code.

> Any snippet of C-code is transparent in that you know roughly how it is going to be translated into machine code. This isn't really true on a modern optimizing compiler.

Precisely. As someone who's tried to duel a compiler for performance, -O3 has very little resemblance to anything I've ever written, and outperforms what I've written significantly.

Re: C Is Not a Low-Level Language

#112

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.

It's a fair conclusion if you're willing to accept that the phrase "low-level language" has approximately zero modern examples.

Or maybe we should relax the definition of "low-level language" a bit?

Re: C Is Not a Low-Level Language

#113

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…

> I worded this statement carefully to exclude exotic languages like Haskell or Erlang I suspect that your definition of "exotic" is exactly "not like C".

Which is kinda true. Most popular languages are C like.

Re: C Is Not a Low-Level Language

#114

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.

Hmm, what does "virtual machine" mean if the "virtual machine" is implemented in hardware?

And, is nothing but actual binary machine code a "low level language"? I guess it's the lowest, I don't _think_ you can go lower than that... but someone's probably gonna tell me I'm wrong.

Re: C Is Not a Low-Level Language

#116

Earlier quoted context omitted.

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…

Itanium's hardware did not make any of these things easier.

Re: C Is Not a Low-Level Language

#118
Language evolves. C is certainly lower level than C# or JavaScript, so even if it no longer fits the definition created decades ago, I don't see a problem with the term evolving to match modern times. People say assembly language when they mean assembly language, (which others have argued isn't low level any more anyway) so using low level to describe a language closer to the hardware seems valid to me. It's interesting that the author argues C could be considered low level on the PDP-11, because by the old definition used back it definitely wouldn't be. That tells me the author's definition of low level is already an evolution of the original definition, so there's no reason the term can't evolve some more.

Wiki definition:

"A low-level programming language is a programming language that provides little or no abstraction from a computer's instruction set architecture—commands or functions in the language map closely to processor instructions. Generally this refers to either machine code or assembly language."

Re: C Is Not a Low-Level Language

#119
post #60

Earlier quoted context omitted.

On the flipside, doesn't it allow more or less direct memory access?

I mean, yes, no, it depends on what you mean? You can write to null in C, your operating system rejects it. You can write past your allocated memory, your OS rejects it. It's not like just because it's written in C it gets to read the kernel memory - it's just that you can try. All memory access in userspace is mediated by the MMU, so nothing in C gets "direct" memory access - but it does allow you to screw up your o…

That's my whole point. C doesn't try to stop you from doing that. C tries to do exactly what you ask it to, and if the OS doesn't allow it it just crashes.

To me that is about as low level as you can get without bypassing the OS.

Re: C Is Not a Low-Level Language

#120
post #104

Earlier quoted context omitted.

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 k…

It isn't at all similar. JVM bytecode is a pretty high-level IR for tokenized Java. The JVM's main unit of optimization is a method, not instructions. Its key component is a compiler, it's even called that. An x86 cpu, as the article points out, spends inordinate resources looking for ILP. It's not a compiler in any reasonable sense of the word, while a JVM is.

`javac` is a compiler. The JVM is an execution platform, just like modern x86.
Post reply on HN