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

PLOS2021: ISO-C became unusable for operating systems

yodaiken.com

Post reply on HN
Print view View original

41–50 of 100 posts

Re: PLOS2021: ISO-C became unusable for operating systems

#41

Post by yjftsjthsd-h »

MobiusHorizons wrote: post #22
po1nt wrote: post #4

I think it's about time to abandon C language entirely.

I'm curious what you would replace it with? I can't think of anything actually suitable for most of the low-level operating systems / embedded level things that use C. I know people recommend rust for this kind of thing, but Rust really isn't appropriate in a lot of cases, especially when dealing with microcontrollers not supported by llvm (ie PIC, 8051 off the top of my head). This may be changing, but I was also un…

I'd nominate Pascal (which has been used for OS dev before) and Ada. Not 100% sure how broad their support is for different hardware, but it also seems like adding new platforms to an existing toolchain is less work than inventing a new language while still benefiting from being not-C.

Re: PLOS2021: ISO-C became unusable for operating systems

#42

Post by ncmncm »

not2b wrote: post #28
bombcar wrote: post #13

Earlier quoted context omitted.

It is possible - but not whilst maintaining standards-compliance and there are always/often another one where you least expect it. At the root is taking a “assume the programmers know what they are doing” language and turning it into a “assume the programmers are drooling morons” language.

I think it's the opposite: compiler writers under pressure to produce fast code assume that the programmers are smart, not morons, and that they understand the rather complex rules. For example: the compiler is assuming someone isn't ignorant and knows, for example, if they want to write a variable as one type and read it as another, they need to consider two things: they are now in implementation-dependent territory…

Amusingly, unions are also defined so that operations that pun types are undefined. Gcc has private extensions that provide a way to pun types in unions, but those are not portable.

Specifically: if you have a union with members a and b, and you assign into member a, then reading from member b afterward is, by the C and C++ Standards, usually undefined. You are presumed to have some way to know that member a is live, and use that. You can then write into b, and later read that back out.

Re: PLOS2021: ISO-C became unusable for operating systems

#43

Post by vyodaiken »

pcwalton wrote: post #37
Asooka wrote: post #35

Earlier quoted context omitted.

C was always a high-level assembler. UB was meant to be "this cannot be defined portably, refer to your CPU's documentation". What do you gain by making C unusable by default? Just make it 5% slower by default, but possible to reason about and give people the option to shoot themselves in the foot. I don't know what more you need than the creator of the language telling you "this is not possible to implement sanely".

Even assuming the 5% number were correct (depending on how expansive your definition of UB is, it may not be), asking everyone who doesn't adjust their compiler flags to accept a 5% slowdown for some theoretical benefits is at odds with economic reality.

Maybe you should tell the Linux developers that they are making a mistake.

Re: PLOS2021: ISO-C became unusable for operating systems

#44

Post by pcwalton »

astrange wrote: post #40
pcwalton wrote: post #27

In general I've long been very skeptical of removing optimizations that rely on undefined behavior. People say "I'd happily sacrifice 1% for better theoretical semantics", but theoretical semantics don't pay the bills of compiler writers. Instead, compiler developers are employed by the largest companies, where a 1% win is massive amounts of dollars saved. Any complaint about undefined behavior in C must acknowledge…

> If you want to blame someone, blame the designers of the C language for doing things like making int the natural idiom to iterate over arrays even when size_t would be better. The fact that C programmers continue to write "for (int i = 0; i Well, size_t is unsigned and has defined overflow, so you'd lose the optimization if you switched to it. (Specifically, there's cases where defining overflow means a loop is pos…

The optimization I'm referring to is widening a 32-bit loop IV to 64-bit so it can stay in a register: https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...

size_t obviates the need for this optimization.

Re: PLOS2021: ISO-C became unusable for operating systems

#45

Post by ncmncm »

aw1621107 wrote: post #16
pdw wrote: post #11

How much of this is driven by modern C++ style? I always assumed optimizers needed to become much more aggressive because template-heavy code results in convoluted IR with tons of unreachable code. And UB-based reasoning is the most effective tool to prove unreachability.

