port gcc for c51 step by step

gcc does not support c51.

Ian

That's why he's asking how to port GCC to the c51.

However, simply googling for "hot to port gcc" would have answered his question, so anybody who asks such a question (in the wrong foum to boot) probably has no no chance at all of porting gcc.

--
Grant Edwards                   grante             Yow!  They don't hire
                                  at               PERSONAL PINHEADS,
                               visi.com            Mr. Toad!

That would be a long email! If you are looking for opens source 51 compiler try SDCC.

GCC is already available for AVR. Head over to avrfreaks.net.

Regards, Richard.

*Now for ARM Cortex-M3!*

Why not use the SDCC freeware compiler for 8051?

I'd recommend the msp430 (16 bit CPU, very low current), or ARM7TDMI if you need more performance. Both of these have gcc ports.

AVR is good for very small applications. It's much better than a PIC. Atmel has nice intergation of gcc into their IDE, and their debugging options are great! Make sure you get a recent version, though.

Eric

I have to use gcc becouse my problem is here: "how to port gcc for c51 step by step". I know that would be easier to use sdcc or sth else.

Where does this problem come from? Sometimes it's wise to question the question. See GCC Internals,

via Also see "Porting GCC for Dunces,"

As I said before, you cannot use gcc because it does not support the 8051 series of micros.

Ian

Pawel is asking on information on how to port it, so that it *will* support 8051s. Since there are gcc ports for other 8 bitters I see no reason why this could not be done.

See "Using and Porting the GNU Compiler Collection (GCC)" at

( The chances of succeeding in this endeavor for somebody that requests "step by step" instructions, and/or could not find the above link by himself is a different issue. )

I just realized that link is for an older version of GCC. The whole list is here:

I've built a number of GCC versions, just asking the question the way you did indicates you do not understand the magnitude of the task. I believe that the 8051 is too limited in it's archetecture to easily port GCC.

Somewhere in the gcc docs I came across a comment on what features were necessary in a processor to port GCC to it. At the time I read that it suprized me that the AVR was successfully ported, to my knowledge the 8051 and PIC have not been successfully ported to GCC. The fact that it has not been done for these processors indicates that it would be very very hard.

To specifically answer your question take a look here:

This is the "porting GCC for dummies" document that talks about porting GCC.

Paul

IMHO, he should start with porting binutils, including as and ld.

The next step would be designing the binary run-time model and the necessary support routines (which will be libgcc).

The GCC target processor mode is ill suited to the

8051 architecture - the model assumes a RISC processor with plenty of registers (of which the least used will be transformed to in-memory variables if needed).

The addressing structure of 8051 will make the port a real challenge - there's good reason why it's not already made.

I'd recommend to use SDCC instead if 8051 is an absolute necessity as the target.

--

Tauno Voipio
tauno voipio (at) iki fi

I realise that, but the reason gcc does not support the c51 is because of its architecture which has limited stack operations. In other words I think it is not possible to provide gcc support for the c51.

Ian

magnitude of the task.

necessary in a processor

successfully ported, to my knowledge the 8051 and PIC have not been

processors indicates that

There are various reasons why some micros have gcc ports, and others do not. By far the biggest is whether there is someone capable and willing to do the port. Certainly there are some micros that are easier than others, but there is no fundamental reason why a gcc port for the 8051 or even the PIC cannot be made (using a prog_mem solution like the AVR for flash data access). However, generating *good* code for these two micros would be a bigger challenge.

For the PIC, it should be practical to make a reasonable C compiler for the Pic18 family (treating the whole memory as linear), but generating good code for bank switching for the Pic16 would not be easy. And I think you'll probably find that anyone at all interested in how their cpu works will have chosen a different processor, so that while there may be many who would want to *use* a pic-gcc port, there are few who would want to write one.

For the 8051, there is more potential for a gcc port. It would be easier than for the PIC, but harder than for the AVR. I suspect the biggest sticking point here is SDCC - since there is already a perfectly good open source C compiler for the 8051, why write another one? A gcc port has the potential to be superior (having the advantage of its excellent front end), but it would be a lot of work for a little gain.

Paul wrote: "[..]

[..]"

Just because a processor is not listed on the GCC website, it does not have to be the case that it is not already ported and actively maintained for GCC.

E.g. the MIL-STD-1750A used to have a configuration in GCC (the GNU C Compiler as it had been then) supported by the Free Software Foundation, but even after it was culled from GNU.org it was still privately maintained in a commercial product.

However, even if a target never appeared in a Free Software Foundation version, it is still possible that it is supported by someone else. E.g. Microchip does at least claim to have a pic30 port of GCC, which I have never used but over seven months ago I did check some files from mplabal30_v1_20_03.tar.gz and mplabc30_v1_20_03.tar.gz , they are the public miscellanous low level GNU tools including binutils and the GNU Compiler Collection, however they do contain extra code for the Microchip dsPIC30F family which is not contained in mainstream GNU distributions (e.g. the more recent binutils version 2.16.x and GCC version 4.x do not come with dsPIC30F support). It seems to be indicated on

that Microchip still offers GCC as that webpage is dated "7 April 2006".

Perhaps Microchip never submitted this code to the Free Software Foundati "[..]

For the 8051, there is more potential for a gcc port. It would be easier than for the PIC, but harder than for the AVR. I suspect the biggest sticking point here is SDCC - since there is already a perfectly good open source C compiler for the 8051, why write another one? [..]"

Perhaps it is a project for university. One is often required at university to produce something through effort rather than obtaining an already made option.

There are certainly many ports of gcc outside the official tree. For example, the msp430 port is a solid and port with strong development outside the official tree (although their binutils ports are part of the official binutils tree). There are many reasons why a port might not be part of the main tree - to be part of the tree requires a serious commitment on the part of the port maintainers, as they have to follow the timelines for the rest of gcc. The gcc maintainers make a number of requirements, including technical ones (code quality, style, etc.), legal ones (copyright attributions), and beurocratic ones (such as who is allowed to commit changes). This is vital for gcc, to ensure that each release works well for all its targets, but many port maintainers don't want to go through this process. Even large, commercially backed gcc ports such as for the Nios II and the Microblaze are not part of the main tree - the companies behind these ports want to have tighter control of their releases. The same applies to binutils, although to a lesser extent.

The Pic30 architecture is very significantly different to the Pic16, and would be much easier (though not easy) to use with gcc.

Hi,

Yes, it's a university projekt. Thank you for your time.

Pawel_O

Uzytkownik "Col> "[..]

As does lcc, which in other respects would be easier to build a machine description for.

If this is a compiler course, it would probably be of greater educational value to start at the other end, with perhaps a C subset, and build a compiler from first principles that is tailored to the quirks of this target. Working with a behemoth such as gcc must have limited value for students.

I should clarify. lcc doesn't assume 'RISC' -- it handles both CISC (x86, 68K, VAX and I have made a PDP-11 target) and RISC (SPARC, MIPS, etc) targets well -- but it does like plenty of registers, and has a few other built-in assumptions that clash with the tinier architectures.

That's simple enough -- you just don't use the hardware stack: you implement one in software. Other C compilers do that for the 8051, I see no reason why GCC couldn't.

I don't see why not. It may not be fun, it may not be practical, but I would think it almost certainly possible.

--
Grant Edwards                   grante             Yow!  KARL MALDEN'S NOSE
                                  at               just won an ACADEMY AWARD!!
                               visi.com