bloodline wrote:
I've always been keen on the idea of having the "Executable Format" actually as the gcc intermediate code, and then doing the final compile at the loading stage (by the segloader). That way the same "Executable" could run on both a PPC or a x86.

You could restore platform independence to a certain extent by including object files for assembly functions for a variety of processors and/or platforms. For example, a codec would be mostly half-compiled code, plus an x86 object file for accelerated functions, plus a PPC object file for the same thing. On x86 systems, the back-end would link in the x86 object file.

rinnan wrote:
Not sure what you mean here. Probably the most famous and most used compiler in the world, gcc, is based on this design already. The only thing it lacks, in order to do exactly what is envisioned, is the feature of saving the intermediate output from the front end (right now it just feeds it right into the back-end). If you write in C, C++, or any language more abstract than assembly (including, interestingly, AmigaDE's pseudo-assembly), then the specifics of the CPU are supposed to be hidden from you. Hand-optimizations are wonderful for drivers, datatypes, and so on. But as the optimizers in compilers get better and better, hand-optimization has less and less effect. Eventually, compilers will surpass the human coder's skill in optimization. To some extent this has already happened. I haven't seen a even a driver written in assembly in quite a while, and yet they run with sufficient speed.

Are you imagining an ideal world where programmers carefully code in C, or C++, with the clear knowledge of the CPU they are targetting in their mind? Coding carefully in such a way to encourage the compiler to take advantage of the specific CPU's natural skills? It doesn't work this way. Already, coders code in languages and in styles that are comfortable to them, and leave it to the compiler to figure out how to make it fast. The technique of "cutting the compiler in half" gives the back end more freedom to specifically tailor the resulting machine code to be optimum for the specific target CPU. It will produce faster code than what we have now, not slower code.

Here's a question then... would this back-end compiling also work for drivers as well? Say your audio or video driver would then be compiled specifically for your CPU? Having the apps and OS compiled in this way I think sounds like a nice idea considering I myself don't feel like I should have to muck around with a compiler to get an optimized system up and running. It should be able to do it for me without my intervention, but having source for those who want it is just fine.

The problem with "cutting the compiler in half" is that it forces you to remove any optimizations you might make by hand. All you are allowed is plain C/C++/whatever code. You can make no assumptions as to the CPU that might make things faster. Instead, you use the most generic code possible and pray that the other half of the compiler does a good job. Sometimes it will, and sometimes it won't. No programmer worth spitting will put up with that.

rinnan wrote:
All compilers, including GCC, have a front-end and a back-end. The front end converts the source code into an intermediate form -- it strips comments, resolves symbols, digests the commands into a more machine-code-like stream, and even performs some optimization. But at this stage, it's a pre-digested mess that doesn't mean anything to any specific CPU. Then the back-end takes over. It translates this code into machine code that the target CPU can understand, doing further optimizations. The "cut-the-compiler-in-half" idea basically works this way. The programmer runs the front-end, but not the back-end, on the code when they want to distribute it. What issues from the front end is captured into a standard format and saved into a file. Then, the user, downloads this onto their own machine and runs the back-end process on their own machine, and runs it. Of course this works invisibly. There is no virtual machine, no just-in-time compiling of bytecode, nothing, so no slowdown. In fact, a speedup. Here's why:

When you download a binary for your AROS box, or even compile one using the current instructions and build system, it creates something that would be happy running on your screaming new Pentium 4, or AMD, but would also be quite happy running on a 486. However, the AMD and 486 do differ (REALLY?? ) YES, REALLY! The AMD has more instructions and for optimal execution, would organize them differnetly or use differnet instructions than a 486, but an executable compiled for a 486 can't take advantage of them (though it will, of course, still run). If your OS does the final back-end processing on your own machine, however, it knows that it's an AMD and not a 486, so will optimize the code production around that chip. True, the final binary will run only on that specific chip -- but if a 486 user downloads the same intermediate code, their back-end compiler will do the right thing and produce 486 machine code for them. All in all, it will result in a faster, not slower, experience than what happens now with AROS.

I still believe that downloading the source directly and compiling it entirely is best -- we have all the tools today to do this, up and running, and remember you can obfuscate it if you need to deal with it in a proprietary way.

rinnan wrote:
Graphics/Intuition (interface) -- The old concepts of windows would go away and be replaced by the much more efficient concept of frames and overlays. The whole screen starts as a frame but would subdivide into smaller frames, which of course, can further subdivide ad-infinum. Features like frame-swapping, hiding, and an expose-like finding utility would be there to assist the user. Overlays, which could be sprites, mouse pointers, and other informative over-the-whole-mess elements would exist. Frame-stacks would also exist, in situations where that would make sense. Frames could be made to snap to their smallest or biggest possible size with an easy mouse gesture. Again, hardware independance would be key, with total physical independance of the visual system. Resolution, and to a lesser-extent, color depth wouldn't matter, fonts, icons, and frame frames would be rendered through vector information.