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
markets.
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).
-f
> 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: