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

Carbon’s most exciting feature is its calling convention

foonathan.net

Post reply on HN
Print view View original

41–50 of 223 posts

Re: Carbon’s most exciting feature is its calling convention

#41

Post by staticassertion »

olliej wrote: post #33
usrnm wrote: post #14

Earlier quoted context omitted.

Some of the biggest problems with C++ come from its backwards compatibility with C. Yes, it wins you users in the short term, but it's a pain to support as both languages evolve

The binary compatibility is the big deal. The other safe languages have explicitly taken the view the interop with C++ is bad, and so we should instead do interop with the significantly less safe C instead. The real killer is that the lack of any interaction with C++ means that you can’t do any real incremental adoption of one of those safe languages in any big security critical projects. Saying that the solution to…

> The other safe languages have explicitly taken the view the interop with C++ is bad

I think it's more that interop with C++ is hard and ultimately a lot less valuable than interop with C, which is what the vast majority of languages use for FFI.

> It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface.

I don't see how that leads to "it doesn't matter"

Re: Carbon’s most exciting feature is its calling convention

#42

Post by josephcsible »

temac wrote: post #40
olliej wrote: post #30

Earlier quoted context omitted.

I think the alias analysis “pro” is overblown, it’s UB to take the address of a parameter via any mechanism other than explicitly taking the address - which a compiler obviously sees, and because it’s UB the compiler optimizes is free to assume no one is taking the address. Then for any parameters that are passed by reference the compiler has to assume there are other references so there’s no gain. Honestly the only…

> it’s UB to take the address of a parameter via any mechanism other than explicitly taking the address - which a compiler obviously sees, and because it’s UB the compiler optimizes is free to assume no one is taking the address. I don't get that: can you express in C++ a code that "take the address of a parameter via any mechanism other than explicitly taking the address"?

Consider this C code (also "works" if compiled as C++):

    int main(void) {
        int x = 0;
        int arr[1];
        int *p = arr + 1;
        *p = 42;
        return x;
    }
On a lot of systems (e.g., https://godbolt.org/z/jYqM8TT3Y), it just so happens that `x` is right above `arr` on the stack, so that code will return 42. But that code is absolutely UB.

The more general name for this concept is "pointer provenance". Basically, you can't pull pointer values out of thin air; you have to derive them from operations rooted at taking the address of something within the same allocation.

Re: Carbon’s most exciting feature is its calling convention

#43

Post by [deleted] »

olliej wrote: post #30
Denvercoder9 wrote: post #15

Maybe I'm missing something, but I don't see what's special about Carbon here. In C++ the compiler can also optimize pass-by-const-reference to pass-by-value, and they do. It just can't do it across an ABI boundary, but that should only be an issue with dynamic libraries, and Carbon has to follow the standard ABI there as well. Just make sure the compiler knows it doesn't have to follow the standard ABI for every sym…

I think the alias analysis “pro” is overblown, it’s UB to take the address of a parameter via any mechanism other than explicitly taking the address - which a compiler obviously sees, and because it’s UB the compiler optimizes is free to assume no one is taking the address. Then for any parameters that are passed by reference the compiler has to assume there are other references so there’s no gain. Honestly the only…

[deleted]

Re: Carbon’s most exciting feature is its calling convention

#44

Post by ISL »

I'm sure the ship has sailed on Carbon's naming convention, but darn if that isn't a confusing article-title.

It is interesting to contemplate the most-ambiguous and least-comprehensible/googleable name one might be able to give to a piece of software. "the"? "Biden"? "Russia"? "water"? "air"? "dog"? "person"? "!"? "?"? " "?

Re: Carbon’s most exciting feature is its calling convention

#45

Post by comex »

Denvercoder9 wrote: post #15

Maybe I'm missing something, but I don't see what's special about Carbon here. In C++ the compiler can also optimize pass-by-const-reference to pass-by-value, and they do. It just can't do it across an ABI boundary, but that should only be an issue with dynamic libraries, and Carbon has to follow the standard ABI there as well. Just make sure the compiler knows it doesn't have to follow the standard ABI for every sym…

That optimization is quite fragile.

For example, try putting `puts("hello");` at the beginning of `add`. Now neither GCC nor Clang performs the optimization. Why? Because `puts` could theoretically modify the value behind the reference, so the value loaded is not necessarily the same as the value at the beginning of the function, which makes things more complicated, so both compilers give up.

As another example, GCC and Clang both perform the optimization within a translation unit, but if the function definition and the call are in different translation units, GCC doesn't perform the optimization even with LTO, and Clang doesn't perform it with ThinLTO (but does perform it with full LTO). Meanwhile, many projects don't compile with any form of LTO, which is a reasonable decision to improve compilation speed and predictability.

Neither compiler is smart enough to perform the optimization for virtual calls in almost any situation.

Re: Carbon’s most exciting feature is its calling convention

#46

Post by labrador »

ISL wrote: post #44

I'm sure the ship has sailed on Carbon's naming convention, but darn if that isn't a confusing article-title. It is interesting to contemplate the most-ambiguous and least-comprehensible/googleable name one might be able to give to a piece of software. "the"? "Biden"? "Russia"? "water"? "air"? "dog"? "person"? "!"? "?"? " "?

Google engineers: "Let's make our languages hard to Google!"

Google managers: "Whatever floats your boat. How about Go, Dart and Carbon?"

Re: Carbon’s most exciting feature is its calling convention

#47

Post by [deleted] »

bbkane wrote: post #6

I really think the most exciting feature of Carbon (indeed, it's justification for existence) is its backwards compatibility with C++, followed closely by it's more modern and flexible governance structure. Even the docs in the repo say you should avoid Carbon unless you have lots of C++ code you need to interact with.

[deleted]

Re: Carbon’s most exciting feature is its calling convention

#48

Post by phire »

Denvercoder9 wrote: post #15

Maybe I'm missing something, but I don't see what's special about Carbon here. In C++ the compiler can also optimize pass-by-const-reference to pass-by-value, and they do. It just can't do it across an ABI boundary, but that should only be an issue with dynamic libraries, and Carbon has to follow the standard ABI there as well. Just make sure the compiler knows it doesn't have to follow the standard ABI for every sym…

I have been burned many times in the past by "the compiler is allowed to optimise something away".

You write your code assuming such an optimisation will happen, and for some reason, the compiler decides not to apply the optimisation. Perhaps the wind was blowing in the wrong direction, or it was in a bad mood, or you forgot to specify -fvisiblitly=hidden.

The exciting part here is that it happens by default, and the compiler is required to do it. I don't have to think about it, and the ABI automatically does the thing best for performance.

Re: Carbon’s most exciting feature is its calling convention

#49

Post by moralestapia »

bardworx wrote: post #26
moralestapia wrote: post #21

Earlier quoted context omitted.

It's Google but yes, another instance of Embrace, Extend and Extinguish . I hope this doesn't take off, with my sincere apologies to the ones who have been working hard on this. The last thing the C/C++ ecosystem needs is becoming de facto owned by a private company.

Sorry, not in the ecosystem (clearly). Why not? Just curious.

No problem, here's some context, https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

Re: Carbon’s most exciting feature is its calling convention

#50

Post by labrador »

moralestapia wrote: post #21
bardworx wrote: post #17

Earlier quoted context omitted.

Microsoft. - don’t listen to me, it’s Google.

It's Google but yes, another instance of Embrace, Extend and Extinguish . I hope this doesn't take off, with my sincere apologies to the ones who have been working hard on this. The last thing the C/C++ ecosystem needs is becoming de facto owned by a private company.

I prefer a fast evolution when necessary to a slow committee process. I don't see any drawbacks, unless your the type that prefers to build consensus before moving forward
Post reply on HN