[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Forseen performance problems with libchip (and other BIG PBS)
- Date: Fri, 19 Feb 1999 09:52:49 -0600
- From: jennifer.averett at OARcorp.com (Jennifer Averett)
- Subject: Forseen performance problems with libchip (and other BIG PBS)
joel> Yes. Jennifer lurks on the list way too much. :)
Eric> At least I've managed to make her show up once :-)
Eric> Jenifer your experience is important : I still know very little on
Ok I'll throw in two more cents.
Eric> Side remark but that has its importance : I would really love that at
Eric> in discussion we do not mix IRQs and exceptions. The main reason I
Eric> emphasis this is that exception are processor dependent and all
Eric> definition/supports could go in lib/libcpu/_PROC_/xxx while IRQ are
Eric > BSP dependent.
Eric> Furthermore, the implementation of the low level ASM handler are
Eric> differents as :
Eric> - exception do not occur often and generally terminate the
Eric> - then are not likely to be nested,
Eric> - some processor makes things differently for execption
Eric> and interrupts (68040 with interrupt stack hardware and the famous
Eric> copy of the frame on msp stack, Intel for double fault,...)
Eric> - Nothings needs to be acknoledged before entering the
Eric> handler code safely...
Eric> - I do not knows needs for multiplexing exceptions but clearly
Eric> it is required for supporting PCI devices...
I don't completely agree with your differences. Consider the decrementer
exception used for tick. You will also have another common exception if
floating-point unavailable exception is used to recover/store floating point
registers as is being discussed.
joel> Say the standard PPC603 IRQs end with PPC_IRQ_LAST, then you do this:
joel> #define PPC_IRQ_BSP_FIRST_PIC_SOURCE PPC_IRQ_LAST+1
Eric> You mean EXCEPTIONS not IRQ :)
Eric> I would have (or will if I find time to work on MCP750 port :-()
Eric> done things differently.
Eric> First define the exceptions :
Eric> PPC_EXC_xxx (E.g system check, machine check, DSI, ISI, SC, ...)
Eric> and define the API for setting the vectors at the right place.
I don't want to lose the fact that there is a last interrupt called
..._LAST. This is important because there is a large variation on the
number of cpu defined exceptions based upon the individual chip (603e vs
604...). This allows board support packages to support more than one
revision of the same basic hardware.
Eric> One important vector is the External interrupt vector that will be
Eric> to multiplex all the interrupts but this vector can be connected using
Eric> the same API than other exception.
These are attached by rtems_interrupt_catch.
Eric> Then a set of SYMBOLIC irq names that is different from the set of
Eric> (allthough many can be shared by different ports). For the MCP750,
Eric> a PCI/ISA bridge (VIA chipset). The PIC (raven) maps all ISA IRQ on a
Eric> PIC IRQ, but PC 8259 emulations can then be used to perform PC like
Eric> management for ISA interrupt. (if you want to know more, read
Eric> so I will need to define
Eric> PPC_ISA_IRQ0 0
Eric> PPC_ISA_IRQ15 15
Eric> PPC_ISA_IRQ_NB 16
Eric> PPC_PCI_IRQ_X PPC_ISA_IRQ_NB + X
Eric> So that when calling "interrupt connect API" I know what to do
Eric> (if IRQ_NB < PPC_ISA_IRQ_NB) not really connect a handler a PIC level
Eric> but put the handler in a table that will multiplex the single PIC ISA
Eric> For other values, I will conncet the handler directly at PIC level
Eric> (any PCI IRQ). NB : the need for multiplexing the PCI IRQ exists
Will a libchip driver be able to work on both a processor that maps the chip
IRQ directly to a cpu interrupt and a processor that maps the chip IRQ to a
external exception, using your implementation?