On Wed, 7 Apr 1999, Matthew Jacob wrote:

> On Wed, 7 Apr 1999, Jason Thorpe wrote:
> 
> > On Tue, 6 Apr 1999 18:41:29 -0700 (PDT) 
> >  Matthew Jacob <mjacob@nas.nasa.gov> wrote:
> > 
> >  > So just to reconfirm- for sparc64 ports __sparc__ won't be defined, but
> >  > __sparc64__ will be....
> > 
> > Note the lack of underscores in my message...
> > 
> > The kernel Makefiles define symbols that match $MACHINE, i.e. "sparc"
> > and "sparc64".  Like "hp300", "amiga", "pmax", "mac68k", etc.
> > 
> 
> Oh. Well- I'm hoping for compiler assist here. This is code that lives in
> other than NetBSD. So- my question is still: will NetBSD sparc64's
> compiler generate __sparc__ as well as __sparcv9__? Or is this just too
> broken for NetBSD and I'll figure out a better way to do this? Perhaps I
> should- based upon inclusion of some SBus header file that generate a
> define- I mean, it's really an optimization to not have to do the swizzle
> check for platforms/instances that can't possibly be SBus instances.

Things get a tad ugly.  SBus will use big-endian addressing and big-endian
accesses.  PCI will use little endian addressing and little-endian
accesses.  It is quite possible to have both SBus and PCI on the same
machine.  PCI devices will either use a little-endian page mapping or a
little-endian ASI in the bus_{read,write}_*() macros to access PCI
register, control, and memory spaces.

What does this mean?  It's probably better to define all the registers as
16-bit entities so that endianness is handled automagically, and use
macros to access the sub-fields. Otherwise things get ugly, requiring two
different drivers for SBbus and PCI devices, based on some as yet
non-existant SBUS/PCI define.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me