Date: Mon, 27 Sep 1999 23:52:49 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@village.org> Cc: "Matthew N. Dodd" <winter@jurai.net>, KATO Takenori <kato@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/i386/conf files.i386 Message-ID: <Pine.BSF.4.10.9909272254200.707-100000@alphplex.bde.org> In-Reply-To: <199909270628.AAA08033@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'd also like to get some feedback on a related issue. I'd like to
> know what people think of adding a third space to the I386 port. The
> third I/O space would be I386_BUS_SPACE_IO_INDIRECT. The code for it
> ...
> static __inline void
> bus_space_write_1(bus_space_tag_t tag, bus_space_handle_t bsh,
> bus_size_t offset, u_int8_t value)
> {
> #if defined(_I386_BUS_PIO_H_)
> #if defined(_I386_BUS_MEMIO_H_) || defined(_I386_BUS_PIOI_H_)
> if (tag == I386_BUS_SPACE_IO)
> #endif
> outb(bsh + offset, value);
> #endif
> #if defined(_I386_BUS_MEMIO_H_)
> #if defined(_I386_BUS_PIO_H_) || defined(_I386_BUS_PIOI_H_)
> else if (tag == I386_BUS_SPACE_MEM)
> #endif
> *(volatile u_int8_t *)(bsh + offset) = value;
> #endif
> #if defined(_I386_BUS_PIOI_H_)
> #if defined(_I386_BUS_PIO_H_) || defined(_I386_BUS_MEMIO_H_)
> else if (tag == I386_BUS_SPACE_IO_INDIRECT)
> #endif
> outb(bsh[offset], value);
> #endif
> }
Well, this won't compile (unless `bsh' or `offset' is a pointer, but on
i386's bsh is a u_int and offset is and int). Some ugly conversions
(both in the caller and the function) would be required to fix it.
I don't like this much. At least for PIO, indirection may be best in
all cases. I use it for most accesses in sio. I pre-compute all the
heavily used port addresses at attach time to avoid additions at
compile time.
E.g., the line status port is accessed via com->line_status_port instead
of via (com->iobase + com_lsr). The former is always faster (since gcc
doesn't (can't?) know enough about aliasing to use a previously loaded
value of com->iobase, and the addition takes some time. Even if
com->iobase is explicitly loaded into a (register) variable, the
computation of (iobase + com_lsr) takes the same time as the load of
com->line_status_register provided the machine is an i386 and
com->line_status_register is in the L1 cache. (This is where MEMIO may
benefit if we use (iobase + com_lsr). On machines with base+index
addressing, the addition tends to be free. This is also the only excuse
for pushing the addition to the bus space functions.)
Back to the main point. Pre-computation of the heavily used port
addresses is almost the same as construction the table the computation
of bsh[offset]. The only difference is that for the latter, the values
must be stored in an array and the entries for all values of `offset'
that are used must be pre-computed.
The only costs for using indirect addressing for all bus types are:
1) the table would have to be computed for all bus types. This would
mainly cost space, since initialisation for the old cases is
easy (sc->table[i] = sc->iobase + i;).
2) there is an extra memory reference for the above-mentioned MEMIO case.
There is also an extra memory reference when the offset is 0 and the
base is in a register, even for PIO.
3) non-constant offsets may be more expensive.
Indirect addressing would use the current bus space functions with offset 0,
e.g., bus_space_read_1(sc->tag, sc->line_status_port, 0).
sc->line_status_port can still be cached in a register variable, so we
lose mainly in MEMIO cases that could have used
bus_space_read_1(tag, iobase, com_lsr) and where the bus space function
isn't slowed down by more tests.
You could also consider abstracting the indirection in a level between
the driver and the current functions, so that we don't have to duplicate
code in all the functions.
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.9909272254200.707-100000>