Live data from Hacker News

C++ in the Linux Kernel

threatstack.com

91–100 of 102 posts

Re: C++ in the Linux Kernel

#91
post #66

Earlier quoted context omitted.

> The System V i386 ABI passes parameters through the stack. No. The C/C++ ABI is quite uniform across architectures. The first 1..N (N is ISA dependant) parameters that can fit into a CPU register are passed via registers. The first input parameter that _can't_ fit into a register (e.g. a structure passed by value) is pushed onto the stack, with every other following parameter being pushed onto the stack as well. N+…

> The C/C++ ABI is quite uniform across architectures. How can it be? What about an architecture without conventional registers? And for example I work on an implementation of C/C++ that logically uses the heap for its ABI.

Quite uniform != completely uniform.

Especially when it comes to C (less so C++), it is a remarkably adaptable language that has been able to attune to a variety of vastly incompatible hardware architectures, including stack based ones, heap based ones and some esoteric ones as well. Yet, in the case of conventional, register based ISA's, the ABI has been remarkably similar: nonwithstanding actual ISA specific register names, registers 0…N (apart from RISC ISA's where storing into/loading from the register 0 is a no-op / zero constant) are used as input parameters and register 0 (where available) is used as the function return value (provided it can fit in); otherwise the return result is returned via stack.

Re: C++ in the Linux Kernel

#92
post #91

Earlier quoted context omitted.

> The C/C++ ABI is quite uniform across architectures. How can it be? What about an architecture without conventional registers? And for example I work on an implementation of C/C++ that logically uses the heap for its ABI.

Quite uniform != completely uniform. Especially when it comes to C (less so C++), it is a remarkably adaptable language that has been able to attune to a variety of vastly incompatible hardware architectures, including stack based ones, heap based ones and some esoteric ones as well. Yet, in the case of conventional, register based ISA's, the ABI has been remarkably similar: nonwithstanding actual ISA specific regist…

> Quite uniform != completely uniform

Don't know if you're a non-native speaker, but no 'quite' usually does means 'completely'!

https://dictionary.cambridge.org/dictionary/english/quite

Re: C++ in the Linux Kernel

#93

a complete waste of time

If my boss told me to go write a Linux device driver in C++, I'd quietly go away and deliver a working device driver that happens to stick to the C subset of C++. Trying to fiddle about getting header files to include cleanly is a complete waste of time. (Maybe you're referring to something else like reading the article.) The benefits of C++ over C that is consistent and well-written in a disciplined manner is really not as great as many managers have been led to believe. And seeking forgiveness from an idiot manager is always easier than seeking permission to do things sanely.

Re: C++ in the Linux Kernel

#94
post #91

Earlier quoted context omitted.

Quite uniform != completely uniform. Especially when it comes to C (less so C++), it is a remarkably adaptable language that has been able to attune to a variety of vastly incompatible hardware architectures, including stack based ones, heap based ones and some esoteric ones as well. Yet, in the case of conventional, register based ISA's, the ABI has been remarkably similar: nonwithstanding actual ISA specific regist…

> Quite uniform != completely uniform Don't know if you're a non-native speaker, but no 'quite' usually does means 'completely'! https://dictionary.cambridge.org/dictionary/english/quite

Only when used with non-gradable adjectives/adverbs (from the same surce: https://dictionary.cambridge.org/grammar/british-grammar/qui... ) (and yes, uniform, is quite non-gradable)

(non-native speaker here, quite frustrated about the quite different meanings of 'quite')

Re: C++ in the Linux Kernel

#95

Earlier quoted context omitted.

> Quite uniform != completely uniform Don't know if you're a non-native speaker, but no 'quite' usually does means 'completely'! https://dictionary.cambridge.org/dictionary/english/quite

Only when used with non-gradable adjectives/adverbs (from the same surce: https://dictionary.cambridge.org/grammar/british-grammar/qui... ) (and yes, uniform, is quite non-gradable) (non-native speaker here, quite frustrated about the quite different meanings of 'quite')

'Quite dead' for example means completely dead.

Re: C++ in the Linux Kernel

#97

Earlier quoted context omitted.

Perhaps the article is old enough to have been written in the 32-bit era?

The Page Info I see says this: > article:published-time 2016-10-28T11:40:06+00:00 which is well into the era of 64-bit code.

People are still complaining about macOS dropping 32bit despite the last 32bit hardware having been dropped a decade ago.

Some people (especially game devs) are bizarrely obsessed with 32bit :-/

Re: C++ in the Linux Kernel

#98
post #89

Valueless Article. Please stop posting these sort of articles which have no information content. The article is merely a rant because the author doesn't have much of an idea of how C++ actually works. Merely knowing the syntax doesn't make one a "C++ programmer" and this is even more true when you are messing around in the Kernel. The article contains no specifics only general statements making me think this was put…

With all due to respect, your comment is an anti-specialization rant. > Merely knowing the syntax doesn't make one a "C++ programmer" Does knowing all the possible abstract layers (uh, it's an ocean) make one a C ++ programmer then? > this is even more true when you are messing around in the Kernel It's his right to mess around Kernel and learn things.

My comment has nothing to do with "anti-specialization" or "right to mess around" anything.

The article has zero substance with a generic rant being "i tried to use C++ to write a Kernel Module and ran into problems". There are no specifics w.r.t. C++ nor The Kernel and yet the author blames the C++ Language! Whatever is written up also betrays a certain ignorance of basic C/C++ ABI conventions leading one to surmise that the author is clueless (w.r.t. these two domains). As you can see from other comments in this thread, many others are also of the same opinion while others are guessing all over the map as to what the actual problem might be.

Re: C++ in the Linux Kernel

#99

Earlier quoted context omitted.

> that would be very weird on Linux. The x86_64 linux ABI mandates that the first arguments go on registers afaik (I'm assuming x86_64 here since the post mentions linux distros which are overwhelmingly x64). What compiler would default to a pure stack-based calling convention ? Certainly not GCC or clang, no ? The System V i386 ABI passes parameters through the stack. Perhaps that is what the author is referring to,…

In case it is talking about the x64 calling convention, there is actually some kind of an odd case where you would get something that looks like an argument was pushed on the stack: When a non-trivially-copyable object is passed by value to a function, you need to ensure that through the lifetime of the copy, it's address will never change because the constructor may have stored address of some of the field (for inst…

Too late to edit so I'll just write a message here: The hypothesis written above would not explain the author's complains as he mentions he was able to fix it with a compilation flag, whereas I doubt the compiler would change non-trivially-copyable being handled as reference to a copy since it would break correctness.

Re: C++ in the Linux Kernel

#100

Earlier quoted context omitted.

C++ or even C isn't exactly "fine" on any 8-bit system though. It's nice for a little demo, it can even be tolerable for some real-world projects when mixed with large amounts of inline assembly, but those 8-bit ISAs have been designed mainly for manual assembly coding, not high level compiled languages like C.

Honestly unless you’re on something like an ATtiny with As far as I’ve seen, two things make C and C++ specifically problematic on 8-bitters: automatic promotion to int for all expressions, with int required to be at least 16 bits (a language problem); and subpar codegen on accumulator architectures and other things that are not like desktops (a compiler problem).

Forth is much better for creating tiny executables than C on 8-bit ISAs though, performance takes a hit because of all the calls/jmps, but it's still surprisingly good. C compilers on the other hand often create "obviously" dumb and inefficient code, at least in my experience (6502 may be better than Z80 in that regard though).
Post reply on HN