This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Hi James,

What I believe Sean is specifically asking about is in relation to
Freescale embedded microcontrollers that have two distinct CPUs within
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.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]