Rolf,
This *was* not a known bug...
I have just asked gcc to generate the assembler from the offending piece
of code, and I can understand why it causes a problem. The statement
if (id->asciiI != 'I' ||
id->asciiP != 'P' ||
id->asciiA != 'A' ||
id->asciiC != 'C') {
return S_IPAC_noIpacId; /* Not an IPAC */
}
translates into
movel a2@,d0
andl #16711935,d0 ; 0x00ff00ff
cmpl #4784208,d0
jne L17
movel a2@(4),d0
andl #16711935,d0 ; 0x00ff00ff
cmpl #4259907,d0
jeq L16
L17:
movel #39321606,d0
jra L18
GCC has optimised reading four bytes (spread out amongst eight bytes)
into reading two long words and masking the result for those bytes it is
interested in (this is a bl***y clever optimiser!).
The problem is that GCC has changed the access length from a word to a
long. On our mv167 cards here, a 32-bit read in the short address space
is automatically converted by the VMEchip into two 16-bit reads, which
the IPAC was capable of handling. I guess that your CPU/BSP allows
32-bit accesses within the short address space, but the IPAC carrier
doesn't like this.
Strictly speaking Jeff's comment about making these items volatile is
incorrect, because I know they're all in a PROM on the IPAC module and
hence cannot change at run-time. However this does actually solve the
problem because gcc cuts out the optimisation. Change the beginning of
the ipmCheck routine by adding the volatile keyword to the definition of
id to produce the following:
int ipmCheck (
ushort_t carrier,
ushort_t slot
) {
volatile ipac_idProm_t *id;
char dummy;Ñ
Thanks for the feedback, and appologies for the bug.
-- Andrew
___
.' `. Andrew Johnson, Head of Electronics
/ Royal ) Royal Greenwich Observatory
\ Greenwich Madingley Road, Cambridge, CB3 0EZ
| Observatory Tel: +44 1223 374823 Fax: 374700
+---------- WWW: http://www.ast.cam.ac.uk/~anj
- Replies:
- Re: gnu cross-compiler problem Rolf Keitel
- References:
- gnu cross-compiler problem Rolf Keitel
- Navigate by Date:
- Prev:
Re: Buffer copying? Jeff Hill
- Next:
Re: gnu cross-compiler problem Steve Lewis
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
gnu cross-compiler problem Peregrine McGehee
- Next:
Re: gnu cross-compiler problem Rolf Keitel
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|