And he missed the second step:
File a bug report for the compiler with 'missed optimization opportunity' in the title and a reduced test case.
We like to see real-world examples of where we're generating bad code - if we don't see them, we can't fix them.
Definitely correct, and an oversight on my part. To my part, I've not first-hand observed a compiler generating bad or erroneous code, but was more thinking back to Linus's recent tirade about GCC 4.8. When I have seen the compiler behaving badly, it's usually been in the form of internal compiler errors. When I do encounter these, I do as much research as I reasonably can, and try and distill a minimal reproduction. Last such ICE I saw was in GCC 4.1.2 a few years ago (yes, my employer at the time was that far behind). The Ops team wanted to push a "small" update to my dev server, which I think was running Rhel 5.4 at the time to fix a completely unrelated issue. After the update, I noticed it also updated GCC to a newer point release of 4.1.2 and an unmodified code base started to fail with an ICE. A bit of investigation narrowed it down to, in C++ code, defining an anonymous namespace at the global scope (perfectly legal, but caused an ICE in that particular GCC version). Turns out it had already been reported, fixed and already released in a later version, so my Ops team had very little work to do to fix it.
But yes, a mixture of C++ and assembly is definitely the right solution, either inline assembly or a single separate function to do the messy math.
I disagree with nothing you've said here, or in your initial reply to me. One word of caution: I'd discourage mixing inline assembly with "regular" C/C++ code. Most compilers (last I've looked) immediately bail on attempting to optimize any function that contains inline assembly. I honestly don't know if you have an inline asm function how that plays in - it's just not something I deal with regularly. Last time I wrote/modified any inline assembly was to correct a x86->x64 compatibility problem roughly 6 years ago.
Before I posted this, I read through the roughly 60 posts that were here. If your child is interested in the lore and mechanics of gaming, I think the prime focus should be on creativity and writing. I don't think you can necessarily "teach" creativity, but I think you can encourage it. I would probably suggest a lot of reading of fiction from as great an expansive base of styles and genres as you can. Through exposure to a variety of material, they may find something they like and build/expand upon something they like. Very little is truly a brand new idea. Most fiction is an adaptation/twist/extension on a previous idea.
If your kid wants to both write the story behind the game and the code that makes it happen, large AAA games are not what you want to strive towards. There tends to be a strict separating of responsibilities.
If your child is insistent upon that, as far as development goes, a large number of people have already post some great links to development resources. A lot of those may be over the head of a child, though, let alone a seasoned non-game developer./p?
Actually this is false. It is possible to write a language that is both safe* and compiles itself.
This is not true, at least not initially. And your example of LLVM (and clang) completely disregards its history. LLVM/clang are only relatively recently self-hosting (can be used to build themselves). LLVM & clang are written in C++ and for a long time relied upon an external C++ compiler (typically gcc) to be built.
At least z/OS has some pretty aggressive protection going on that x86 doesn't, otherwise I'd have no hope for the ol' systems (they should hardly ever have existed really then)
That may be, but it didn't stop me from crashing an entire LPAR, knocking the entire development staff off the mainframe by running a simple select sql statement against DB2.
One of the simplest constructs in C++ that makes me cringe is when I see people do:
std::string foo = "";
instead of:
std::string foo;
The reason being, although functionally equivalent, the second version results in faster, smaller code. On every implementation I've looked at the first one results in calls to strlen, a possible memory allocation and a strcpy. The second is a mere memset of the internal pointers to null. Even though us humans that understand C++, the compiler knows only the language. It typically does not know anything about the standard library. Yes, there are exceptions, such as compile-time warnings/errors for mismatched arguments to printf style functions. But, those are exceptions, not the rule, and they are few and far between.
When I see the first form, I immediately understand that I am looking at code from some whose primary language is not C++, but instead likely Java or C#.
No amount of careful planning will ever replace dumb luck.