This is the mail archive of the 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]

gcc port to StarCore


I am working on the port of the gcc version 3.0.1 to the StarCore
architecture ( DSP from Motorola/Agere ).

StarCore calling convention requires first two ( numeric or pointer )
parameters to be passed in registers and other ( non-numeric/pointer or
third and higher ) to be passed on stack.

I disabled "movstrsi" definition in my md file and compiled:

struct str
  int x[100];

int foo()
  struct str s;

  bar( s );


Compiler generated the following code:

1. adda #-400,sp,r0 <- first parameter to 'memcpy' - destination
2. move.l (sp-4),d6
3. moveu.l #400,d0
4. move.l d0,(sp-4) <- third parameter to 'memcpy' - count
5. tfra sp,r15
6. move.l r15,d1
7. addnc.w #-800,d1,d0
8. move.l d0,r1  <- second parameter to 'memcpy' - source
9. jsr _memcpy
10. move.l d6,(sp-4)
11. jsr _bar

'bar' excepts one parameter that shall be passed on the ( top ) stack. This
area is set by 'memcpy'. However 'memcpy' requires one of it parameters (
the third - count ) to be passed on the stack potentially interfering with
the data to be copied to.

It seems that compiler recognizes that something is wrong issuing
instruction 2 ( move.l (sp-4),d6, register d6 is saved across the calls ) to
save what is going to be overwritten by instruction 4 ( that pushes the
third parameter to memcpy ) and later issuing instruction 10 ( move.l
d6,(sp-4) ) to restore it. I think it is unnecessary to explain why this is

The above also suggests that using generic ( with no assumptions ) library
calls by the compiler may be inappropriate in certain cases.


David Livshin
Tel:      +972 - 8 - 935 - 4597
Mobile: +972 - 67 - 290 - 998
Laskov 11/31
Rehovot, 76654

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