linux-mips
[Top] [All Lists]

Re: [PATCH] mm/pg-r4k.c: Dump the generated code

To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Thiemo Seufer <ths@networkno.de>
Date: Wed, 3 Oct 2007 21:18:00 +0100
Cc: Ralf Baechle <ralf@linux-mips.org>, "Maciej W. Rozycki" <macro@linux-mips.org>, linux-mips@linux-mips.org
In-reply-to: <4703F155.4000301@gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.64N.0710021447470.32726@blysk.ds.pg.gda.pl> <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.16 (2007-06-11)
Franck Bui-Huu wrote:
> Thiemo Seufer wrote:
> > 
> > Then you have the worst of both approaches: The nicely readable
> > disassembly will change under you feet, and you still need
> > relocation annotations etc. for CPU-specific fixups. The end-result
> > is likely more complicated and opaque than what we have now.
> 
> Let say we generate handlers with all possible cpu fixups. Very few
> instructions would be removed so the disassembly should be quite
> similar after patching.

No way. Just check the possible variations: 64bit, highmem, SMP,
and so on.

> And by emitting some nice comments in the
> generated code, it should be fairly obvious to get an idea of the
> final code.
> 
> All fixups would be listed in a table with some flags to identify them
> and a list of instructions which need to be relocated.

At that point you have invented something which effectively emits
the sourcecode for tlbex.c.

> It seems to me that the kernel code would be much simpler than what we
> have now. Regarding the script used to generate the assembly code, if
> think it would be too.

I doubt that.


Thiemo

<Prev in Thread] Current Thread [Next in Thread>