Setting build parameters for a sub-tree of RTEMS sources

Mon Apr 24 18:21:15 UTC 2000

Hi, Joel -

Thanks for the note.

On Mon, 24 Apr 2000, Joel Sherrill wrote:
> Is -O4 allowed to reorder on the SH-2?  If so, it is possible that 
> executing the statements in the order presented by the source is
> incorrect and the reordered version is correct by the HW.

I don't know where to check this with GCC docs, but I think the answer is
'yes', because the '-O4' output has reversed the order in which the two
exported functions of my code module appear in the assembly language
output. This is the version which works. #8-P)

> Is read8() a macro or subroutine?

 > > '#define read8(addr)  (*(volatile unsigned8 *) (addr))'

They're macros. 'read*' effectively typecasts the right-side argument of
an assignment, so you can just define a CPU register in terms of its
[memory-space] address:
     '#define SOME_ONCHIP_REGISTER  0xffff????'

and access it with:
 > >    'temp8 = read8(SOME_ONCHIP_REG);'

'write*' versions are macros for type-case assignment operations - left
and right sides both appear. You can thus read or write to different
register widths with a single register-address definition, provided this
is appropriate for the hardware.

>  Have you looked at the 
> assembly generated at both levels to see if some obvious
> set of operations is differently?  I know that when you are
> missing volatile, the difference is amazingly clear this way.

Yes: I can follow the '-O4' output fairly well -- we're just talking about
3 read/mask/write sequences here -- but '-O1' is dense, convoluted and
loop-oriented. I haven't puzzled it out.

I can try again with 'volatile', which doesn't solve the problem, in case
it would be informative.

NATURALLY ---
I want to find out if I have a usage or coding error here, and fix it.

BUT --- I think the selective-optimization question still obtains, because
I may yet inherit or write other code with similar sensitivities: I was
just lucky enough to find this case in a short, well-contained routine. I
fear taking a long time to find this type problem in a more deeply buried
part of the code.

The three attachments to this note are for true masochists, but I would
be very happy to receive feedback from anyone who looks at them:
1) the original C code: 'hw_init.c'
2) assembly code obtained with '-O4' optimization, which works, and
3) assembly code obtained with '-O1' optimization, which doesn't work.

I chopped the assembly listings down to the tiny fraction which is
corresponds to my source, and may have tossed out some essentials -- let
me know that's true.

Let me know also if I should spare the list this gorey postmortem, and
just post a conclusion, presuming I get to one.

Thanks for any comments -

   John Mills
   Sr. Software Engineer
   TGA Technologies, Inc.
   100 Pinnacle Way, Suite 140
   Norcross, GA 30071-3633
   e-mail: jmills at tga.com
   Phone: 770-441-2100 ext.124 (voice)
          770-449-7740 (FAX)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hw_init.c
Type: application/octet-stream
Size: 3974 bytes
Desc: 'hw_init.c' original source
URL: <http://lists.rtems.org/pipermail/users/attachments/20000424/d2ec31ed/attachment-0001.obj>
-------------- next part --------------
 [... entire preamble elided ...]
	.align 4
	.def	_bsp_hw_init;	.val	_bsp_hw_init;	.scl	2;	.type	041;	.endef
	.global	_bsp_hw_init
_bsp_hw_init:
	.def	.bf;	.val	.;	.scl	101;	.line	78;	.endef
	.ln	2
	.ln	28
	mov.l	r14, at -r15
	mov.w	L54,r3
	mov.w	@r3,r1
	.ln	29
	mov.w	L55,r2
	.ln	28
	extu.w	r1,r1
	.ln	29
	or	r2,r1
	.ln	30
	mov.w	r1, at r3
	.ln	33
	mov.w	L56,r2
	mov	#0,r1
	mov.w	r1, at r2
	.ln	36
	add	#-6,r2
	mov.w	@r2,r1
	extu.w	r1,r0
	.ln	37
	or	#32,r0
	.ln	38
	mov.w	r0, at r2
	.ln	28
	mov	r15,r14
	.ln	40
	mov	r14,r15
	rts	
	mov.l	@r15+,r14
	.align 1
L54:
	.short	-31816
L55:
	.short	2048
L56:
	.short	-31814
	.def	.ef;	.val	.;	.scl	101;	.line	40;	.endef
	.def	_bsp_hw_init;	.val	.;	.scl	-1;	.endef
	.align 4
	.def	_early_hw_init;	.val	_early_hw_init;	.scl	2;	.type	041;	.endef
	.global	_early_hw_init
_early_hw_init:
	.def	.bf;	.val	.;	.scl	101;	.line	55;	.endef
	mov.l	r14, at -r15
	mov	r15,r14
	.ln	20
	mov	r14,r15
	rts	
	mov.l	@r15+,r14
	.def	.ef;	.val	.;	.scl	101;	.line	20;	.endef
	.def	_early_hw_init;	.val	.;	.scl	-1;	.endef
-------------- next part --------------
 [... entire preamble elided ...]
	.align 4
	.def	_early_hw_init;	.val	_early_hw_init;	.scl	2;	.type	041;	.endef
	.global	_early_hw_init
_early_hw_init:
	.def	.bf;	.val	.;	.scl	101;	.line	55;	.endef
	.ln	20
	mov.l	r14, at -r15
	mov	r15,r14
	mov	r14,r15
	rts	
	mov.l	@r15+,r14
	.def	.ef;	.val	.;	.scl	101;	.line	20;	.endef
	.def	_early_hw_init;	.val	.;	.scl	-1;	.endef
	.align 4
	.def	_bsp_hw_init;	.val	_bsp_hw_init;	.scl	2;	.type	041;	.endef
	.global	_bsp_hw_init
_bsp_hw_init:
	.def	.bf;	.val	.;	.scl	101;	.line	78;	.endef
	.ln	2
	.ln	28
	mov.l	r14, at -r15
	mov	r15,r14
	mov.w	L54,r3
	mov.w	@r3,r1
	extu.w	r1,r1
	.ln	29
	mov.w	L55,r2
	or	r2,r1
	.ln	30
	mov.w	r1, at r3
	.ln	33
	mov.w	L56,r2
	mov	#0,r1
	mov.w	r1, at r2
	.ln	36
	add	#-6,r2
	mov.w	@r2,r1
	extu.w	r1,r0
	.ln	37
	or	#32,r0
	.ln	38
	mov.w	r0, at r2
	.ln	40
	mov	r14,r15
	rts	
	mov.l	@r15+,r14
	.align 1
L54:
	.short	-31816
L55:
	.short	2048
L56:
	.short	-31814
	.def	.ef;	.val	.;	.scl	101;	.line	40;	.endef
	.def	_bsp_hw_init;	.val	.;	.scl	-1;	.endef