Live data from Hacker News

Who Says C is Simple? (2010)

eecs.berkeley.edu

21–30 of 59 posts

Re: Who Says C is Simple? (2010)

#21
post #19

Who says simple things always yield simple results?

Depends on how you define simple:

If something is simple for the compiler-writer, then simple things do yield simple results.

If something is simple for the programmer, simple things often yield quite complex results.

For example, in a language that's simple for the compiler-writer, (1/10) times 10 is only very rarely 1. 0 is a common answer, as is some fraction which is almost, but not completely, unlike 1.

In a language which is simple for the programmer, Heaven, Earth, and minor deities will be moved to make (1/10) times 10 come out to the obvious, simple answer.

Re: Who Says C is Simple? (2010)

#22
post #21
post #19

Who says simple things always yield simple results?

Depends on how you define simple: If something is simple for the compiler-writer, then simple things do yield simple results. If something is simple for the programmer, simple things often yield quite complex results. For example, in a language that's simple for the compiler-writer, (1/10) times 10 is only very rarely 1. 0 is a common answer, as is some fraction which is almost, but not completely, unlike 1. In a lan…

It really only depends on if you define simple as "can only derive simple results."

And, you do realize that one of the simplest languages for compiler writers, lisp, doesn't have to move heaven/earth to make that calculation work out how you want it.

Re: Who Says C is Simple? (2010)

#23
post #4
post #2

Can anybody figure out the year on this one? Internet Archive says 2011 but it seems it might be earlier.

This URL http://www.eecs.berkeley.edu/~necula/cil/cil002.html#toc1 mentions cil version 1.3.7. Changelog http://www.eecs.berkeley.edu/~necula/cil/changes.html says 1.3.7 was released on 2009-04-24.

But 2010 may just have been when they stopped updating a version number. It looks like early 2000s material to me, based on nothing in particular. There's also this:

When I (George) started to write CIL I thought it was going to take two weeks. Exactly a year has passed since then and I am still fixing bugs in it

The CIL paper was published in 2002. Actually the whole project looks interesting—arguably more so than the currently posted page. It should have its own HN thread sometime. https://news.ycombinator.com/item?id=836735 was a while ago!

Re: Who Says C is Simple? (2010)

#24
post #3
post #2

Can anybody figure out the year on this one? Internet Archive says 2011 but it seems it might be earlier.

The HTTP headers can put an upper bound on the date: Last-Modified: Fri, 29 Oct 2010 16:59:15 GMT And the changelog for CIL suggests that it may be significantly older: http://www.eecs.berkeley.edu/~necula/cil/changes.html

That header trick is a good one.

Ok, we'll put 2010 on it even though it is likely quite a bit older. An upper bound is better than nothing.

Re: Who Says C is Simple? (2010)

#25
post #15

Earlier quoted context omitted.

The first invokes UB if you assume that x is a local variable, and the second doesn't at all as far as I can tell. Care to explain? To elaborate, the second expression has an underflow at 1 - sizeof(int) on an unsigned integer (promotion due to sizeof being unsigned), which is perfectly well defined: "if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum val…

The behavior is only well defined if the shift amount is strictly less than the width of the operand. If `size_t` is 32 bits, then shifting right by 32 bits is undefined. I know of three different ways in which platforms implement shifts by greater than the word size.

Yep, you're right. I knew left shift for signed/unsigned as it is more complicated and I've had to look it up more often, but I forgot that right shift can be UB for unsigned integral types as well.

Re: Who Says C is Simple? (2010)

#26
post #11
post #5

The first two invoke UB and are thus completely illogical.

No they don't. What UB do you think they invoke? They do invoke implementation defined behaviour, but not undefined.

An uninitialized variable is UB, not implementation-defined. Thus, the compiler is free to treat the variable as though it doesn't have a value at all, or change it's value at will. It's not uncommon for the value of an uninitalized variable to change at strange places in the code that you wouldn't expect, because the compiler initially said "Variable x will be kept in register %eax", but then without a value to initialize it too, it just uses whatever happens to be in %eax at the time. For example, if they compiled this:

    return x == (1 && x);
Into this:

    movl $0, %eax
    andl $1, %eax
    cmpl %eax, %eax
    # Result in %eax
That will (obviously) return 1 every time, because we compare %eax and %eax. The reason for this is that the value of 'x' changes half-way through the computation (Because the computation is done in %eax, which is where 'x' is assumed to be). This is valid because 'x' is uninitalized, so it doesn't have a defined value.

Re: Who Says C is Simple? (2010)

#27

who said C is simple? :S

A lot of people have said it. They develop a mental model that is a rough approximation of its semantics, see that their mental model is simple and conclude that the semantics itself must also be simple. Then other people write articles like these to remind the first group that their "simple" mental model is not the actual semantics, just an approximation.

Re: Who Says C is Simple? (2010)

#29
post #20

C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.) That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code;…

But everything that came after C hasn't improved on this, at all. In fact, languages now dominate that aren't compiled.

So as it stands, C is still your best bet when you are looking for that optimal translation. Intel has recently made some effort to augment it in ways to fully utilize new CPUs various parallel pipelines and specific functionality:

https://ispc.github.io/

Re: Who Says C is Simple? (2010)

#30
post #4
post #2

Can anybody figure out the year on this one? Internet Archive says 2011 but it seems it might be earlier.

This URL http://www.eecs.berkeley.edu/~necula/cil/cil002.html#toc1 mentions cil version 1.3.7. Changelog http://www.eecs.berkeley.edu/~necula/cil/changes.html says 1.3.7 was released on 2009-04-24.

FYI the project is still active, https://github.com/cil-project/cil

That website for it hasn't been updated.

Post reply on HN