Linked by pmac on Tue 22nd May 2018 09:47 UTC
General Development

In the wake of the recent Meltdown and Spectre vulnerabilities, it's worth spending some time looking at root causes. Both of these vulnerabilities involved processors speculatively executing instructions past some kind of access check and allowing the attacker to observe the results via a side channel. The features that led to these vulnerabilities, along with several others, were added to let C programmers continue to believe they were programming in a low-level language, when this hasn't been the case for decades.

Processor vendors are not alone in this. Those of us working on C/C++ compilers have also participated.

Thread beginning with comment 657146
To read all comments associated with this story, please click here.
Not a very good article.
by grat on Tue 22nd May 2018 15:00 UTC
grat
Member since:
2006-02-02

First, the article essentially says that there are no low level languages for x86, including assembly.

Unfortunately, this is because the author insists on defining a "low level language" as one that doesn't abstract out the hardware.

In 40 years, I have yet to encounter a language more advanced than Assembly that meets this criteria.

In fact, let's called "Assembly Language", that is, a language made of mnemonic op codes specific to a processor, "A".

Side note: An op code called "CMP" to compare two values, is not a low level operation by Chisnall's definition-- the operations performed by the CPU to do that comparison are themselves "hidden" from the programmer.

Let's imagine for a moment, a language slightly more advanced than "A", which supports pseudo-code-- a standardized way of implementing "CMP", or "CP" or "JMP"-- Perhaps "if" or "copy" or "goto". We might, for the sake of argument, call this "B".

While it's a useful language, in that we don't need to remember op codes specific to each processor, or know a system's memory map, or register set, it's not really a full blown language, so it never came to exist.

Now let's take that pseudo-code language "B", and add structure, data types, functions, maybe a standard IO library. We might call that "C".

And that's what C is-- About as close as you can get to programming on any given CPU without knowing exactly how that CPU operates. It should be considered the lowest level of a fully abstracted programming language available. As such, it became insanely popular because it was faster than BASIC or Pascal, or Fortran or Cobol, because it let you get as close as possible to the guts of the system, without having to write code for that specific system.

It's a high performance language that requires some care -- If you malloc(), don't forget to free(), and don't exit your subroutine before reclaiming resources.

So-- reality is that C was never what Chisnall claims some people think it is. It doesn't meet his definition of a low level language. It is, however, about as low level as most sane programmers want to get.

As for claiming that Spectre and Meltdown are all the fault of people writing C code, that's just specious. From a security point of view, that sort of speculative branch prediction was badly designed to start with, and doesn't play nice with today's multi-threaded systems. Many manufacturers have spent the last two decades emphasizing speed over security, and Intel, Microsoft, AMD and others are all guilty.

Personally, having experienced low level programming on Z80 and 6502 Assembly language, and knowing how completely incompatible the two systems were, I'm left somewhat baffled by his article-- does he want to go back to the days where you coded for specific hardware?

No, he can't be that daft. Perhaps, instead, this is really an article about how convoluted x86 has become, and how we need better CPU architectures-- and that seems to be a point near the end of the article, although ARM has similar speculative goofs in their design (although not as prevalent).

All in all, this seems to be a "x86 sucks because of C" article, and that's such a gross oversimplification that I have difficulty taking him seriously.

Reply Score: 4

RE: Not a very good article.
by acobar on Tue 22nd May 2018 21:05 in reply to "Not a very good article."
acobar Member since:
2005-11-15

Could not agree more. The whole thing is so deranged and the arguments are so stretched that there is no way to take them seriously.

Out of order and speculative execution came to exist because access to any memory outside the processor is slow and as so we needed a way to keep the cpu busy. It has nothing to do with 'C'.

Also, he seems to believe that parallelism is something easy and, somehow, 'C' is a kind of block for it. WTF, most applications have no need or would be actually badly affected by parallelism inside them. Where there is good opportunity to parallelism and it is, relatively, easy to be put on use it already is, i.e., by OS multitasking, asynchronous IO and some math algorithms.

The only thing about right is that modern processors are not super-fast PDP-11.

Reply Parent Score: 3