From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with archive (Exim 4.43)
	id 1IqwP2-0007dT-EC
	for mharc-grub-devel@gnu.org; Sat, 10 Nov 2007 14:54:00 -0500
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IqwP0-0007ci-OF
	for grub-devel@gnu.org; Sat, 10 Nov 2007 14:53:58 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IqwOz-0007cB-PN
	for grub-devel@gnu.org; Sat, 10 Nov 2007 14:53:58 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IqwOz-0007c7-MH
	for grub-devel@gnu.org; Sat, 10 Nov 2007 14:53:57 -0500
Received: from mailout07.sul.t-online.de ([194.25.134.83]
	helo=mailout07.sul.t-online.com)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Christian.Franke@t-online.de>) id 1IqwOz-0006Bq-BF
	for grub-devel@gnu.org; Sat, 10 Nov 2007 14:53:57 -0500
Received: from fwd34.aul.t-online.de by mailout07.sul.t-online.com with smtp 
	id 1IqwOy-0000vM-03; Sat, 10 Nov 2007 20:53:56 +0100
Received: from [10.3.2.2]
	(rPDXwiZ-ghTqgkg2tP34PdEPT9mRhbSq2xbwx1SsY5p7L6q13ImLa+SZn+t5+OXZEv@[217.235.244.67])
	by fwd34.aul.t-online.de
	with esmtp id 1IqwOp-1zIEZk0; Sat, 10 Nov 2007 20:53:47 +0100
Message-ID: <47360C44.6050906@t-online.de>
Date: Sat, 10 Nov 2007 20:53:40 +0100
From: Christian Franke <Christian.Franke@t-online.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
MIME-Version: 1.0
To: The development of GRUB 2 <grub-devel@gnu.org>
References: <471E4628.9030706@t-online.de>
	<87d4ujmrkm.fsf@xs4all.nl>	<4734E963.20000@t-online.de>
	<87zlxmgkhh.fsf@xs4all.nl>
In-Reply-To: <87zlxmgkhh.fsf@xs4all.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ID: rPDXwiZ-ghTqgkg2tP34PdEPT9mRhbSq2xbwx1SsY5p7L6q13ImLa+SZn+t5+OXZEv
X-TOI-MSGID: 76de5a01-bb3b-4f60-b81a-058245785672
X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3)
Subject: Re: [PATCH] Fix eisa_mmap evaluation, add memory existence check
X-BeenThere: grub-devel@gnu.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: The development of GRUB 2 <grub-devel@gnu.org>
List-Id: The development of GRUB 2 <grub-devel.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/grub-devel>,
	<mailto:grub-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/grub-devel>
List-Post: <mailto:grub-devel@gnu.org>
List-Help: <mailto:grub-devel-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/grub-devel>,
	<mailto:grub-devel-request@gnu.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Nov 2007 19:53:59 -0000

Marco Gerards wrote:
> Christian Franke <Christian.Franke@t-online.de> writes:
>   
>> ...
>> volatile is necessary here to tell the complier that the memory
>> address might not behave like regular memory. Otherwise, the optimizer
>> might legitimately remove memory accesses and then constant
>> propagation detects an unchanged value.
>>
>> gcc actually does a very good job here. Result with volatile removed:
>>     
>
> I think this is just normal memory, not memory mapped hardware.  Or
> perhaps I am misunderstanding something here.
>
>   

It is normal memory - but only if present :-) Like memory mapped 
hardware, missing memory violates the optimizers assumptions about 
memory accesses. Therefore, volatile is mandatory here.


>> $ gcc -S -O -fomit-frame-pointer init.c && cat init.s
>> ...
>> addr_is_valid:
>>    movl    $1, %eax
>>    ret
>> ...
>>
>>
>> aka:
>>
>> static int
>> addr_is_valid (grub_addr_t addr)
>> {
>>  return 1;
>> }
>>
>>
>> This is at least a proof that the original function returns the
>> correct result when real memory is present :-)
>>     
>
> :-)
>
>   
BTW: this also proves that the routine leaves memory unchanged.

Christian