Hi,

The OpenRisc 1200 core compares itself to ARM core with favorable die
size and mips. We would like to know if its program code density is also
better than ARM.

Thanks.
Steve

Hi, Steve, Regarding this issue, I think code density is similar to MIPS. We know MIPS's code density is worse than ARM depending on your application. In addition, good code density doesn't mean good performance. Also, the above is under the assumption that you don't use Thumb and MIPS16 and without performance issue. Jimmy On Sat, 1 Jan 2005 02:22:50 +0100, cadiniatech@yahoo.com cadiniatech@yahoo.com> wrote:


--
-- securing everything online

Aloha! Quoting Jimmy Chen nptmsf@gmail.com>: Last time I checked (which was about a year ago), there difference in code density between ARM and OpenRISC was actually quite large (ARM9, pure 32 bit code). Also the results between LEON and OpenRISC came out in favor of LEON. But, this was for a fairly small set of code of very specific application type so YMMV. What I would like to do is compare OpenRISC code density with MicroBlaze and Nios-II. In my world code density is quite a big issue since it really affects the chip area. Speed is of a lesser concern (even though speed normally corresponds quite nicely to code sice for a single scalar RISC without too many instruction dependency hazards). If you need the speed, you should probably put some of the code in HW instead. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson@informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Hi, Joachim, When you talk about "large difference code density", could you put a number? Then we could understand it better. I ever saw 20% difference in some application. At the same time, it means MIPS32 has the same problem. BTW, code density is an issue. But if you use on-chip ROM, I think it doesn't make much difference since rom cell is not very big. I don't think you put all codes in your on-chip 'sram'. You could compare all on-shelf RISC and decide which is the best chip to use just like which one of Firefox and IE you want to use. In addition, when you decide which one to use, not only code density but also the tool chains, performance and silicon proven, etc, make you puzzled. I think OpenRISC has everything now that keeps growing. Have a good year! Jimmy On Thu, 6 Jan 2005 00:04:08 +0100, Joachim Strombergson Joachim.Strombergson@informasic.com> wrote:


--
-- securing everything online

Would not the resulting code density depend largely on the performance of the compiler and the parser? MicroBlaze, NIOS, LEON, and OR1200 must rely on the GNU compiler while MIPS and ARM can use Green Hills, Mentor Graphics, and other 3rd party tools. Please publish your code density results when available. MVH, -philip -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Joachim Strombergson Sent: Wednesday, January 05, 2005 6:04 PM To: Jimmy Chen; List about OpenRISC project Subject: Re: [openrisc] Code Density Aloha! Quoting Jimmy Chen nptmsf@gmail.com>:
MIPS16
Last time I checked (which was about a year ago), there difference in code density between ARM and OpenRISC was actually quite large (ARM9, pure 32 bit code). Also the results between LEON and OpenRISC came out in favor of LEON. But, this was for a fairly small set of code of very specific application type so YMMV. What I would like to do is compare OpenRISC code density with MicroBlaze and Nios-II. In my world code density is quite a big issue since it really affects the chip area. Speed is of a lesser concern (even though speed normally corresponds quite nicely to code sice for a single scalar RISC without too many instruction dependency hazards). If you need the speed, you should probably put some of the code in HW instead. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson@informasic.com Home: www.informasic.com ---------------------------------------------------------------------- _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

Jimmy Chen nptmsf@gmail.com> writes:

One problem is that the MIPS backend for GCC can generate a lot better
code than the OpenRISC backend. All the official GCC backends for
MIPS, ARM, PowerPC and so on are heavily maintained. People have put
in huge amounts of time to get the backend to generate good, dense and
high performing code.

I was in the process of rewriting the OpenRISC GCC backend, and to
"port" it to the upcoming GCC 4 release. It was quite promising, but
everything was lost in a HD crash :/

Since things like code size is to great importance to the embedded
community, which OpenRISC targets, maybe more time should be spent on
getting GCC into good shape. My suggestion is to rip out the "best"
parts from the MIPS backend and adjust and tweak them to fit into the
OpenRISC picture.

~j