From owner-cvs-all Tue Sep 28 10:46: 1 1999 Delivered-To: cvs-all@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 53D94156CD; Tue, 28 Sep 1999 10:45:53 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA30669; Tue, 28 Sep 1999 11:45:47 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA04687; Tue, 28 Sep 1999 11:45:44 -0600 (MDT) Message-Id: <199909281745.LAA04687@harmony.village.org> To: Bruce Evans Subject: Re: cvs commit: src/sys/conf files src/sys/i386/conf files.i386 Cc: Takahashi Yoshihiro , winter@jurai.net, kato@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, FreeBSD98-hackers@jp.freebsd.org In-reply-to: Your message of "Wed, 29 Sep 1999 03:06:50 +1000." References: Date: Tue, 28 Sep 1999 11:45:44 -0600 From: Warner Losh Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In message 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. : 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). When a driver doesn't need to do so, ther eis no extra cost over the current bus_space implementation. : 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). : > But, your code requires some ugly casts. : > I suggest the following way to fix this problem. : > : > 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 space implementation that had both bus_space_handle_t and bus_space_tag_t as structs. The biggest breakage was with the tag_t change since too many places still use the machine dependent I386_BUS_SPACE_FOO tags and I was too lazy to fix it right (actually, I didn't think of how to fix it right until just this instant). bus_space_map/unmap would be easy to implement which would solve the math problem, assuming that's all the do, and they don't mark the region as in use/free. If they do, the implementations get uglier much more quickly. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message