This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Freescale 68HC11/68HC12 port (gcc newbie help request)


On Wed, 2011-01-26 at 14:55 +0000, James Murray wrote:
> On Wed, 2011-01-26 at 15:40 +0100, Richard Guenther wrote:
> 
> > Stephane Carrez is listed as maintainer of the port, so he should
> > know how to contribute fixes to the port upstream.
> > 
> Yes, but as I said... he is no longer active on this port. His last
> published contributions are 4+ years ago.

I've spent a some time looking at this and can honestly say I'm very
likely out of my depth.

As a first step in bringing the port forwards, I worked on 3.4.4 as that
was fairly contemporary with 3.3.6. I manually applied the changes that
Stephane Carrez had made. The compiler builds and can generate code.

However, the generated code isn't as good as the output from 3.3.6. I
swapped back to unpatched 3.4.4 and compared with unpatched 3.3.6.

Take the following example:

------------
#define PORTA    (*((volatile unsigned char*)(0x0000)))
#define PORTB    (*((volatile unsigned char*)(0x0001)))
#define PORTT    (*((volatile unsigned char*)(0x0240)))

#define SYNC_SYNCED     0x1
#define SYNC_SEMI       0x8
#define SYNC_SEMI2      0x10
extern unsigned char synch;

int main()
{
    if ((PORTT & 0x01) == 0) {
        PORTA |= 0x80;
    }

    if (PORTT & 0x02) {
        PORTA |= 0x40;
    }

    if ( (!(synch & SYNC_SYNCED)) && (!(synch & SYNC_SEMI)) && (!(synch
& SYNC_SEMI2)))  {
        PORTB = 0x23;
    }
    return (0);
}
------------
m68hc11-elf-gcc -g -Wall -Werror -O -fomit-frame-pointer -m68hcs12
-mshort -msoft-reg-count=5 -mauto-incdec -fsigned-char  -S test4.c


With 3.3.6 (unpatched), the resultant code (trimmed) is:

------------
main:
	ldab	576
	clra
	andb	#1
	bne	.L2
	tfr	d,x
	bset	0,x, #-128
.L2:
	ldab	576
	clra
	andb	#2
	beq	.L3
	bset	0, #64
.L3:
	ldab	synch
	clra
	andb	#25
	bne	.L4
	movb	#35,1
.L4:
	clra
	clrb
	rts
------------

The 8bit bit tests are a little sub-optimal, but workable.

Now, with 3.4.4
------------
main:
	movw	_.d1,2,-sp
	ldab	576
	clra
	eorb	#1
	anda	#0
	andb	#1
	tbeq	d,.L2
.LM3:
	bset	0, #-128
.L2:
	ldab	576
	anda	#0
	andb	#2
	tbeq	d,.L3
	bset	0, #64
.L3:
	xgdx
	clra
	ldab	synch
	tfr	d,x
	anda	#0
	andb	#1
	tbne	d,.L4
	tfr	x,d
	anda	#0
	andb	#8
	tbne	d,.L4
	tfr	x,d
	anda	#0
	andb	#16
	tbne	d,.L4
	movb	#35,1
.L4:
	ldd	#0
	movw	2,sp+,_.d1
	rts 

------------
This resultant code is significantly larger and slower. I was able to
backtrack through SVN to the majority of this change:

------------
2003-07-02  Jeff Law  <law@redhat.com>

	* expr.c (do_store_flag): Remove special case folding for
	single bit tests.  Instead call back into the commonized folder
	routine.
	* fold-const.c (fold_single_bit_test): New function, mostly
	extracted from do_store_flag, with an additional case extracted
	from fold.
	(fold): Call fold_single_bit_test appropriately.
	* tree.h (fold_single_bit_test): Prototype.

------------
The changes there adversely impacted the hc11 output. The code generated
immediately after this change is even worse than the 3.4.4 output above
- instead of "andb #8" the code does three right-shifts before "andb #1"
i.e.
-----------
.L2:
	ldab	576
	lsrd
	clra
	andb	#1
	beq	.L3
	.loc 1 17 0
	bset	0, #64
.L3:
	xgdx
	clra
	ldab	synch
	xgdx
	stx	_.d1
	tfr	x,d
	clra
	andb	#1
	bne	.L4
	ldd	_.d1
	lsrd
	lsrd
	lsrd
	clra
	andb	#1
	bne	.L4
	ldd	_.d1
	lsrd
	lsrd
	lsrd
	lsrd
	clra
	andb	#1
	bne	.L4
	movb	#35,1
.L4:
-----------
I'm sure that the changes must have had a positive effect on other
targets, but the core of that code (.L3-.L4) is five times larger than
the 3.3.6 output.

What would be the best approach to address issues like this?
Create new m68hc11.md rules to pick up the newly generated RTL and turn
it back into optimal code or???

i.e. if Stephane Carrez had continued maintaining the m68hc11 target,
how would he have been keeping up with core changes that had a negative
impact on m68hc11 ?

My rationale here is that if I'm unable to make changes to preserve
output code quality for a small change like this, then there is no
chance of me working through the other eight years of changes...(!)

The alternative is that I work on adding a few enhancements to 3.3.6 as
that's what is being used in production by a number of different project
teams.

regards

James Murray

PS. Yes I know I'm quoting a ChangeLog entry from 2003 and also that
m68hc11 has been removed from gcc now. But please humour me..


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]