linux-mips
[Top] [All Lists]

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

To: Thiemo Seufer <ths@networkno.de>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
Date: Wed, 03 Oct 2007 21:45:25 +0200
Cc: Ralf Baechle <ralf@linux-mips.org>, "Maciej W. Rozycki" <macro@linux-mips.org>, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=wBaLFP0lfnx1FAcT4YjMW+TTCpdClKW+ZrInFq4+dFM=; b=iPJqUHkDG+ZJiAZ6EefglT1ypwYvQ6xz9SbA1VyhMjqsDDRBeV7UvIPq5RFaYQRK1UCstnt9tdN2lisiiHb93DEqH0SJh0JoaXYej4hFFcK01/NPewOuxcyBsA21QPmq//8xEH+JCcVqyIvpdmmJV6CXQQ6/eXhfqAfdB/tb2n8=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Kv8FL0QGhqc8/6QlWbT98A3vyXVGw12A2snQuxFj/rMSn806nWhAwt7bu7DfD3S6/qN4r7XD8hhUQqS9rWq8EQlFYFH2aVGaKSgMS9N0bjwudc0i3kEjUaFZZLOwf+TfS32K+0ahK297ikJPWhIrPGuemnwUe3+ww8IPCEQ1H9Q=
In-reply-to: <20071003131158.GL16772@networkno.de>
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>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.5 (X11/20070719)
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. 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.

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.

Thanks,
                Franck

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