LPC900/80C51 Compiler Toolchain

snipped-for-privacy@gmail.com schrieb:

We are using the Raisonace tools, and are fairly satisfied with it. It has a good price/performance ratio, compared to other brands.

You might also have a look at for their uC/51 package. It also is rather cheap, and the demo is limited to 8k (which is enough for most LPC900 devices due to their flash sizes). I didn't look at that software deeper yet, however.

Tilmann

--
http://www.autometer.de - Elektronik nach Maß.

In article , snipped-for-privacy@gmail.com writes

I would suggest in this order

Keil IAR Raisonance Rigel SDCC

Keil and IAR are very much more advanced than the rest. Keil particularly can do aggressive data overlaying which is often more crucial than the limit on memory addressing the eval version.

Infact I have known the Keil eval compiler to get programs to fit ant run where the full versions of other programs can not.

SDCC is not what I would call "decent" It may be unlimited but as I said the lack of optimisation means you will run out of Data space and possibly code space.

Also there is a lot more to the 8051 variants than just changing the header files. TO start with the LPC932 has INTERNAL eXternal DATA memory..... The Keil compiler will handle this correctly.

Start with the Keil compiler. I would put the SDCC as a last resort.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Anyone got any figures comparing any of these with gcc? Maybe for a bit of open source software? (e.g. Lewin's DOSFS - or a another similar sized project). How big is it when compiled with gcc, and with any of the above compilers. I'm more interested in code size rather than run-time performance.

Regards,

Paul Taylor.

Doesn't have to be 8051 target.

For code size (I assume you mean both Code and Data data usually being the critical one ) the only options are Keil and IAR in that order. GCC is not in the running.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Then it depends on the target. GCC is closer to commercial performance int he 32 bit areas than the 8 or 16 bit.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

yes

oops - I haven't used/looked at the 8051 for years, and just assumed that gcc was ported to 8051.

As far as I know it is but It would not be a practical answer.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Thanks Chris, that was a very informative answer. I will give Keil a try, and see if my program fits into 4K. All it does is managing I2C, SPI and some GPIO control lines. I think it should be able to do it.

Eugene.

Remember, this is Chris Hills, operating from his anti-open-source bias position. He might even be accurate here.

--
 
 
 
                        cbfalconer at maineline dot net

No, I have to work with hard facts not the fanciful notions of the FOSS Devotee

Gcc is a general purpose system. It is better suited to the 32 bit systems.. Rather than the 8 bit ones especially the 8051.

As has been pointed out GCC uses technology that is about 10-15 years behind the top commercial compilers in the 8-16 bit field.

The problem with the 8061 family is the memory map and the DATA space. In this case the internal eXternal DATA space.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Then there is no open source option for the 8051 at the moment.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

As far as I know, there is no 8051 gcc port. If there was, I'm sure it would be pretty poor for code generation, since gcc (as you said) is aimed more at 32-bit, or at least 16-bit, processors with plenty of registers. 8-bit accumulator based architectures like the 8051 are not a good match.

The "standard" open source compiler for the 8051 is SDCC. I've never used the 8051, so I can't really comment on the tools.

Not at all... not according to the compiler people I know. The most generous comment I heard was that the latest Gcc is at least 5 years behind commercial compilers. They weren't looking at the 8 bit ones either. Others will tell you it is 10 years behind.

However they are not going to tell you how they do it for obvious reasons.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

That's apples and oranges. gcc uses some of the latest compiler technologies, and is way ahead of many (but not all) commercially available compilers *within its field*. There are no gcc ports for the

8051 or similar types of cpu - it is not "behind" or using out-of-date technology, or anything of the kind. In the same way, no one is going to claim ByteCraft's compilers are "out of date" because they don't auto-vectorise loops or re-organise structures to minimise the cost of cache misses - such features are not relevant to targets like the 8051.

Perhaps the only target that could be overlapped by compilers specialised for small targets and gcc is the AVR - it is 8-bit, with separate memory spaces, but has multiple registers and a gcc port. It would be fascinating to know how the sorts of techniques used by ByteCraft, IAR, and other commercial embedded compiler specialists compare to those of gcc.

What do you expect a commercial compiler vendor to tell you - we've got this great expensive compiler, but it is not as advanced as a free and open source one? And where does this mythical time-line come from anyway?

There are many compilers available for many targets, and some are stronger than others in certain ways and for certain types of code. If you need to know details, do a benchmark yourself using your own code - anything else is just ramblings.

FUD alert. Facts please. No hearsay and/or innuendo.

Perhaps because they would need to admit their claims are baseless or exaggerated?

On the other hand, there is a price to be paid for supporting a large number of targets of different types, and vendors that specialize in particular targets (e.g. 8051) will tend to be more optimized in that narrow field.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

I know you meant to say SDCC instead of gcc. But you need to consider that SDCC, although similar to gcc in some respects, was specifically designed to target small devices, hence its name. It also understands the memory architecture of the 8051.

gcc has been ported to generate H8 code, hc11, and I probably others. So it does support some 8-bit targets. I agree that it's nor a "good" code generator for 8 bit targets. gcc likes to see a real software stack and no excessive memory paging, which is why it doesn't support

8051, and PIC.

But gcc does OK with the PIC24/dsPIC devices because those have a "serious" 16 bit architecture that is quite different from the lowly PIC everyone knows (and loves?).

I'm sure this is true in some cases. But I expect that gcc and SDCC lead ahead of commercial compilers in some cases. Commercial compilers are developed and improved whenever there is a reasonable expectation that paying customers will come forward, or continue to come forward. Sometimes decent commercial compilers are not kept up to date because the customer demand might be "soft" for a particular target family of devices.

I'm not against commercial software because I enjoy a pay check as much as anyone else! Open source serves a niche that can't easily be served by commercial software in some cases.

Eric

The h8 and hc11 also have 8 bit accumulators and they are supported by gcc. It's the blasted memory paging and poor stack that make the 8051 such a difficult device to target. These same limitations are seen in the PIC.

Eric