Date: Wed, 29 Sep 1999 05:48:29 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@village.org> Cc: Takahashi Yoshihiro <nyan@FreeBSD.org>, winter@jurai.net, kato@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, FreeBSD98-hackers@jp.freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/i386/conf files.i386 Message-ID: <Pine.BSF.4.10.9909290511240.7835-100000@alphplex.bde.org> In-Reply-To: <199909281745.LAA04687@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Sep 1999, Warner Losh wrote:
> In message <Pine.BSF.4.10.9909290231150.7599-100000@alphplex.bde.org> Bruce Evans writes:
> : 1) Only one bus type supported, and the tag for that is a compile-time
> : constant. Otherwise, there will be an extra branch in the bus space
> : routines for getting to the inirect case. This branch will cost
> : more than indirection on most machines.
>
> That's what the ifdefs do. They give you a zero branch function.
> When you support more buses, then you have more things to support.
The ifdefs don't help here. I've already mentioned the critical cases.
In more detail:
Case 1: only one bus type supported, etc., and that type is the new
indirect type.
Case 2: multiple bus types supported, including the new indirect type.
Driver strategy A: always put indirections in driver (and don't use new bus
type.
Driver strategy B: always leave indirections to bus space functions.
Costs for various combinations:
Case 1 - strategy A: 1 indirection (in driver), 0 branches
Case 1 - strategy B: 1 indirection (in bus space function), 0 branches
Best strategy for case 1: either.
Case 2 - strategy A: 1 indirection (in driver), 0 branches
Case 2 - strategy B: 1 indirection (in bus space function), 1 branch
Best strategy for case 1: strategy A. However, this is only for the
new bus types. The old types may lose in some cases due to an extra
indirection in a bus space function.
> : 2) i386-style PIO access with the port address in a register, and offset
> : 0. If the port address is in a softc, then there must be an indirection
> : to load it, and the load should load the final address
> : (sc->sc_bshtable[offset]). If the offset is nonzero, then on i386's
> : there must be an instruction to add it, and this will take the same
> : time as an indirection in many cases even if the base address is in
> : a register.
>
> I'm not sure I understand why this is bad. When a driver needs to use
> indiction, it pays a small runtime price to do so (one extra add).
I think you mean one extra load.
> When a driver doesn't need to do so, ther eis no extra cost over the
> current bus_space implementation.
The point is that in the PIO case, doing the indirection in the driver
is normally at least as good, and often better than doing it in the bus
space function.
> : 3) MEMIO access with the port in a register, and the offset constant or in
> : a register, and a machine that does suitable (base + index) addressing
> : at no cost.
>
> I'm not sure I understand this objection. In the current memio case
> we have the same overhead we do for pio (namely the addition).
Not true. Memory accesses can often be done using base + index addressing,
while i386 PIO addressing requires and extra add and is made worse be gcc
doing suboptional register allocation. E.g., for *(base + offset) in i386's:
movl base,%ebx
movb offset(%ebx),%al
and for inb(base + offset):
movl base,%edx
addl $offset,%edx
inb %dx,%al
> : > bus_space_handle_t is the union instead of u_int.
> : >
> : > union bus_space_handle {
> : > bus_addr_t bsh_base;
> : > bus_addr_t *bsh_iat;
> : > };
> : > typedef union bus_space_handle bus_space_handle_t;
> :
> : Doesn't this require changing all drivers that currently use the
> : bus space functions to be changed to initialise their sc->sc_bsh.base
> : instead of their sc->sc_bsh? This is uglier than casting.
>
> No. There are remarkably few drivers that do math or other naughty
> things with their bus handle. There are likely only 3-5 in the tree.
> Doesn't sound like an undue burdon to me. I had an experimental bus
It's incompatible with NetBSD, etc. Only the first member of a union
can be initialised statically in Standard C.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9909290511240.7835-100000>