1/1 
|
or32-...- Compiler differencies
by lexxsu on Sep 25, 2012 |
lexxsu
Posts: 2 Joined: Oct 29, 2009 Last seen: Dec 17, 2025 |
||
|
We are using OR1200 with some h/w (f/w) for a long time (old rtl version). I'm not so good in Linux compilers (mostly h/w) and don't fully understand this situation:
Current compiler is old version under uclinux (cygwin) and where are some issues with it (not so serious, but anyway I'm not fully satisfied with it) and I'd like to change into new one. But there are many differences in compiled code: after objdump lst file have a different structure that we currently use now. Previous one starting from _reset_vectors-0x100 and looks like this (http://www.rte.se/blog/blogg-modesty-corex/writing-application-program/2.5) and new one is different (starting from section text, no h/w interrupt code, no other interrupts). Compiled code are different and not working. Also where is a question is the nay differences related to CPU, because our version is quite old and I�m not sure that new compiler (newlib) can work well with it. |
|||
|
RE: or32-...- Compiler differencies
by jeremybennett on Sep 25, 2012 |
jeremybennett
Posts: 815 Joined: May 29, 2008 Last seen: Jun 13, 2019 |
||
|
We are using OR1200 with some h/w (f/w) for a long time (old rtl version). I'm not so good in Linux compilers (mostly h/w) and don't fully understand this situation:
Current compiler is old version under uclinux (cygwin) and where are some issues with it (not so serious, but anyway I'm not fully satisfied with it) and I'd like to change into new one. But there are many differences in compiled code: after objdump lst file have a different structure that we currently use now. Previous one starting from _reset_vectors-0x100 and looks like this (http://www.rte.se/blog/blogg-modesty-corex/writing-application-program/2.5) and new one is different (starting from section text, no h/w interrupt code, no other interrupts). Compiled code are different and not working. Also where is a question is the nay differences related to CPU, because our version is quite old and I�¢ï¿½ï¿½m not sure that new compiler (newlib) can work well with it. Hi lexxsu, You'll need to be more specific about which versions of the compiler you mean. Can you run "or32-elf-gcc --version" on each and report the output here. Best wishes, Jeremy
-- |
|||
|
RE: or32-...- Compiler differencies
by lexxsu on Sep 25, 2012 |
lexxsu
Posts: 2 Joined: Oct 29, 2009 Last seen: Dec 17, 2025 |
||
|
we use uclinux (cygwin): or32-uclinux-gcc 3.1 20020121 (experimental)
for new one I've download image for VirtualBox: 4.5.1-or32-1.0rc4 Where are some updates for rtl code, not related to logic, but anyway it's looks where are many differences, because during executing pc counter going out of f/w area (with new compiler) |
|||
|
RE: or32-...- Compiler differencies
by jeremybennett on Sep 25, 2012 |
jeremybennett
Posts: 815 Joined: May 29, 2008 Last seen: Jun 13, 2019 |
||
|
we use uclinux (cygwin): or32-uclinux-gcc 3.1 20020121 (experimental)
for new one I've download image for VirtualBox: 4.5.1-or32-1.0rc4 Where are some updates for rtl code, not related to logic, but anyway it's looks where are many differences, because during executing pc counter going out of f/w area (with new compiler) Hi lexxsu When you said "old" you really meant it. I've never seen that compiler version. The current stable version of the compiler is 4.5.1, which is so far ahead of 3.1 (different major version number) as to bear little relation to what you are using. It comes in two flavours, or32-elf for bare metal use and or32-linux for compiling Linux applications. The one significant change you may notice is that global symbols are no longer prefixed by '_'. The actual code generated will be completely different - 10 years of compiler optimization development has an effect. There is a also a development version of the compiler, based on the forthcoming GCC 4.8 code base. Depending on your requirements, there are a number of companies (my own included) offering commercial support for these compilers. HTH, Jeremy |
|||
1/1