C++: “model of the hardware” vs “model of the compiler”

 
Author:  Follow: TwitterFacebook
Job Title:Sarcastic Architect
Hobbies:Thinking Aloud, Arguing with Managers, Annoying HRs,
Calling a Spade a Spade, Keeping Tongue in Cheek
 
 

Recently, I have run into [P1063R0], and was literally stunned with a way those guys (mis)interpret certain fundamental aspects of C++ philosophy. By today, I found what I don’t like about their position – and am able to articulate it, so here it goes.

Disclaimer: THIS POST IS SPECIFICALLY ABOUT C++; other programming languages MAY BE (and most ARE) different in this regard.

Disclaimer #2: unfortunately, [P1063R0] is very vague about justifying some of its claims – so I had to make quite significant leaps to connect the dots. If any of the authors of [P1063R0] is ready to provide alternative justification of their wording mentioned below – I will be happy to amend this post to reflect it (however, I cannot guarantee that amended post will be any more favorable to the “model of compiler” or to P1063R0).

P1063R0 and “model of the hardware” becoming “model of the compiler”

In the very beginning [P1063R0], the logic goes as follows:

  • first, they’re quoting Bjarne: “C++ is a general-purpose programming language providing a direct and efficient model of hardware combined with facilities for defining lightweight and efficient abstractions.” No problem here – in fact, I am a big fan of this concept.
  • Wtf hare:We suggest as a friendly amendment that the quote should say “a direct and efficient model of the platform”but then, the authors of [P1063R0] suggest a “friendly amendment” to this quote: “We suggest as a friendly amendment that the quote should say “a direct and efficient model of the platform”. For example, C++ templates provide a direct and efficient map of the compiler’s code generation facilities, rather than of any hardware feature”. This is where the problem starts; actually, following their logic, original Bjarne’s quote becomes diluted, transitioning from original “model of the hardware” via conspicuously-vague (and IMO weasely) “model of the platform”, and in fact into a “model of the compiler”.
  • and then, [P1063R0] implies that their approach (which is BTW a special case of lambdas) is a better “direct and efficient model of hardware” than Coroutines TS; while P1063R0 isn’t clear on why they’re better in this regard, it seems that the implication goes because their approach exposes more of compiler+library internals (“model of platform” in P1063-speak) to the end-programmer.

At this point, I don’t want to start arguing about [P1063R0]-vs-Coroutines-TS, but rather want to emphasize that

While I 100% agree with the original Bjarne’s quote, I 100% disagree with ‘model of the hardware’ becoming ‘model of the compiler’

NB: I have to say that I have no idea what does Bjarne thinks about it (and sure, it would be nice to hear from him on this kind of ‘friendly amendment’ to his quote), so I cannot tell whether they’re misusing Bjarne’s quote or not; however, I am clearly entitled to agree or to disagree with (a) original quote, and (b) its modified form.

What’s So Different Between ‘Model of the Hardware’ and ‘Model of the Compiler’?

On the first glance, it might look strange that I am so picky about the difference between ‘model of the hardware’ and ‘model of the compiler’. However, there is a fundamental difference between the two, which IMNSHO MUST NOT be ignored.

Let’s take a look at the programming language (with its compiler) from a 50’000-feet point of view. What is the programming language doing for us? The answer is simple: from a 50’000-feet point of view,

Programming language translates a program expressed in terms of humans, into the same program expressed in terms of hardware

That’s it – no more and no less; in other words, programming language has TWO AND ONLY TWO interfaces – one with human programmers, and another with hardware, that’s it.

