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

101–110 of 326 posts

Re: C Is Not a Low-Level Language

#101

Post by mkirklions »

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…

Its crazy that C has changed because of the way people used it.

Well crazy isnt the correct word... mainstream use has changed the future of an old language...

Re: C Is Not a Low-Level Language

#102

Post by wglb »

The article does not properly distinguish between C as a language and what the C compiler does with the C program. The logic of the article references what the compiler does.

The reasonable way to measure languages is to look at the abstractions present in the language. C has fewer abstractions than the other languages that we are familiar with. That is the reasonable definition of the level of a language.

Re: C Is Not a Low-Level Language

#103

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

#104

Post by pvg »

admax88q wrote: post #96
pvg wrote: post #85

Earlier quoted context omitted.

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 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.

Re: C Is Not a Low-Level Language

#105

Post by jstimpfle »

munificent wrote: post #93

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

> cost of cache misses

How is the C memory model a leaky abstraction here? What better way do you suggest? Are we not fine coding sequential (in memory) datastructures in C?

Re: C Is Not a Low-Level Language

#106

Post by fixermark »

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…

x86 is also there on modern architectures to supply an abstraction that is increasingly divergent from the actual die hardware (but compatible with expectations of e.g. a C compiler that already has an output target for previous x86 hardware).

Modern Intel CPUs basically emulate x86; there are many layers of abstraction between individual opcodes and transistor switching.

Re: C Is Not a Low-Level Language

#108

Post by kwillets »

waynecochran wrote: post #15

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.

    unsigned char r(unsigned char num) {
        return num % 10;
    }
https://godbolt.org/g/26HfQk

Re: C Is Not a Low-Level Language

#109

Post by fixermark »

mikepurvis wrote: post #84
admax88q wrote: post #58

Earlier quoted context omitted.

> 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.

The JVM provides native primitives around memory and thread management which are not present in x86, but that's a matter of degree.

x86 provides all sorts of memory abstractions. The whole memory segmentation model is an abstraction. https://en.wikipedia.org/wiki/X86_memory_segmentation

Re: C Is Not a Low-Level Language

#110

Post by PeterisP »

jackhack wrote: post #9
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…

Thanks for the TLDR. But if that's the argument, then not even assembly is sufficient, as control over speculative branching and prefetch is only accessible via microcode in the CPU. I think the argument is improperly framed. This is a discussion over public and private interface. The CPU is treated as a black box with a public interface (the x86+ instruction set). Precisely how those instructions are implemented (on…

The argument implied in the article is that choosing a different public interface (breaking "C compatibility" and the imposted limitations) could bring a serious performance improvement.

While precisely how those instructions are implemented (on chip microcode) is a private matter for the chip design team, we do care how much resources it takes to implement these instructions, since if we can enable a more efficient implementation then we can get better price/performance.

Post reply on HN