From owner-svn-src-all@FreeBSD.ORG Sat Mar 17 11:48:27 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFD04106564A; Sat, 17 Mar 2012 11:48:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 50F548FC08; Sat, 17 Mar 2012 11:48:26 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2HBmHaK031651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 22:48:18 +1100 Date: Sat, 17 Mar 2012 22:48:17 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Julian Elischer In-Reply-To: <4F642A1A.4070006@freebsd.org> Message-ID: <20120317223612.D2494@besplex.bde.org> References: <201203161942.q2GJgdPU032060@svn.freebsd.org> <4F642A1A.4070006@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, Tijl Coosemans , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r233043 - head/sys/i386/include X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 11:48:27 -0000 On Fri, 16 Mar 2012, Julian Elischer wrote: > On 3/16/12 12:42 PM, Tijl Coosemans wrote: >> int32_t en_sw; /* status word (16bits) */ > > what's wrong with this picture? Only the excessive indentation in the new version. The 16 in the comment is not mismatched with 32 in the code, but is less needed that before, since it is more obvious that the code uses 32 and it goes without saying that this would only be used if it is correct. The comment says that although field has 32 bits in memory, only 16 bits of it are used in the status word register. For fields in this struct that use all of the bits in memory, no comment is made about the number of bits in the register, and vice versa. I forget if the padding bits in memory are read or written by the hardware. On write, they might not be touched, or they might be filled with garbage, or all zeros, or all 1's, or a "reserved" not-quite garbage value. Probably closest the latter, with the actual bits being all 0 or all 1. On read, they might be ignored or checked for garbage. I think they are ignored for this file.d Bruce