Thank you, I thoroughly enjoyed this guide. It seems however, that your initial assumption is somewhat invalid: you wanted to build an architecture that a compiler writer would design.
But then you make all design decisions by looking at what the toolchain does well, which is inevitably the feature set of the most popular processors. Which are, in turn, designed by hardware engineers, per your original assumption.
In the preamble I freely admit that this project was based on naive assumptions and ideas. On the other hand, I believe that I was successful in building an architecture that a compiler writer would design, free from the knowledge of how actual hardware works, simply because I only implemented things that were obvious and easy for GCC.
Note the lack of any kind of instruction scheduling, unnatural addressing modes, weird arithmetic, etc.
The ggx processor's successor, moxie (which is part of the upstream GNU toolchain), is slowly developing characteristics shared with real architectures as the FPGA implementation develops. For instance, I just introduced a pipeline hazard with my new multi-port register file implementation that will benefit from some instruction scheduling in GCC.
This title is idiotic. Why does the number of patches matter? Any changes made to a software package can be put into any number of patches. Saying 21 makes it seem like the changes were simple. But those patches could be thousands of lines each. Saying 21 patches is meaningless. Why was it included in the title?
5 comments
[ 3.4 ms ] story [ 23.2 ms ] threadBut then you make all design decisions by looking at what the toolchain does well, which is inevitably the feature set of the most popular processors. Which are, in turn, designed by hardware engineers, per your original assumption.
Note the lack of any kind of instruction scheduling, unnatural addressing modes, weird arithmetic, etc.
The ggx processor's successor, moxie (which is part of the upstream GNU toolchain), is slowly developing characteristics shared with real architectures as the FPGA implementation develops. For instance, I just introduced a pipeline hazard with my new multi-port register file implementation that will benefit from some instruction scheduling in GCC.