bsnes' source is getting really annoying to work with. If you look at src/interface.hpp, you'll see a carefully ordered list of header files, needed to get all of the various functions to inline across file boundaries. Look at ppu/counter.hpp and you see where I've resorted to wrapping functions I can't inline in headers that can't be included yet (circular dependency issues) so that the bulk of the functions can be inlined.
Why do I do this? Take this small example:
Code: Select all
int compute(int x, int y) { return g(f(x, y), g(x, y)); }
int f(int x, int y) { return (x * 8) - (y * 4); }
int g(int x, int y) { return (x * 2) + y; }
If f,g are in a different source file, and you benchmark calls to compute(), it's literally ~15-20x slower.
But putting all of these speed-critical functions in header files is increasing compile time, hurting maintainability, etc. Not to mention all the benefits I
could be getting if I inlined even more functions.
The solution to this problem is obvious, and Intel + Microsoft solved it five years ago: Link-time optimization. That is, compile each object to an intermediate language, then do all the machine translation inside the linker.
Visual C++ calls it LTCG, Intel C++ calls it PGO. Naturally, GCC only has --combine for pure C89, so I'm screwed.
... or am I? What if I were to make a special "release" target for GCC in my Makefile ... take all of the source files, spit them out into a file called lto.cpp, then compile and link that as if it were one gigantic object.
It would eat an insane amount of memory, take an eternity to compile, etc; but I think it could work. And, if we're lucky and GCC catches up in the next ten years, we can just convert that back to a compiler switch like the modern compilers have (/LTCG et al.)
Thoughts?
Therefore for hiro, if the Qt part of hiro didn't include anything from the rest of hiro, it can be a stand alone backend, and not infect the rest of hiro to be GPL.
That's excellent news. Encourages me to take another stab at hiro::qt sometime.
However, the workaround for GPLv2 won't work, as GPLv2 doesn't allow linking against non GPLv2 code, unless it can be virally "upgraded" to GPLv2.
Yeah. For this at least, it's Linux we're talking about. The user would be doing the linking themselves. And since it's a distribution license, so long as they keep it for personal use, they aren't violating anything. And even if they were, who cares? Nobody will know.