Forseen performance problems with libchip (and other BIG PBS)

[mark.johannes at oarcorp.com (Mark Johannes)]

To all:

We need to remeber that this first version of libchip is at best a
proof-of-concept to determine the fitness of the ideas.  This high-level
design is a broad interpretation of all the devices that exist within the
embedded domain.  We all are aware that what is good for one family of
processors can be very wrong for another, case in point Eric's concerns.
What we may find is that at the end of this study is that too much
generality is a bad thing.  The questions we need to raise are not only what
is common among these devices, but do they function in common ways to make
them generic.  If not, then we have our dividing line for the generics.

In addition. the BSP configured using this method can be optimized further
to meet the specfic needs of the user.

I believe this will be an interesting, challenging, and enlightning task to
bear out these details to achieve a feasible BSP architecture that will not
only be performance oriented, but also modular enough to support
"cut-and-paste" BSP development.

Regards,

Mark Johannes
OAR Corporation

> -----Original Message-----
> From: owner-rtems-snaphots at oarcorp.com
> [mailto:owner-rtems-snaphots at oarcorp.com]On Behalf Of VALETTE Eric
> Sent: Tuesday, February 09, 1999 5:35 AM
> To: rtems-snapshots at oarcorp.com
> Cc: joel at oarcorp.com; valette at crf.canon.fr
> Subject: Forseen performance problems with libchip (and other BIG PBS)
>
>
>
> I have been looking a little bit to the libchip things and
> I must say I'm totally disappointed by the "generic"
> API definition.
>
> in  serial.h we find :
> 		---------------------
> typedef unsigned8 (*getRegister_f)(unsigned32 port, unsigned8 register);
> typedef void      (*setRegister_f)(
>                             unsigned32 port, unsigned8 reg,
> unsigned8 value);
> typedef unsigned8 (*getData_f)(unsigned32 port);
> typedef void      (*setData_f)(unsigned32 port, unsigned8 value);
> 		--------------------
>
> then latter in ns16559.c we see that each register is accessed
> via call to the functions ptr.
>
> I would like to recall that on PPC, motorola the function
> getRegister_f can be implemented by a single movl instruction
> and that using this API will imply to have for each interrupt
> several additionnal indirect function calls compared to normal
> code execution.
>
> On modern precessor architecture a function call costs much
> more than the number of processor cycles it requires to perform
> it as it also implies :
>
>      - two flushs of the instructon pipleine, and a two reload
>      whih is extermely costly especially for one instruction
>      functions.
>      - more cache misses, more memory accesses,
>
> I would really like someone with the relevant hardware equipement
> to benchmark a driver using this API and a normal driver. I would
> not be surprised to get 40% performance degradation...
>
> Other problems :
>
>       1) "getRegister_f" should be "getRegister_p" as the mapping of
>       PCI IO space and PCI ISA IO space is board dependent for example
>       on PPC (you can have a look at the definition of inb in the linux
>       source tree to be convinced...),
>
>       2) The code that needs to be executed to handle an interrupt
>       is BSP specific as the code that needs to be performed
>       to acknoledge the interrupt is usually dependent on the
>       interrupt mangement architecture (access to 8259 PIC to
>       reenable the interrupt needed if SET_VECTOR is called).
>       The actual code will never work on pc386 due to a more
>       powerfull interrupt API for example...
>
> So to summarize :
>
>    1) THE IDEA BEHIND LIBCHIP IS GOOD,
>    2) WHAT IS CURRENTLY DONE IS REALLY BAD AS FAR AS I HAVE
>    ANY LEGITIMITY TO SAY THIS,
>    3) We should start a more interactive spec of libchip API,
>
> Missing API I can already see :
>
> 	typedef unsigned8 (*getRegisterSet_f)(...); to fectch
> 	several contiguous registers
>
> 	typedef unsifgned (*getDataArea) (...)
>
> In particular for PCI devices with on board memory,
> accessing the data byte per byte is crasy...
>
>
> --
>    __
>   /  `                   	Eric Valette
>  /--   __  o _.          	Canon CRF
> (___, / (_(_(__         	Rue de la touche lambert
> 				35517 Cesson-Sevigne  Cedex
> 				FRANCE
> Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
> E-mail: valette at crf.canon.fr
>