volatile again

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Hi,

when looking at the m68k ISR behaviour, the old problem of handling the
volatile variables in GCC was seen again. People like Mike Stump and
Ralf Guetlein wrote some time ago :

>> Von: Mike Stump <mrs@windriver.com>
>> I just looked at the uses of volatile_ok, and I must say, it is a bad
>> idea (or maybe just a bad implementation).  Not sure why it is even in
>> there, maybe someone else can elaborate?  In any event, it seems like
>> a hack.
>> Now, why is it a bad idea?  Because there are only two uses of it, and
>> in those two uses, there are three bugs.  The bugs are obvious (watch
>> the control flow and the restoration of volatile_ok).  If we supported
>> frame based cleanup actions in C, and used them, there wouldn't be any
>> bugs.
>> I think a .md that doesn't want volatile mem refs in an instruction,
>> can go out of its way to reject or reload the value, instead of
>> penalizing all insns in all .mds as it does now.
>
> That's the point! I still can't imagine why a volatile mem ref
> should *not* be a general_operand in some compiler passes.
>
> Does anybody remember when this ominous volatile_ok has found it's way
> into gcc? Apparently, the code around this flag is incomplete and
> provisional (see comments in sources). Maybe its inserted only to
> hack around an error in a single target implementation, or sth.
> I cannot see why this hack should penalize all other targets in
> which it is safe to use volatiles as a general_operand.
>
> In big OS-based applications this penalty isn't that serious, becaus
> there won't be many volatiles. But it's a MUST for embedded
> applications to optimally handle volatile mem refs, as these are
> used for i/o ports and other peripherals.

 Ok, the problem with m68k is as follows:

 A dummy test program, straight with H8300 names & addresses,
compiled for m68k with '-m68000' :

--------------------------------
#include <stdio.h>

#define PBDR		(*(volatile char *) (0xffffd6))
#define ITU_TSR0	(*(volatile char *) (0xffff67))

/* int count; */
volatile int count;

void ISR_FUNC handle_intr(void)
{
	count++;
	if (count == 400)
	  {
	    PBDR ^= 0x01;
	    count = 0;
	  }
	ITU_TSR0 &= 0xFE;
	write_mdm_device(0x0a);
}
--------------------------------

 The generated code when 'count' is NOT defined as 'volatile' :

--------------------------------
  handle_intr:
  	link.w %a6,#0
  	movm.l #0xc0c1,-(%sp)
! 	addq.l #1,count
! 	cmp.l #400,count.l
  	jbne .L5
  	move.l #16777174,%a0
  	move.b (%a0),%d0
  	eor.b #1,%d0
  	move.b %d0,(%a0)
! 	clr.l count
  .L5:
  	move.l #16777063,%a0
  	move.b (%a0),%d0
--------------------------------

 The generated code when 'count' is defined as 'volatile' :

--------------------------------
  handle_intr:
  	link.w %a6,#0
  	movm.l #0xc0c1,-(%sp)
! 	move.l count,%d0
! 	addq.l #1,%d0
! 	move.l %d0,count
! 	move.l count,%d0
! 	cmp.l #400,%d0
  	jbne .L5
  	move.l #16777174,%a0
  	move.b (%a0),%d0
  	eor.b #1,%d0
  	move.b %d0,(%a0)
! 	moveq.l #0,%d0
! 	move.l %d0,count
  .L5:
  	move.l #16777063,%a0
  	move.b (%a0),%d0
--------------------------------

 When the memory location 'count' will normally be handled straight with 'addq.l #1,count',
'cmp.l #400,count.l' and 'clr.l count' instructions, why the 'volatile' forces the value to
be handled with the much longer 'load/store' operations in architectures like H8/300 and
m68k which allow a direct operation to the memory location?

 While installing those interrupt-patches, this volatile phenomen could be looked too, if
someone finds a nice temporary work-around... All those rules for these operations are in
the same 'gcc/config/m68k/m68k.c' as the the interrupt_handler stuff...

 It is expected that the GCC-specialists will sooner or later find a nice global solution
for this 'volatile bug', but meanwhile not using the 'volatile' and checking that the
produced code is anyhow 'atomic', may be one way. For H8/300 there is a temporary fix, but
m68k still lacks this...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com