From owner-cvs-all Mon Sep 27 6:53:18 1999 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E01B614D6E; Mon, 27 Sep 1999 06:53:10 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from d139.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA19183; Mon, 27 Sep 1999 23:53:31 +1000 Date: Mon, 27 Sep 1999 23:52:49 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Warner Losh Cc: "Matthew N. Dodd" , KATO Takenori , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/i386/conf files.i386 In-Reply-To: <199909270628.AAA08033@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > 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