From: Thiemo Seufer <ths@networkno.de>
To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
linux-mips@linux-mips.org
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
Date: Wed, 3 Oct 2007 21:18:00 +0100 [thread overview]
Message-ID: <20071003201800.GP16772@networkno.de> (raw)
In-Reply-To: <4703F155.4000301@gmail.com>
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
next prev parent reply other threads:[~2007-10-03 20:18 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-02 13:54 [PATCH] mm/pg-r4k.c: Dump the generated code Maciej W. Rozycki
2007-10-02 14:11 ` Thiemo Seufer
2007-10-02 15:49 ` Ralf Baechle
2007-10-02 16:03 ` Thiemo Seufer
2007-10-02 16:08 ` Maciej W. Rozycki
2007-10-03 1:00 ` Ralf Baechle
2007-10-03 7:05 ` Geert Uytterhoeven
2007-10-03 10:32 ` Ralf Baechle
2007-10-03 12:17 ` Franck Bui-Huu
2007-10-03 13:11 ` Thiemo Seufer
2007-10-03 13:51 ` Maciej W. Rozycki
2007-10-03 19:45 ` Franck Bui-Huu
2007-10-03 20:18 ` Thiemo Seufer [this message]
2007-10-04 7:33 ` Franck Bui-Huu
2007-10-04 10:30 ` Maciej W. Rozycki
2007-10-04 12:15 ` Ralf Baechle
2007-10-04 15:01 ` Franck Bui-Huu
2007-10-04 15:23 ` Maciej W. Rozycki
2007-10-04 15:30 ` Ralf Baechle
2007-10-04 15:35 ` Maciej W. Rozycki
2007-10-04 15:42 ` Ralf Baechle
2007-10-04 17:34 ` Maciej W. Rozycki
2007-10-08 15:46 ` Maciej W. Rozycki
2007-10-08 16:41 ` Ralf Baechle
2007-10-08 16:45 ` Maciej W. Rozycki
2007-10-08 16:53 ` Ralf Baechle
2007-10-05 8:03 ` Franck Bui-Huu
2007-10-05 9:09 ` Geert Uytterhoeven
2007-10-08 15:02 ` Franck Bui-Huu
2007-10-08 15:21 ` Geert Uytterhoeven
2007-10-08 15:26 ` Ralf Baechle
2007-10-09 20:20 ` Franck Bui-Huu
2007-10-05 12:19 ` Maciej W. Rozycki
2007-10-08 14:48 ` Franck Bui-Huu
2007-10-08 15:24 ` Ralf Baechle
2007-10-08 15:39 ` Maciej W. Rozycki
2007-10-09 20:17 ` Franck Bui-Huu
2007-10-10 11:58 ` Maciej W. Rozycki
2007-10-10 12:08 ` [SPAM?] " Nigel Stephens
2007-10-11 12:01 ` Maciej W. Rozycki
2007-10-13 10:53 ` Richard Sandiford
2007-10-15 13:17 ` Maciej W. Rozycki
2007-10-14 19:37 ` Franck Bui-Huu
2007-10-15 13:26 ` Maciej W. Rozycki
2007-10-14 19:32 ` Franck Bui-Huu
2007-10-14 19:53 ` Thiemo Seufer
2007-10-14 20:29 ` Franck Bui-Huu
2007-10-15 19:35 ` Franck Bui-Huu
2007-10-15 20:11 ` Nigel Stephens
2007-10-16 8:24 ` Franck Bui-Huu
2007-10-16 12:58 ` Nigel Stephens
2007-10-17 7:56 ` Franck Bui-Huu
2007-10-17 12:30 ` Thiemo Seufer
2007-10-17 13:25 ` Nigel Stephens
2007-10-17 13:31 ` Maciej W. Rozycki
2007-11-04 8:21 ` Franck Bui-Huu
2007-11-04 17:47 ` Thiemo Seufer
2007-11-04 20:19 ` Franck Bui-Huu
2007-11-05 11:36 ` Ralf Baechle
2007-11-05 21:34 ` Franck Bui-Huu
2007-11-05 23:30 ` Ralf Baechle
2007-11-06 7:23 ` Franck Bui-Huu
2007-11-05 15:58 ` Nigel Stephens
2007-11-05 20:43 ` Franck Bui-Huu
2007-10-10 8:53 ` Ralf Baechle
2007-10-10 12:17 ` Maciej W. Rozycki
2007-10-05 11:51 ` Ralf Baechle
2007-10-08 14:11 ` Franck Bui-Huu
2007-10-08 14:41 ` Ralf Baechle
2007-10-09 20:33 ` Franck Bui-Huu
2007-10-09 20:34 ` [PATCH 1/6] tlbex.c: Cleanup __init usages Franck Bui-Huu
2007-10-11 16:16 ` Ralf Baechle
2007-10-12 6:36 ` Franck Bui-Huu
2007-10-12 14:43 ` Ralf Baechle
2007-10-09 20:35 ` [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section Franck Bui-Huu
2007-10-09 20:35 ` Franck Bui-Huu
2007-10-10 14:27 ` Ralf Baechle
2007-10-10 16:17 ` Maciej W. Rozycki
2007-10-10 16:42 ` Ralf Baechle
2007-10-10 16:55 ` Geert Uytterhoeven
2007-10-10 17:01 ` Maciej W. Rozycki
2007-10-10 17:09 ` Geert Uytterhoeven
2007-10-10 19:58 ` Franck Bui-Huu
2007-10-10 19:29 ` Franck Bui-Huu
2007-10-09 20:36 ` [PATCH 3/6] tlbex.c: remove tlb_handler[] from " Franck Bui-Huu
2007-10-09 20:36 ` Franck Bui-Huu
2007-10-09 20:37 ` [PATCH 4/6] tlbex.c: remove final_handler[] " Franck Bui-Huu
2007-10-09 20:37 ` Franck Bui-Huu
2007-10-09 20:38 ` [PATCH 5/6] tlbex.c: cleanup debug code Franck Bui-Huu
2007-10-09 20:38 ` Franck Bui-Huu
2007-10-09 20:39 ` [PATCH 6/6] tlbex.c: cleanup include files Franck Bui-Huu
2007-10-09 20:39 ` Franck Bui-Huu
2007-10-03 13:41 ` [PATCH] mm/pg-r4k.c: Dump the generated code Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071003201800.GP16772@networkno.de \
--to=ths@networkno.de \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=vagabon.xyz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.