From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21379 invoked by alias); 14 Feb 2003 19:09:36 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 21371 invoked from network); 14 Feb 2003 19:09:36 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 14 Feb 2003 19:09:36 -0000 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id C9FCB80004E; Fri, 14 Feb 2003 14:09:35 -0500 (EST) Received: (from fche@localhost) by toenail.toronto.redhat.com (8.11.6/8.11.6) id h1EJ9ZY04030; Fri, 14 Feb 2003 14:09:35 -0500 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Dave Brolley Cc: sid@sources.redhat.com Subject: Re: [patch][rfa]: SID mapper component - wordsize References: <3E4C3122.5040409@redhat.com> Content-Type: text/plain; charset=US-ASCII From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 14 Feb 2003 19:09:00 -0000 In-Reply-To: <3E4C3122.5040409@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 X-SW-Source: 2003-q1/txt/msg00049.txt.bz2 brolley wrote: > [...] The specification > [4*1000-1010] > should allow access to the range 4000-4043, however, the upper bound > is simply being multiplied by the wordsize, resulting in an upper > bound of 4040. Actually, addresses in the mapper specs are inclusive, not exclusive. That's why one often sees ranges ending with ...ffff. Plain raw scaling such inclusive limits doesn't make sense though, so a special case calculation like yours would make sense. However, care should be taken not to confuse exclusive vs inclusive bounds. > If the mapper is accessed using wordsized elements, the problem goes > unnoticed, since the mapper does not check the ending address of the > range being accessed. That's a peculiar other bug. To be consistent with the byte-oriented addressing across sid::bus, the size of the access would need to be included in the checks. - FChE