linux-mips
[Top] [All Lists]

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

To: SGI MIPS list <linux-mips@oss.sgi.com>
Subject: Re: [PATCH] Bring back R4600 V1.7 support
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Date: Tue, 20 Aug 2002 16:10:13 +0200
In-reply-to: <Pine.GSO.3.96.1020820152046.8700E-100000@delta.ds2.pg.gda.pl>
Mail-followup-to: SGI MIPS list <linux-mips@oss.sgi.com>
References: <20020820113329.GZ10730@lug-owl.de> <Pine.GSO.3.96.1020820152046.8700E-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.4i
On Tue, 2002-08-20 15:30:22 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1020820152046.8700E-100000@delta.ds2.pg.gda.pl>:
> On Tue, 20 Aug 2002, Jan-Benedict Glaw wrote:
> 
> > Please accept the patch (from my previous mail). I'm using it now for
> > two days, and I've got one mail telling me that it works for its sender.
> 
>  Ugh, this should be a separate set of functions selected at the run time. 
> It should be fairly trivial to rewrite it this way (best done with
> processor-specific functions expanded from common templates for ease of

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.

-*- 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, 

static inline void r4k_flush_cache_all_s128d16i16(void)
static inline void r4k_flush_cache_all_s32d32i32(void)
static inline void r4k_flush_cache_all_s64d32i32(void)
..

could go away by: (there _will_ be bugs. 100% untested, and I'm a bad
preprocessor coder:-)

#define FUNC_R4K_FLUSH_CACHE_ALL(NAME, SC, DC, IC)              \
        static inline void                                      \
        r4k_flush_cache_all_##NAME(void)                        \
        {                                                       \
                blast_dcache##DC();                             \
                blast_icache##IC();                             \
                blase_scache##SC();                             \
        }

and then writing:

FUNC_R4K_FLUSH_CACHE_ALL(s128d16i16, 128, 16, 16)
FUNC_R4K_FLUSH_CACHE_ALL(s32d32i32,   32, 32, 32)
FUNC_R4K_FLUSH_CACHE_ALL(s64d32i32,   64, 32, 32)
...

instead. The __save_and_cli()/__restore_flags() functions could be done
as well as all the remaining others. That would pollute namespace like
it does today, but the .c file will be 80% smaller or so:

$ wc -l c-r4k.c 
   2422 c-r4k.c


MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
         -- New APT-Proxy written in shell script --
           http://lug-owl.de/~jbglaw/software/ap2/

Attachment: pgppV6fj2uiwI.pgp
Description: PGP signature

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