Freescale hc11/12 port extension to s12x / xgate
Announce. I have posted some patches to gcc and binutils to better support Freescale S12X and XGATE cores. See: http://www.msextra.com/tools/s12x-20100504.zip This contains rolled up patches against. gcc-3.3.6 binutils-2.18 newlib-1.16-0 The patches include Stephane Carrez' patches and add binutils support for the S12X instructions and XGATE core. gcc contains a hand coded S12X assembler version of udivsi32 which is faster than the original C version. gcc/binutils modified to allow the m9s12x xgate CPU target flags to be passed but do not otherwise use them. Typical Makefile likes would be: CFLAGS = -g -Wall -Werror -O -fomit-frame-pointer -m9s12x -mshort -msoft-reg-count=5 -mauto -incdec -fsigned-char -DGCC_BUILD -Wa,-mm9s12x XFLAGS = -g -Wall -Werror -O -fomit-frame-pointer -m9s12xg -mshort -msoft-reg-count=5 -maut o-incdec -fsigned-char -DGCC_BUILD -Wa,-mxgate XGATE assembly appears functional. Probably best discussed on http://tech.groups.yahoo.com/group/gnu-m68hc11 regards James
Freescale 68HC11/68HC12 port
Unsure if this is the right place to mention this, so excuse me if it is not. The 68hc11/68hc12 port page http://www.gnu.org/software/m68hc11/ is very out of date and was last updated in October 2003. The creator of that port Stephane Carrez is no longer active (to my knowledge) but his page was updated in 2006 and has the current version of the port there. What needs to be done to update the gcc hosted page? >From my testing, the hc11/12 code in the released gccs (3.4.6, 4.5.2) does not work and either needs to be brought up to date (I've tried and failed) or removed. The gcc-3.3.6+Carrez code does work. I have made some small enhancements to the port locally but these are not yet fully verified. If anyone is interested in working on the port, please contact me and I will share my work. James Murray
Re: Freescale 68HC11/68HC12 port
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. James
Re: Freescale 68HC11/68HC12 port (gcc newbie help request)
On Wed, 2011-01-26 at 14:55 +, 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*)(0x)))
#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:
ldab576
clra
andb#1
bne .L2
tfr d,x
bset0,x, #-128
.L2:
ldab576
clra
andb#2
beq .L3
bset0, #64
.L3:
ldabsynch
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
ldab576
clra
eorb#1
anda#0
andb#1
tbeqd,.L2
.LM3:
bset0, #-128
.L2:
ldab576
anda#0
andb#2
tbeqd,.L3
bset0, #64
.L3:
xgdx
clra
ldabsynch
tfr d,x
anda#0
andb#1
tbned,.L4
tfr x,d
anda#0
andb#8
tbned,.L4
tfr x,d
anda#0
andb#16
tbned,.L4
movb#35,1
.L4:
ldd #0
movw2,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
* 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:
ldab576
lsrd
clra
andb#1
beq .L3
.loc 1 17 0
bset0, #64
.L3:
xgdx
clra
ldabsynch
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
Re: Freescale 68HC11/68HC12 port (gcc newbie help request)
On Wed, 2012-03-21 at 15:12 -0700, Ian Lance Taylor wrote: > I can understand why you are doing this. However, you should be aware > that the compiler internals changed significantly in version 4.0. Time > spent working on detailed optimizations of gcc 3.4 is almost certainly > time wasted. Walking forward version by version makes some sense, I > guess, but you shouldn't even look at the optimizations in the generated > code until you get to at least 4.3. Thanks for the advice. After a number of days fumbling around, I think I'm going to concede defeat for the time being (!) I have brought the code forwards a little bit but at each step there are hurdles to overcome, using a current build environment highlights ancient hidden bugs in the gcc code. The m68hc11 code too is frequently struck by ICEs due to insn not matching contraints and the like. The commentary in the 2003 gcc conference proceedings regarding the difficulty of bringing stagnant targets up to date is spot on. Seeing that it took 2 developers from MIPs six months to revive their target... I realise that I do not have the time (or skill) to presently undertake this task. Also the m68hc11 is (was) a minority target. However, I do think I'm able to make some small improvements on the 3.3.6 code for m68hc11 and will use that internally. regards James
hc11/12 port extension to s12x
(First post to gcc mailing list) I have been making use of the Freescale (Motorola) HC11/12 functionality within gcc and binutils on the 9S12C64 target. I plan to extend gcc to cover the newer S12X CPU as the existing compiler only utilises the S12 subset. Is anyone working on this presently? Hopefully I will be working on this with a colleague Ken Culver and we would aim to have some code by the middle of the year. I contacted the existing maintainer of the HC11/12 port Stephane Carrez, but he does not have the time to actively work on it. Additionally I have extended binutils-2.18 to cope with S12X and the XGATE co-processor used in chips like the 9S12XD and 9S12XE families. My code does appear to work but needs a good cleanup and more testing before it is ready for submission. ( http://www.jsm-net.demon.co.uk/xgate ) I have attempted to build gcc-4.3.0 with --target=m6812-elf and using plain binutils-2.18 built with the same target, prefix and program prefix as gcc, however gcc fails: ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function ‘__negdi2’: ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c:80: internal compiler error: Segmentation fault I believe I have attempted to build it correctly as the same configure options passed to a gcc-3.3.6 (with Stephane Carrez's patches applied) builds ok. My host compiler reports: [EMAIL PROTECTED] ~]$ gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c ++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) regards James Murray
Re: hc11/12 port extension to s12x
On Tue, 2008-03-18 at 16:23 -0700, David Daney wrote: > James Murray wrote: > > > I have attempted to build gcc-4.3.0 with --target=m6812-elf and using > > plain binutils-2.18 built with the same target, prefix and program > > prefix as gcc, however gcc fails: > > ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function ‘__negdi2’: > > ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c:80: internal compiler error: > > Segmentation fault > > > > It is unclear to me if you have modified GCC. If so, this page contains > some pointers about debugging GCC: Sorry for the lack of clarity. This was with as-yet unmodified gcc-4.3.0 and unmodified binutils-2.18. > Otherwise if it is an unmodified GCC, you can file a bug report as > explained here: > > http://gcc.gnu.org/bugs.html > OK, I'll give that a go. regards James Murray
