This is the mail archive of the
mailing list for the binutils project.
Re: Supporting more than one CPU with the same gas port.
Nick, would you say that it is in bad taste to try to make one
assembler handle two different sets of opcodes in one table, two
different sets of registers in one struct, etc? I would.
James wrote: "So, within one microcontroller there are two processors
that use different machine code..."
Machine code, instruction sets, register sets, programming model,
memory map, clock rate, interrupt handler, etc. In the words of
Freescale itself, taken from their application note AN3224:
"We have two separate CPUs, with different instruction sets and
different CPU architectures, running at different speeds, but using
the same memory and peripherals."
The linker has a flag for linking unrelated code into the same binary,
IMO it's better to use that for its intended purpose than destabilise
the existing S12 assembler with the sort of changes required to take
the ?approach of using one assembler for two disparate cores.
On Wed, Jan 4, 2012 at 2:35 PM, James Murray <firstname.lastname@example.org> wrote:
> On Wed, 2012-01-04 at 10:56 +0000, nick clifton wrote:
> > Hi Sean,
> > > I have a general question when it comes to supporting more than one core
> > > with the same assembler(tc-x)
> > Theoretically yes, but in practice no. ?Why do you want this though ?
> > What is hard about having different assemblers for different architectures ?
> 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.
> In my extension to the m68hc11 port I've added support for the XGATE
> assembly language and allow the two codes to be linked together to a
> single object file.
> 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
> I felt that the linking together (sharing external variables) was a
> benefit outweighing the perhaps unconventional approach.
> James Murray