core changes for mep port
Thu Mar 15 02:19:00 GMT 2007
> 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
> 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:
> 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
The multi-mode changes are small, just a few target hooks. The big
change is support for coprocessor modes.
More information about the Gcc