I figured. I'll try -O2, thank you.<br><br><br>JM<br><br><div class="gmail_quote">On Thu, Jun 17, 2010 at 3:38 PM, Jiri Gaisler <span dir="ltr"><<a href="mailto:jiri@gaisler.com">jiri@gaisler.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Setting -O0 is equal to wasting ~ 70% of the cpu performance.<br>
Just so you know ....<br>
<br>
Jiri.<br>
<div class="im"><br>
João Rasta wrote:<br>
> Dear all,<br>
><br>
> I have finally managed to solve this issue by using the following<br>
> compilation flags *only* on the autocode library:<br>
><br>
> OPT_OPTS = -O0 -g -fmessage-length=0<br>
><br>
> I suspect of the ffloat-store and O3 optimization flags placed on the<br>
> library makefile by default by matlab, and mabe my answer to Ralf was<br>
> affected by not touch'ing all the project files before compilation.<br>
><br>
> I'm extremely grateful for all your valuable help.<br>
><br>
><br>
> Best,<br>
> JM<br>
><br>
><br>
><br>
> On Thu, Jun 17, 2010 at 12:56 PM, Manuel Coutinho<br>
</div><div class="im">> <<a href="mailto:manuel.coutinho@edisoft.pt">manuel.coutinho@edisoft.pt</a> <mailto:<a href="mailto:manuel.coutinho@edisoft.pt">manuel.coutinho@edisoft.pt</a>>> wrote:<br>
><br>
> Hi<br>
><br>
> Are you sure you are using the correct baud rate to comunicate with<br>
> the board (using GRMON)?<br>
> Did you try different baud rates?<br>
><br>
><br>
> Regards<br>
><br>
> Manuel Coutinho<br>
> Software Engineer - Space<br>
><br>
> EDISOFT, S.A.<br>
> Rua Quinta dos Medronheiros - Lazarim<br>
> Apartado 382 Monte de Caparica<br>
> 2826-801 Caparica Portugal<br>
> Tel: (+351) 212 945 900<br>
> Fax: (+351) 212 945 999<br>
><br>
><br>
><br>
> ------------------------------------------------------------------------<br>
> *From:* <a href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a><br>
> <mailto:<a href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a>><br>
> [mailto:<a href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a><br>
> <mailto:<a href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a>>] *On Behalf Of *João Rasta<br>
> *Sent:* Thursday, June 17, 2010 10:33 AM<br>
><br>
> *To:* Ralf Corsepius<br>
</div>> *Cc:* <a href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a> <mailto:<a href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>><br>
<div><div></div><div class="h5">> *Subject:* Re: rtems with matlab autocode problems<br>
><br>
> Well, i'm using regular printf. I would not point to the<br>
> encoding since it allways prints the same thing no matter what i<br>
> pass to printf().<br>
><br>
> I removed the 3 optimization in the gcc flags and removed the<br>
> other ones and the same problem occurs. If i remove the printf<br>
> the application exits on the following instruction<br>
><br>
> IU in error mode (tt = 0x2b)<br>
> 4000ca8c d127bfec st %f8, [%fp - 0x14]<br>
><br>
> . I'm initializing rtems with:<br>
><br>
> #define CONFIGURE_INIT<br>
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER<br>
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER<br>
><br>
> #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 10<br>
> #define CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE (300*1024)<br>
><br>
> #define CONFIGURE_MAXIMUM_POSIX_THREADS 10<br>
> #define CONFIGURE_MAXIMUM_POSIX_MUTEXES 10<br>
> #define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES 5<br>
><br>
> #define CONFIGURE_POSIX_INIT_THREAD_TABLE<br>
><br>
> I think i have enough stack space.<br>
> Also, if i point CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT to a<br>
> function declared on the autocode the printfs do not work well,<br>
> which does not happen if i point it to a function declared on<br>
> the main code.<br>
><br>
> The autocode is compiled with sparc-rtems-gcc and a library<br>
> libgnc.a is created which is then passed to the compiler at link<br>
> time with -lgnc. The library is created with<br>
><br>
> ar ruvs libgnc.a *.o<br>
><br>
> Does it make sense that there may be a problem with the compiled<br>
> .o's of the library? If so, how can its declared functions be<br>
> messing up with memory operations and not on the main code? They<br>
> use the same compiler..<br>
><br>
><br>
> Best,<br>
> JM<br>
><br>
> On Thu, Jun 17, 2010 at 4:18 AM, Ralf Corsepius<br>
</div></div><div><div></div><div class="h5">> <<a href="mailto:ralf.corsepius@rtems.org">ralf.corsepius@rtems.org</a> <mailto:<a href="mailto:ralf.corsepius@rtems.org">ralf.corsepius@rtems.org</a>>> wrote:<br>
><br>
> On 06/16/2010 07:48 PM, João Rasta wrote:<br>
><br>
> Yes, here goes<br>
><br>
> // dummy printf test code<br>
> int upa(void)<br>
> {<br>
> int i = 0;<br>
><br>
> for (i=0; i< 20; i++)<br>
> printf("B\n");<br>
><br>
> exit(0);<br>
><br>
> }<br>
><br>
> And the result is:<br>
><br>
><br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
> ¬ÖUf<br>
><br>
> Program exited normally.<br>
><br>
> Hmm, I am seeing "4 characters per line" instead of "1 or 2<br>
> characters per line" as one would expect.<br>
><br>
> Are you sure your code uses the right printf? 4 chars<br>
> instead of 1 could indicate using UTF8 or UTF16 encoding<br>
> instead of ACSII.<br>
><br>
><br>
> sparc-rtems-gcc -c -O3 -g3 -ffloat-store -fPIC<br>
> -DUSE_RTMODEL -DMODEL=gnc<br>
> -DRT -DNUMST=1 -DTID01EQ=0 -DNCSTATES=0 -DUNIX -DMT=0<br>
> -DHAVESTDI<br>
> O -I. -I../../rtwlt/matlab/simulink/include<br>
> -I../../rtwlt/matlab/extern/include<br>
> -I../../rtwlt/matlab/rtw/c/src<br>
> -I../../rtwlt/matlab/rtw/c/<br>
> src/ext_mode/common -I. -I..<br>
> -I../../rtwlt/matlab/rtw/c/libsrc<br>
> ../../rtwlt/matlab/rtw/c/src/rt_sim.c<br>
><br>
><br>
> ... -O3 -g3 -ffloat-store -fPIC<br>
> certainly leave room for speculation on incompatibility.<br>
><br>
> -03 ... switches on dangerous optimizations<br>
> -ffloat-store ... could be incompatible to rtems-gcc/newlib<br>
> -fPIC ... unneeded, unused by the rtems-toolchains, unknown<br>
> side effects on rtems-gcc/newlib<br>
><br>
> Ralf<br>
><br>
><br>
><br>
><br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> rtems-users mailing list<br>
> <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
</div></div></blockquote></div><br>