> template-heavy code results in convoluted IR with tons of unreachable code Does it? Honest question; my impression was that template-heavy code can tend to produce deep call trees, but not necessarily outright unreachable code unless you count instantiations ruled out by SFINAE/std::enable_if/tag dispatching, for which UB-based analyses are not necessary. In addition, I thought template (meta)programming relied ver…

It is quite common for any heavily inlined code to have lots of dead sections. Template code is very frequently heavily inlined. So, it is common for compilers to prune out the dead branches.

But C code is often heavily inlined, too, and similarly pruned.

Re: PLOS2021: ISO-C became unusable for operating systems

#46

Post by vyodaiken »

astrange wrote: post #30

This is a typical whining about UB article, but removing it won't get what you want, in particular your program still won't behave correctly across architectures. Overflow on shift left may be undefined, but how do you want to define it? If you want a "high level assembler", well, the underlying instructions behave differently on ARM, x86 scalar, and x86 SIMD. The reason they claim program optimizations aren't import…

Nobody claims optimizations are not important.

Re: PLOS2021: ISO-C became unusable for operating systems

#47

Post by ncmncm »

Asooka wrote: post #31
mhh__ wrote: post #15

Earlier quoted context omitted.

If a warning is issued in that case I'm tempted to say it's fair game. If you are sure it'd safe the compiler has extremely well established ways of telling it (i.e. assume or unreachable)

I wouldn't call it fair game, not least because nobody reads warnings. My central objection is that it's not what C is meant to be. C was made to write Unix, it was specifically created to be halfway between a portable macro assembler and a high-level language. That is a useful language that fills a particular niche. That is what C was for many years and a lot of code was written with that behaviour in mind. It can b…

There is probably more than a million times as much C code that is not Unix as code that is. We could chuck in all the other OSes, and all the RTOSes besides, without changing the statement.

Re: PLOS2021: ISO-C became unusable for operating systems

#48

Post by vyodaiken »

userbinator wrote: post #36
pcwalton wrote: post #27

In general I've long been very skeptical of removing optimizations that rely on undefined behavior. People say "I'd happily sacrifice 1% for better theoretical semantics", but theoretical semantics don't pay the bills of compiler writers. Instead, compiler developers are employed by the largest companies, where a 1% win is massive amounts of dollars saved. Any complaint about undefined behavior in C must acknowledge…

The reason why GCC and LLVM ended up attaining overwhelming market is simply that they produce the fastest possible code No, I think it's more because they are free. In my experience, ICC can be much better at instruction selection while also not being so crazy with exploiting UB.

It is because they are "free" and also because they attract massive investment from FAANG and National Labs etc.

Re: PLOS2021: ISO-C became unusable for operating systems

#49

Post by cozzyd »

astrange wrote: post #32
Asooka wrote: post #29

Earlier quoted context omitted.

It was many months ago and I no longer remember the full details, plus it's proprietary code, so I can't tell them to you. But the gist was that after optimisation, some floating point arithmetic was done in different order by different compilers. This particular expression really needed to be computed in exact order and, since nothing else worked, we had to just write it in compiler-specific assembly. IIRC some lang…

That's a compiler bug. Floating-point math shouldn't be reassociated unless you were using -ffast-math, which is indeed a poorly named option that does bad things, but one many people demand.

I think icc might be more cavalier about this sort of thing.

Re: PLOS2021: ISO-C became unusable for operating systems

#50

Post by ncmncm »

MobiusHorizons wrote: post #17
jjtheblunt wrote: post #12

Earlier quoted context omitted.

UB = Undefined Behavior ?

correct. In my experience a focus on UB (often actually said U.B.) tends to come from the C++ community, although a lot of it trickles down to the C community as well. I can recommend watching a few talks from C++ conferences. I especially enjoyed ones by Matt Godbolt, and Miro Knejp.

Not correct. Most UB is the same in C and C++. If you disallowed optimizations based on UB, it might have more effect on C++ programs, just because C++ tends to more deeply inlined abstractions that can benefit more from them. But those don't tend to need much attention. The cases people worry about are more common in C code, just because the concept of type is less important in C.
Post reply on HN