Judging hare:we MUST NOT care about compiler internals beyond our task definition (which is based on (a) humans, and (b) hardware, that's it). But it also means that a proper business-level definition of any programming language MAY refer to humans (who are on the one side of the translation), and MAY refer to hardware (which is on the other side) – but MUST NOT refer to anything else! It is a classical case of everything-else-being-an-implementation-detail – and we MUST NOT try to overspecify this everything-else (at least to keep implementation options open). In classical business analysis, if we have a business-level task which defines what we have to do, it is dead wrong to specify how we should do it; in [DDMoG] a few examples of improper business requirements are considered – such as “we should use TCP for our project” – and it is shown that such a (mis)specification is a Bad Thing(tm). Exactly the same applies to programming language and compiler: we MUST NOT care about compiler internals beyond our task definition (which is based on (a) humans, and (b) hardware, that’s it). 

As I understand it (and as always when trying to interpret somebody’s else intention, I can be wrong), the whole point of the original Bjarne’s quote is that C++, unlike many of the other programming languages, cares NOT ONLY about being easy-to-use by human beings, but also about being efficiently mapped into the hardware. Let’s note that those many-other-languages are still within their rights to ignore hardware while staying faithful to the proper business-level definition of their task (that is, until an interpreter/compiler becomes a de-facto standard which dictates the language – which did happen to a language or three and IMNSHO did contribute to demise of such languages).

Oh, and BTW, the argument from P1063R0 (“templates provide a direct and efficient map of the compiler’s code generation facilities, rather than of any hardware feature”) doesn’t justify introducing compiler into the picture. From my point of view, templates can (and IMNSHO SHOULD) be seen not as a “map of the compiler’s code generation facilities”, but, for example, as “a much better way to express stuff previously-expressed-with-macros”, or “a way to express generalized algorithms”, etc. etc. – all of which can be expressed in terms of source code, which in turn is already in the picture as a way for humans to express themselves. In other words – if not for human programmers having a need to simplify their lives (or to be able to express more complicated things) – templates won’t be there (and BTW, it took compiler writers about 10 years to implement templates properly); ergo, templates are there NOT because of the need “to map compiler’s code generation facilities”, but because of perfectly legitimate business needs which can be expressed in terms of valid interfaces of the programming language.

Why so Much Fuss About It?

This whole thing might look trivial – or obvious, and the next logical question is “hey, why you’re paying so much attention to this minor issue?”

Hare with hopeless face:My problem with introducing a 'model of the compiler' into the picture, is that it can be used to justify pretty much anything without any relation to real-world requirements.My problem with introducing a “model of the compiler” into the picture, is that it can be used to justify pretty much anything without any relation to real-world requirements. In terms of maths, it can be used as a kind of “false implies true”, or “on an empty set pretty much any statement is true” statements – which are technically correct statements, but at the same time are perfectly useless and often utterly misleading.

And IMSNHO, this is exactly what has happened in [P1063R0]: starting from this IMNSHO-fallacy about “model of the compiler” being important, they got to an implication that overspecifying things in the programming language (which exposes more of “model of the compiler” to the end-programmer) is inherently better than underspecifying them. This, in turn, is an extremely dangerous statement – which BTW IMNSHO contradicts to another Bjarne’s writing, [P0976].

But the problem I see with introducing implementation details of the compiler into the philosophy is much more general than that – it can be used to justify pretty much anything, and IMNSHO that’s where the real danger to the language lies.

Dixi.

Don't like this post? Comment↯ below. You do?! Please share: ...on LinkedIn...on Reddit...on Twitter...on Facebook

[+]References

Acknowledgement

Cartoons by Sergey GordeevIRL from Gordeev Animation Graphics, Prague.

 

Join our mailing list:

Comments

  1. Gnate says

    Neither are true. There is no reason to believe that compiled code can only run on real hardware. In fact, browser(s) try to bring C support. Yes, the browser is technically running on hardware, but more precisely it is running in a constrained environment. In this case it is neither hardware nor platform but rather a new environment.

    And there is no reason to believe that the final compiled code is in assembly. Use LLVM and you can change it to byte code.

    I think this amendment is about expanding scope and to change how people think of programming. Then again, I’ve never heard this quote until today.

    • "No Bugs" Hare says

      The whole post is entirely about C++ (I will make it more clear); and as the first quote is coming from The Creator of C++, it is true more or less by definition (arguing with Bjarne on the philosophy of C++ would be too much even for me 😉 ). The point is that C++ is designed specifically to aim for the hardware (while tons of other languages aren’t).

      > In fact, browser(s) try to bring C support.

      More precisely, what browsers are doing is supporting asm.js or wasm (and then it is a job of the C++ compiler such as emscripten to compile into them). However, it is worth noting that both asm.js and wasm are effectively emulating the very same typical hardware architecture with registers and RAM etc. etc., so the philosophy of C++ (and C++ compiler for that matter) doesn’t change at all.

      > Then again, I’ve never heard this quote until today.

      It just means that you’re not programming in C++ long enough 😉 . C++ _is_ a language built to be close to hardware – and this is one of its Big Strengths(tm) (and has interesting side effects too: for example, NVidia is currently building their chips with C++ standard in mind).

      • Benjamin says

        I think designing a chip around a language is a mistake. Sure, you’re making one or two languages run faster, at the price of potentially slowing down others. It also restricts what low level languages will look like: C and C++. IMO, chip designers should make their chips work best without a specific language and compiler programmers should make the language map most efficiently.

        • "No Bugs" Hare says

          > IMO, chip designers should make their chips work best without a specific language and compiler programmers should make the language map most efficiently.

          I see your point, but this is at least arguable. In the modern highly dynamic world, a chip without a really good compiler won’t really stand a chance, so this kind of inter-relations is pretty much inevitable from the business perspective.

          More importantly, as I am not NVidia and cannot really affect them, I have to take their decisions for granted.

          > at the price of potentially slowing down others.

          Just for the sake of argument/trolling one could say “as other languages don’t really care about performance, it is not a big deal” ;-).

      • Curtis says

        Targeting a VM you are targeting virtual hardware so that makes sense. Also what if you target a chip with no OS like a Pic or an Arduino. If you don’t have an OS is that even a platform.

  2. Curtis says

    You know if you target a VM you are targeting virtual hardware. Also what if you target a chip like an Arduino is that really a platform I mean there is no OS.

    • "No Bugs" Hare says

      > You know if you target a VM you are targeting virtual hardware.

      Sure, but… I don’t know of a single non-research VM which simulates a non-existing CPU (or non-existing hardware for that matter), so targeting real hardware is more or less equivalent to targeting virtualized one (and even if ceases to be the case – we could include “virtualized hardware” into definition of “hardware”, I have no problems with it, but this “virtualized hardware” still won’t include compiler, which is the point of OP).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.