> This and the register changes come close to multi-arch gcc. Yup. The core has two modes, core and vliw, and the coprocessor(s) each have their own units. The core manages the opcode processing, but the coprocessor does the work.
> Historically we have not tried to support different architectures in > the same compiler, even when there are coprocessors on the same > chip. We've provided different compilers, and expected people to > stich together the .o files. In the case of MeP, the vliw mode combines a core insn and a coprocessor insn into each vliw bundle, so that the two units can run in parallel. Hard to do that with the linker. Plus, the core-mode opcodes are exactly the same as the core portion of the vliw bundle. It's the coprocessor side of the vliw bundle that's different. > Do you have insns to move values from the main processor to and from > the coprocessors? What do those insns look like? movcopsisi2? How > do those insns get generated? It's handled through the regular movsi patterns. I'm not exactly sure how it inserts the subreg conversion, though, but it's just subreg'd. If you want a conversion, you need to use an intrinsic. A pointer to the patch for 3.4 was posted here recently: http://people.redhat.com/dj/mep/ > Again my first reaction is whether it is necessary to compile code > which runs in two completely different modes in the same > compilation. If the functions can't call each other, why do they > need to be compiled together? Why do *any* two functions need to be compiled together? This is very much like arm/thumb or mips/mips16, except that the available *functionality* changes. So, if you want to have a static function that does coprocessor work in an otherwise non-coprocessor source file, you have to have a multi-mode compiler. > That said the machine independent changes here are presumably quite > small. The multi-mode changes are small, just a few target hooks. The big change is support for coprocessor modes.
