[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ColdFire was Re: [buildd] Etch?

On Sun, 6 Aug 2006, Aurélien GÉRÔME wrote:

> Hi,
> On Sat, Aug 05, 2006 at 02:46:02PM +1000, Finn Thain wrote:
> > If there was a m68k backend for GCC-LLVM [1], the m68k port could ship 
> > LLVM-IR that was assembled for the target at install time. Could be a 
> > viable long term solution. In the short term, I think we have to wear 
> > the performance hit of lowest-common-denominator hybrid binaries.
> I doubt there is one.

LLVM is designed in such a way that the backends aren't tangled up with 
the intermediate representations and early compile stages as they are in 
gcc. It has been deliberately designed to be maintainable and extensible.

> > At least LLVM seems to be a more maintainable design than GCC.
> I fail to see what a virtual machine can bring to the m68k port. Maybe 
> can you enlighten me?

There is a JIT for LLVM, but that only scratches the surface. You should 
read the links I posted. The pdf (and IIRC, the web site) mentions 
deferring the assemble & link to install time. When you look at the 
proliferation of variants of MIPS, ARM etc embedded cores built under 
license, it isn't hard to see why this is becoming attractive. And it 
isn't hard to see why specialised variants are important to embedded 

Given a back end, it wouldn't be difficult to do. The driver is GCC, so 
build scripts don't change. When building the package, the compiler driver 
need only produce, as a side effect, a list of the IR (intermediate 
representation) objects, and the build commands it used to assemble and 
link them. Those are shipped in the package, which has a dep on the 
specific tool needed to assemble and link in a deterministic way.

Note that this is nothing like Gentoo, since they can't control the tools 
or build commands (other than filtering a few compiler flags).


> BTW, I believed the idea was to emulate in kernel space the missing
> opcodes from legacy m68k on CF to avoid whatever modifications on
> the m68k legacy port or to limit them.
> Cheers,

Reply to: