[ECOS] ARM SDT2.51 vs arm-elf-gcc

[ECOS] ARM SDT2.51 vs arm-elf-gcc

[dnt ly]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=big5; format=flowed, Size: 1272 bytes --]

       
   I had a code which decode data, I compiled it using both 
arm-elf-gcc(2.95/3.0) and ARM SDT2.51, and run it in test board, text 
generated by ARM SDT2.51 is very fast than genereated by 
arm-elf-gcc(2.95)(17.3 ms VS 70.2ms). I try the following simple code, and 
get different asm code:

      int i = 1000000;
      while(i--);

ARM SDT2.51:
	0xc12e38c: mov r0, #0x240
	0xc12e390: add r0, r0, #0xf4000

	0xc12e394: subs r0, r0, #0x1
	0xc12e398: bcs 0xc12e394

arm-elf-gcc(2.95/3.0):
	0xc145c0c: ldr r2, 0xc145c48

	0xc145c10: sub r2, r2, 0x1
	0xc145c14: cmn r2, 0x1
	0xc145c18: bne c145c10

       Is it that arm-elf-gcc(2.95) have not optimized full with ARM 
instructions? anyone can help me or where can I get/buy arm-elf-gcc that 
optimized full with ARM instructions?

      Or are there any way to compile eCos using  arm-elf-gcc, compile my 
application using ARM SDT, link them together?





_________________________________________________________________
MSN ¬Ûï´£¨Ñ±z³Ì²³æªº¤è¦¡¤À¨É¨Ã¦C¦L±zªº¬Û¤ù¡A½Ð²¾¦Ü
http://photos.msn.com/support/worldwide.aspx¡C


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[David Airlie]

arm-elf-gcc does produce crap ARM code, don't bother trying 3.0.4 I'll 
save you the bother it produces code the same level of crapiness as 2.95.3 
:-)

you might have a hope of getting the object linking using ADS the newer 
ARM stuff and gcc objects.. debugging would of course be impossible,

Dave.

On Thu, 11 Apr 2002, dnt ly wrote:

>        
>    I had a code which decode data, I compiled it using both 
> arm-elf-gcc(2.95/3.0) and ARM SDT2.51, and run it in test board, text 
> generated by ARM SDT2.51 is very fast than genereated by 
> arm-elf-gcc(2.95)(17.3 ms VS 70.2ms). I try the following simple code, and 
> get different asm code:
> 
>       int i = 1000000;
>       while(i--);
> 
> ARM SDT2.51:
> 	0xc12e38c: mov r0, #0x240
> 	0xc12e390: add r0, r0, #0xf4000
> 
> 	0xc12e394: subs r0, r0, #0x1
> 	0xc12e398: bcs 0xc12e394
> 
> arm-elf-gcc(2.95/3.0):
> 	0xc145c0c: ldr r2, 0xc145c48
> 
> 	0xc145c10: sub r2, r2, 0x1
> 	0xc145c14: cmn r2, 0x1
> 	0xc145c18: bne c145c10
> 
>        Is it that arm-elf-gcc(2.95) have not optimized full with ARM 
> instructions? anyone can help me or where can I get/buy arm-elf-gcc that 
> optimized full with ARM instructions?
> 
>       Or are there any way to compile eCos using  arm-elf-gcc, compile my 
> application using ARM SDT, link them together?
> 
> 
> 
> 
> 
> _________________________________________________________________
> MSN ¬Ûï´£¨Ñ±z³Ì²³æªº¤è¦¡¤À¨É¨Ã¦C¦L±zªº¬Û¤ù¡A½Ð²¾¦Ü
> http://photos.msn.com/support/worldwide.aspx¡C
> 
> 
> 

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[dnt ly]

Hi, David:
   I am afraid of shorting time to read ARM manuals, will you send me the 
extract functions that you've done?

  BTW, I have linked successfully, but can't get subroutine call's address 
correctly(offset 2 instructions) which I post before, does these functions 
affect linking results?

   Thanks in advance.

Best Regards,
LDT

>
>Oh yeah I forgot to give the rest of the information..
>
>you need to extract some function from ADS's ARM library and you also need
>to implement the __rt_raise() function yourself .. this is sort of
>documented in the ARM manuals...
>
>I needed to extract rt_memcpy.o, rt_udiv.o rt_div0.o rt_memcpy_w.o using
>them armar -x command, and I took them from the c_a__un.b library, the arm
>documents what libs are what also ... different ones for big/little
>endian, interworking, floating point, arm/thumb...
>


_________________________________________________________________
礎b http://explorer.msn.com.hk/intl.asp 禮K繞O瞻U繡羹 MSN Explorer


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[David Airlie]

> Aren't there any licensing issues with such an interlinking?
> Can you just use them publically or such experiments are just for fun?
> I ask because I don't have a clue about ADS's licence.
> Jani.

I've been thinking about this, and currently it is just for fun, but there
should be no problems, my assumption is that eCos allows anything to be
linked against it, closed source, BSD licensed etc.. the ARM lib is the
same as you can't do much with the ARM compiler otherwise, and that
extracting the .o files from the ARM library is not a problem as I'm only
doing what the linker normally would do (armlibs crash my ld...)...

Dave.

 > 
> On 15 Apr 2002, David Airlie wrote:
> 
> >
> > Oh yeah I forgot to give the rest of the information..
> >
> > you need to extract some function from ADS's ARM library and you also need
> > to implement the __rt_raise() function yourself .. this is sort of
> > documented in the ARM manuals...
> >
> > I needed to extract rt_memcpy.o, rt_udiv.o rt_div0.o rt_memcpy_w.o using
> > them armar -x command, and I took them from the c_a__un.b library, the arm
> > documents what libs are what also ... different ones for big/little
> > endian, interworking, floating point, arm/thumb...
> >
> > Dave.
> >
> 
> 
> 

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[Jani Monoses]

Aren't there any licensing issues with such an interlinking?
Can you just use them publically or such experiments are just for fun?
I ask because I don't have a clue about ADS's licence.
Jani.

On 15 Apr 2002, David Airlie wrote:

>
> Oh yeah I forgot to give the rest of the information..
>
> you need to extract some function from ADS's ARM library and you also need
> to implement the __rt_raise() function yourself .. this is sort of
> documented in the ARM manuals...
>
> I needed to extract rt_memcpy.o, rt_udiv.o rt_div0.o rt_memcpy_w.o using
> them armar -x command, and I took them from the c_a__un.b library, the arm
> documents what libs are what also ... different ones for big/little
> endian, interworking, floating point, arm/thumb...
>
> Dave.
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[David Airlie]

Oh yeah I forgot to give the rest of the information..

you need to extract some function from ADS's ARM library and you also need 
to implement the __rt_raise() function yourself .. this is sort of 
documented in the ARM manuals... 

I needed to extract rt_memcpy.o, rt_udiv.o rt_div0.o rt_memcpy_w.o using 
them armar -x command, and I took them from the c_a__un.b library, the arm 
documents what libs are what also ... different ones for big/little 
endian, interworking, floating point, arm/thumb...

Dave.

On Sat, 13 Apr 2002, dnt ly wrote:

> 
> >>
> >>I've attached the script perhaps other might find it useful,
> >thanks!
> >>I've also put the build down on my development board and it didn't 
> >>work,
> >>it boots, the idle thread seems to be running but not of my user 
> >>threads
> >>seem to get started, might get some time to hack on it over the 
> >>next while
> >>..
> >I have done it with a test code(compile with ADS), and finsh linking 
> >it,
> >but the test code which call malloc and free can't link correctly 
> >address
> >which in eCos libarary. have you had problem in it?
> here is my code and assember
> 
> compile 'getsystemlanuage' in ADSv1.1 and link with arm-elf-ld(2.95.3).
> any one can help me?
> 
> 
> char *getsystemlanuage(int id)
> {
> 	char *p;
> 	...
> 	p = (char*)malloc( 32 );
> 	...
> }
> 
> 
> 0c1205a8 <getsystemlanuage>:
>  c1205a8:	e92d4038 	stmdb	sp!, {r3, r4, r5, lr}
>  c1205ac:	e1a05000 	mov	r5, r0
>  c1205b0:	e3a04000 	mov	r4, #0	; 0x0
>  c1205b4:	e3a00064 	mov	r0, #100	; 0x64
>  c1205b8:	eb0058fc 	bl	c1369b0 <free+0x18> 
>                   ^^^^^^^^^^^^^^^^^  
>  c1205bc:	e1a01000 	mov	r1, r0
>  c1205c0:	e5c15000 	strb	r5, [r1]
>  c1205c4:	e1a00001 	mov	r0, r1
>  ...
>  
> 0c136998 <free>:
>  c136998:	e1a0c00d 	mov	r12, sp
>  c13699c:	e92dd800 	stmdb	sp!, {r11, r12, lr, pc}
>  c1369a0:	e24cb004 	sub	r11, r12, #4	; 0x4
>  c1369a4:	e24dd004 	sub	sp, sp, #4	; 0x4
>  c1369a8:	e50b0010 	str	r0, [r11, -#16]
>  c1369ac:	e51b0010 	ldr	r0, [r11, -#16]
>  c1369b0:	ebffff8c 	bl	c1367e8 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  c1369b4:	e91ba800 	ldmdb	r11, {r11, sp, pc}
> 
> vvvvvvvvvvvvvvvvvvv
> 0c1369b8 <malloc>:
>  c1369b8:	e1a0c00d 	mov	r12, sp
>  c1369bc:	e92dd800 	stmdb	sp!, {r11, r12, lr, pc}
>  c1369c0:	e24cb004 	sub	r11, r12, #4	; 0x4
>  c1369c4:	e24dd004 	sub	sp, sp, #4	; 0x4
>  c1369c8:	e50b0010 	str	r0, [r11, -#16]
>  c1369cc:	e59f3018 	ldr	r3, [pc, #18]	; c1369ec <malloc+0x34>
> ...
> 
> 
> _________________________________________________________________
> ¦b http://explorer.msn.com.hk/intl.asp §K¶O¤U¸ü MSN Explorer
> 

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[dnt ly]

>>
>>I've attached the script perhaps other might find it useful,
>thanks!
>>I've also put the build down on my development board and it didn't 
>>work,
>>it boots, the idle thread seems to be running but not of my user 
>>threads
>>seem to get started, might get some time to hack on it over the 
>>next while
>>..
>I have done it with a test code(compile with ADS), and finsh linking 
>it,
>but the test code which call malloc and free can't link correctly 
>address
>which in eCos libarary. have you had problem in it?
here is my code and assember

compile 'getsystemlanuage' in ADSv1.1 and link with arm-elf-ld(2.95.3).
any one can help me?


char *getsystemlanuage(int id)
{
	char *p;
	...
	p = (char*)malloc( 32 );
	...
}


0c1205a8 <getsystemlanuage>:
 c1205a8:	e92d4038 	stmdb	sp!, {r3, r4, r5, lr}
 c1205ac:	e1a05000 	mov	r5, r0
 c1205b0:	e3a04000 	mov	r4, #0	; 0x0
 c1205b4:	e3a00064 	mov	r0, #100	; 0x64
 c1205b8:	eb0058fc 	bl	c1369b0 <free+0x18> 
                  ^^^^^^^^^^^^^^^^^  
 c1205bc:	e1a01000 	mov	r1, r0
 c1205c0:	e5c15000 	strb	r5, [r1]
 c1205c4:	e1a00001 	mov	r0, r1
 ...
 
0c136998 <free>:
 c136998:	e1a0c00d 	mov	r12, sp
 c13699c:	e92dd800 	stmdb	sp!, {r11, r12, lr, pc}
 c1369a0:	e24cb004 	sub	r11, r12, #4	; 0x4
 c1369a4:	e24dd004 	sub	sp, sp, #4	; 0x4
 c1369a8:	e50b0010 	str	r0, [r11, -#16]
 c1369ac:	e51b0010 	ldr	r0, [r11, -#16]
 c1369b0:	ebffff8c 	bl	c1367e8 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 c1369b4:	e91ba800 	ldmdb	r11, {r11, sp, pc}

vvvvvvvvvvvvvvvvvvv
0c1369b8 <malloc>:
 c1369b8:	e1a0c00d 	mov	r12, sp
 c1369bc:	e92dd800 	stmdb	sp!, {r11, r12, lr, pc}
 c1369c0:	e24cb004 	sub	r11, r12, #4	; 0x4
 c1369c4:	e24dd004 	sub	sp, sp, #4	; 0x4
 c1369c8:	e50b0010 	str	r0, [r11, -#16]
 c1369cc:	e59f3018 	ldr	r3, [pc, #18]	; c1369ec <malloc+0x34>
...


_________________________________________________________________
礎b http://explorer.msn.com.hk/intl.asp 禮K繞O瞻U繡羹 MSN Explorer


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[dnt ly]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=big5; format=flowed, Size: 866 bytes --]

>
>I've attached the script perhaps other might find it useful,
thanks!
>I've also put the build down on my development board and it didn't work,
>it boots, the idle thread seems to be running but not of my user threads
>seem to get started, might get some time to hack on it over the next while
>..
I have done it with a test code(compile with ADS), and finsh linking it, 
but the test code which call malloc and free can't link correctly address 
which in eCos libarary. have you had problem in it?

LDT

_________________________________________________________________
MSN ¬Ûï´£¨Ñ±z³Ì²³æªº¤è¦¡¤À¨É¨Ã¦C¦L±zªº¬Û¤ù¡A½Ð²¾¦Ü
http://photos.msn.com/support/worldwide.aspx¡C


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[David Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 567 bytes --]


> will you send me the script which you have made modification!

I've attached the script perhaps other might find it useful, 

I've also put the build down on my development board and it didn't work, 
it boots, the idle thread seems to be running but not of my user threads 
seem to get started, might get some time to hack on it over the next while 
..

Dave.

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com

[-- Attachment #2: Type: TEXT/PLAIN, Size: 3136 bytes --]

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



 





























 

 






























































































STARTUP(vectors.o)
ENTRY(reset_vector)

INPUT(extras.o)

GROUP(libtarget.a libgcc.a)


OUTPUT_FORMAT(elf32-bigarm)



 









































 












 

 




 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 




 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 

 
 






 
 




 
 
 




 
 

 
 

 

 


 
 
 
 
 
 
 
 
 



 
 
 


 




 


MEMORY
{
    ram : ORIGIN = 0x380000, LENGTH = 0x80000
}

SECTIONS
{
    .debug_aranges  0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info     0 : { *(.debug_info) } .debug_abbrev   0 : { *(.debug_abbrev) } .debug_line     0 : { *(.debug_line) } .debug_frame    0 : { *(.debug_frame) } .debug_str      0 : { *(.debug_str) } .debug_loc      0 : { *(.debug_loc) } .debug_macinfo  0 : { *(.debug_macinfo) } 
    .fixed_vectors   0x380020  :      { . = . ; KEEP (*(.fixed_vectors)) } >  ram  
    .rom_vectors   0x388000  :      { . = . ; KEEP (*(.vectors)) } >  ram  
    .text   ALIGN (0x4)  :      { _stext = ABSOLUTE(.); PROVIDE (__stext = ABSOLUTE(.)); *(.text*) *(i.*) *(.gnu.warning) *(.gnu.linkonce*) *(.init) *(.glue_7) *(.glue_7t) } >  ram  _etext = .; PROVIDE (__etext = .); 
    .fini   ALIGN (0x4)  :      { . = . ; *(.fini) } >  ram  
    .rodata   ALIGN (0x4)  :      { . = . ; *(.rodata*) *(.constdata*) } >  ram  
    .rodata1   ALIGN (0x4)  :      { . = . ; *(.rodata1) } >  ram  
    .fixup   ALIGN (0x4)  :      { . = . ; *(.fixup) } >  ram  
    .gcc_except_table   ALIGN (0x4)  :      { . = . ; *(.gcc_except_table) } >  ram  
    .data   ALIGN (0x4)  :      { __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1)   _GOT1_START_ = ABSOLUTE (.); *(.got1) _GOT1_END_ = ABSOLUTE (.); _GOT2_START_ = ABSOLUTE (.); *(.got2) _GOT2_END_ = ABSOLUTE (.); . = ALIGN (4); KEEP(*( SORT (.ecos.table.*))) ; . = ALIGN (4); __CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*))) __CTOR_END__ = ABSOLUTE (.); __DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*))) __DTOR_END__ = ABSOLUTE (.); *(.dynamic) *(.sdata*) *(.sbss*) . = ALIGN (4); *(.2ram.*) } >  ram  __rom_data_start = LOADADDR (.data); __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .; PROVIDE (edata = .); PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data)); 
    .bss   ALIGN (0x4)  :      { __bss_start = ABSOLUTE (.); *(.scommon) *(.dynbss) *(.bss*) *(COMMON) __bss_end = ABSOLUTE (.); } >  ram  
     __heap1   = ALIGN (0x8);
    . = ALIGN(4); _end = .; PROVIDE (end = .); 
}


[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[dnt ly]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=big5; format=flowed, Size: 1947 bytes --]

>
>
>Well I went on a hack and I've managed to build the Parthus Bluestream
>stack with armcc from ADS 1.1, eCos with arm-elf-gcc 2.95.3, the interface
>and application files with arm-elf-gcc and link it all together with
>arm-elf-ld with a modified linker script and a load of glue :-)
I'll have a try as you say!
>
>I haven't actually put it down on a board ( I don't have one available at
>the moment ), but it linked together fine ... I'd say issues around apcs,
>and structure packing may be the only thing that might hit me ..
>
>Linker script modification were, to the list of .text sections I had to
>add *(i.*) and to the .rodata section I had to add *(.constdata*)

>i. sections are generated with armcc -zo which is like the function/data
>sections from gcc,

will you send me the script which you have made modification!

>if it works on board it'll have been worth the laugh for the reduced code
>size figures :-), now for thumb !!!
and also improve performance(especially for MP3, MPEG, etc) :-)

>
>
>On 11 Apr 2002, David Airlie wrote:
>
> >
> > > >you might have a hope of getting the object linking using ADS the 
newer
> > > >ARM stuff and gcc objects.. debugging would of course be impossible,
> > > have you had a try!
> >
> > I've done it for a trivial example, two files linking via armlink, one
> > object compiled with arm-elf-gcc one with ADS....
> >
> > you have to use ADS as SDT only creates AOF objects not ELF ones ...
> >
> > I'm not sure how well it would work for anything non-trivial .. I might
> > give it a lash for the laugh on a project I'm working on...
> >
> > Dave.
> >
> >
>


_________________________________________________________________
¨Ï¥Î¥þ²y³Ì¦h¤H¨Ï¥Îªº¹q¤l¶l¥óªA°È MSN Hotmail¡A½Ð²¾¦Ü http://www.hotmail.com
¡C


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[David Airlie]

Well I went on a hack and I've managed to build the Parthus Bluestream 
stack with armcc from ADS 1.1, eCos with arm-elf-gcc 2.95.3, the interface 
and application files with arm-elf-gcc and link it all together with 
arm-elf-ld with a modified linker script and a load of glue :-)

I haven't actually put it down on a board ( I don't have one available at 
the moment ), but it linked together fine ... I'd say issues around apcs, 
and structure packing may be the only thing that might hit me ..

Linker script modification were, to the list of .text sections I had to 
add *(i.*) and to the .rodata section I had to add *(.constdata*)

i. sections are generated with armcc -zo which is like the function/data 
sections from gcc, 

if it works on board it'll have been worth the laugh for the reduced code 
size figures :-), now for thumb !!!

Dave.


On 11 Apr 2002, David Airlie wrote:

> 
> > >you might have a hope of getting the object linking using ADS the newer
> > >ARM stuff and gcc objects.. debugging would of course be impossible,
> > have you had a try!
> 
> I've done it for a trivial example, two files linking via armlink, one 
> object compiled with arm-elf-gcc one with ADS....
> 
> you have to use ADS as SDT only creates AOF objects not ELF ones ...
> 
> I'm not sure how well it would work for anything non-trivial .. I might 
> give it a lash for the laugh on a project I'm working on...
> 
> Dave.
> 
> 

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[David Airlie]

> >you might have a hope of getting the object linking using ADS the newer
> >ARM stuff and gcc objects.. debugging would of course be impossible,
> have you had a try!

I've done it for a trivial example, two files linking via armlink, one 
object compiled with arm-elf-gcc one with ADS....

you have to use ADS as SDT only creates AOF objects not ELF ones ...

I'm not sure how well it would work for anything non-trivial .. I might 
give it a lash for the laugh on a project I'm working on...

Dave.

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM SDT2.51 vs arm-elf-gcc

[dnt ly]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=big5; format=flowed, Size: 2341 bytes --]

>
>arm-elf-gcc does produce crap ARM code, don't bother trying 3.0.4 I'll
>save you the bother it produces code the same level of crapiness as 2.95.3
>:-)
yes, I also had tried 3.0.4, 
>
>you might have a hope of getting the object linking using ADS the newer
>ARM stuff and gcc objects.. debugging would of course be impossible,
have you had a try!

>
>
>On Thu, 11 Apr 2002, dnt ly wrote:
>
> >
> >    I had a code which decode data, I compiled it using both
> > arm-elf-gcc(2.95/3.0) and ARM SDT2.51, and run it in test board, text
> > generated by ARM SDT2.51 is very fast than genereated by
> > arm-elf-gcc(2.95)(17.3 ms VS 70.2ms). I try the following simple code, 
and
> > get different asm code:
> >
> >       int i = 1000000;
> >       while(i--);
> >
> > ARM SDT2.51:
> > 	0xc12e38c: mov r0, #0x240
> > 	0xc12e390: add r0, r0, #0xf4000
> >
> > 	0xc12e394: subs r0, r0, #0x1
> > 	0xc12e398: bcs 0xc12e394
> >
> > arm-elf-gcc(2.95/3.0):
> > 	0xc145c0c: ldr r2, 0xc145c48
> >
> > 	0xc145c10: sub r2, r2, 0x1
> > 	0xc145c14: cmn r2, 0x1
> > 	0xc145c18: bne c145c10
> >
> >        Is it that arm-elf-gcc(2.95) have not optimized full with ARM
> > instructions? anyone can help me or where can I get/buy arm-elf-gcc 
that
> > optimized full with ARM instructions?
> >
> >       Or are there any way to compile eCos using  arm-elf-gcc, compile 
my
> > application using ARM SDT, link them together?
> >
> >
> >
> >
> >
> > _________________________________________________________________
> > MSN ¬Ûï´£¨Ñ±z³Ì²³æªº¤è¦¡¤À¨É¨Ã¦C¦L±zªº¬Û¤ù¡A½Ð²¾¦Ü
> > http://photos.msn.com/support/worldwide.aspx¡C
> >
> >
> >
>
>--
>       David Airlie, Software Engineer, Parthus Technologies plc.,
>        Mary Rosse Centre, National Tech Park, Limerick, Ireland.
>    t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com
>
>
>--
>Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
>and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>




_________________________________________________________________
¦b±zªº¦æ°Ê¸Ë¸m¤W¶Ç°e±µ¦¬ Hotmail ¶l¥ó¡A½Ð²¾¦Ü http://mobile.msn.com¡C


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss