[Top] [All Lists]

Re: [PATCH] Bring back R4600 V1.7 support

To: Jan-Benedict Glaw <>
Subject: Re: [PATCH] Bring back R4600 V1.7 support
From: "Maciej W. Rozycki" <>
Date: Tue, 20 Aug 2002 16:46:33 +0200 (MET DST)
Cc: SGI MIPS list <>
In-reply-to: <>
Organization: Technical University of Gdansk
On Tue, 20 Aug 2002, Jan-Benedict Glaw wrote:

> Actually, I had written all that using separate functions before, but
> neither I nor Ralf liked this approach (because it adds hundreds LOC to
> .../c-r4k.c). Ralf then suggested writing it using macros, so I did.

 Obviously you'd put all the R4600 stuff in a separate file (the second
and the third being the regular R4k stuff and the template macros sourced
by the first and the second one).  That would aid diffing as well. 

> -*- Proposal -*-
> There are IMHO two goals, one for near future, one for following day
> (after first goal has reached):
>       1. There are many (equally looking) functions in c-r4k.c . It
>          would be nice to not have the (more-or-less) function body 10
>          times there.
>       2. it would be nice to not have like 50 functions around, but to
>          better have a flexible way to do what needs to be done.
>          Something like an (initdata) array containing PRId and
>          function pointers (or other info) on "what needs to be
>          done".
> The first one seems quite easy. Looking eg. at Alphas, they have a macro
> defining a whole function (which inserts a correct function name by
> supplied arguments etc.). This way, 

 Definitely.  The other one is done by Alphas as well since RTH wrote
generic kernel support.  I consider such a feature one of goals for MIPS
as well, so such a rewrite would be a necessary part of the design sooner
or later anyway. 

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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