Re: Supporting more than one CPU with the same gas port.

[nick clifton <nickc at redhat dot com>]

Hi James,

> What I believe Sean is specifically asking about is in relation to
> Freescale embedded microcontrollers that have two distinct CPUs within
> them.
> The main processor is a CISC device (S12X)
> The second processor is a RISC device (XGATE)
>
> So, within one microcontroller there are two processors that use
> different machine code. However, they share common RAM and peripherals
> and the XGATE code starts off in the same flash space as the S12X code.

OK, but why do you want one toolchain that can handle both types of 
processor, rather than two toolchains, one for each processor ?

I get that you might want to include binaries for both types of 
processor into a single executable image, but you can already do this 
with the existing tools.  (Eg the .incbin directive in gas or the 
--add-section option to objcopy).  In fact it seems to me that the 
easiest way to do this might be to treat the executables for the 
secondary processor as overlays and use the linker's overlay mechanism 
to handle them.


> My belief is that this works, given a caveat
> - you have to know which target the code was assembled for when
> disassembling it and where in memory it is located.
>
> gas and objdump use the CPU specific target
> ld uses the m68hc12elf (shared) target

But this is basically the same as having two toolchains, one for the 
S12X and one for the XGATE.  In fact the only issue I see with the two 
toolchain approach comes when trying to disassemble an executable that 
contains code for both processors.  (Actually I imagine that there would 
also be an issue when trying to debug such a binary, but that is outside 
the scope of this discussion).  You could use --section option to 
objdump to restrict disassembly to only those sections relevant to the 
toolchain being used, although this is rather clunky.


> I felt that the linking together (sharing external variables) was a
> benefit outweighing the perhaps unconventional approach.

Which presumably you can do with the toolchain for the S12X processor, 
provided that it has been configured to allow the XGATE processor as an 
additional target.

So the real problem is that although you can use the S12X toolchain for 
most things, you cannot use it to assemble or disassemble XGATE 
binaries.  For that you need a second toolchain, or else a combined 
toolchain that really is combined, including GAS and OBJDUMP.  Which was 
the point of this whole thread.  Ok - so I see where you are coming from 
now.

Have you considered treating the XGATE architecture as a variant of the 
S12X architecture, in the same way as THUMB/ARM or MIPS16/MIPS ?  I am 
sure that they are actually wildly different, but what if you pretended 
that they are not.  GAS is perfectly happy with supporting multiple 
variants of the same architecture and you could use a feature like the 
mapping symbols used by the ARM port to indicate when a section of code 
was in S12X or XGATE format.


> thoughts?

Well my main objection is that I am trying to avoid feature bloat (and 
hence increased scope for the introduction of bugs).  If it is possible 
to achieve what you want without extending the tools, then that would be 
the option that I would prefer.

Cheers
  Nick