linux-mips
[Top] [All Lists]

Re: Where is the definition of i_j macro ?

To: "wilbur.chan" <wilbur512@gmail.com>
Subject: Re: Where is the definition of i_j macro ?
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Sun, 17 Oct 2010 19:56:58 +0100 (BST)
Cc: Adam Jiang <jiang.adam@gmail.com>, Linux MIPS Mailing List <linux-mips@linux-mips.org>
In-reply-to: <AANLkTimkiwssyA=1Ub3qgekcsqECKPy+uuvFxkATqOmn@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <AANLkTik4BddKpVm0x4EpCKCdUff0L=XiYRjfhJaPmX23@mail.gmail.com> <20101016155552.GE23119@capricorn-x61> <AANLkTimkiwssyA=1Ub3qgekcsqECKPy+uuvFxkATqOmn@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
On Sun, 17 Oct 2010, wilbur.chan wrote:

> I_u1(_j);  They just make up pieces of  asm opt code into a  string
> and copy them to ebase:
> 
> memcpy((void *)ebase, final_handler, 0x100);
> 
> 
> Why they did like this seemed strange to me, maybe in the
> consideration of portability.

 This is a performance-critical piece of code that varies vastly across 
processors supported.  As we started losing control of the original 
preprocessor-based approach and had no way to keep performance optimal 
this way anyway, late Thiemo Seufer came up with this brilliant solution 
of generating this code at the run time, early during bootstrap.  This 
solution enabled us with tailoring code used specifically for each 
processor supported, up to including certain processor errata workarounds 
on the as-needed basis.

  Maciej

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