From owner-freebsd-commit  Fri Dec 15 15:52:48 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA27598
          for freebsd-commit-outgoing; Fri, 15 Dec 1995 15:52:48 -0800 (PST)
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA27469
          for cvs-all-outgoing; Fri, 15 Dec 1995 15:51:23 -0800 (PST)
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA27444
          for cvs-sys-outgoing; Fri, 15 Dec 1995 15:51:19 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA27406
          Fri, 15 Dec 1995 15:50:57 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA04105; Sat, 16 Dec 1995 10:43:56 +1100
Date: Sat, 16 Dec 1995 10:43:56 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199512152343.KAA04105@godzilla.zeta.org.au>
To: bde@zeta.org.au, davidg@Root.COM
Subject: Re: cvs commit: src/sys/i386/isa if_ed.c
Cc: CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org
Sender: owner-commit@FreeBSD.ORG
Precedence: bulk

>>In this case, I think the casts only work because the hardware ignores
>>some bits in the address (bits 14-15 of 0-31 for 16K cards and bits
>>13-15 for 8K cards?).  Conversions of the form
>>
>>	(int)(buf - base)
>>	((int)buf) & 0x3fff
>>
>>would be more obviously correct, but might be slower.

>   That's not quite correct. The offset within the NIC memory segment is a 16
>bit number but is written out a byte at a time. The fact that only the lower
>two bytes are written out *implies* a masking of the upper bits. This is both
>intended and correct. I chose to fix the problem the way I did to avoid

Yes, the top 16 bits are masked by not writing out the bytes for them.
Bits 14-15 aren't masked.  Consider a board with 16K of memory address
0xd4000.  Then address 0xd4000 corresponds to offset 0 but offset 0x4000
is written out.  This apparently works because bits 14-15 are ignored by
the h/w.  It wouldn't work for a board with 32K of memory at address
0xd4000 but this is unlikely to be supported since it would take a gate
or two more to decode.  It wouldn't work if the board used bits 14-15
for something else.  To determine the correctnes of the cast, you have
to look at the manuals for all supported boards (a growing list :-) and
and see if those bits are specified as "don't care".

>casting a pointer to a short (which I think is indeed incorrect).

It's no worse than casting to int.  The result is implementation defined.
An unreasonable implementation might always convert to 0...

>   This driver is highly i386-specific and I'm not trying to generalize it.

... but you can reasonably assume the reasonable gcc i386 implementation in
device drivers.

Bruce