Date: Wed, 10 Jan 2001 17:35:01 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Peter Wemm <peter@netplex.com.au> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Peter Jeremy <peter.jeremy@alcatel.com.au>, Sergey Babkin <babkin@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h Message-ID: <200101110035.f0B0Z1s21398@aslan.scsiguy.com> In-Reply-To: Your message of "Wed, 10 Jan 2001 15:23:38 PST." <200101102323.f0ANNcQ63145@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> This should be taken care of by the bus_space() macros; which is
>> already done by most drivers in the tree. (Many drivers can run
>> in either PIO or memory mapped mode)
>
>But the bus_space_() stuff doesn't handle changing register windows etc.
>eg: if you have a 64K memory space and can read/write it directly when
>memory mapped, but when on ISA it is all crammed into 16 lots of 4K windows
>then bus_space_() cannot save you from this.
>
>ie:
> if (IS_PCI(board_type)) {
> value = *mem[reg];
> } else {
> if (board->window != window(reg))
> board->window = window(reg);
> value = inb(base + (reg % winsize));
> }
>
>Cheers,
>-Peter
Right, so abstract that out with a macro. If performance is
critical, create a set of inline functions for key operations,
and have the macros optimize the access depending on which "attachment"
they are included into. This means you have common code and pay
no speed penalty for using it. Determine the equation for bloat vs.
speed and you can easily decide which functionality can survive
without optimized access (this code goes in foo.c) and which code
can't (goes in foo_bus.c with #define indicating which access type
to optimize for).
--
Justin
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101110035.f0B0Z1s21398>