boot loader question

Bill Hacker wbh at conducive.org
Tue Apr 5 11:03:33 PDT 2005


lybsd.org> <20050405084741.GA3491 at xxxxxxxxxxxxxxxxx> <200504051700.j35H0jtp084880 at xxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <200504051700.j35H0jtp084880 at xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 45
Message-ID: <4252d2f3$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 218.253.82.16
X-Trace: 1112724211 crater_reader.dragonflybsd.org 720 218.253.82.16
Xref: crater_reader.dragonflybsd.org dragonfly.users:2736

Matthew Dillon wrote:

> :
> :On Tue, Apr 05, 2005 at 04:32:28PM +0800, Bill Hacker wrote:
> :> Again - 'shared interrupts' have us going out in software and burning 
> :> CPU-cycles
> :> to inquire as to who wishes to do what, with which, and to whom each 
> :> time one line goes active.
> :
> :Actually it is not more expensive than doing the PCI cycles in hardware,
> :just more expensive to manufacture.
> :
> :> Were the INT lines to be read as a byte, or even a nibble, we could 
> :> decode that
> :> in a gate array and save a lot of time and code execution.
> :
> :But it would also increase the costs of the bus protocol dramatically.
> :Keep in mind that PCI interrupts are additive (level triggered?),
> :read as long as any device has the interrupt triggered, the system
> :can handle it. It's the simplest and most efficient way to avoid
> :races without additional bus cycles, which can often be even more
> :expensive.
> :
> :Joerg
> 
>     If Intel had adopted Motorola's vector generation protocool it wouldn't
>     be the problem it is today.  Motorola's 68000 had prioritized level
>     triggered interrupts with individual vectoring capabilities.   The
>     glue logic required consisted of a single 14-pin 8:3 priority mux
>     dip chip.

Shades of VME vs Multibus...

Pardon Intel, Matthew, for they are but barbarians, and think that the 
customs of their mask and and die are the laws of nature.

(With apologies to GBS) ;-)

> 
>     But since we can't redesign the protocols....
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon at xxxxxxxxxxxxx>






More information about the Users mailing list