1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

port gcc for c51 step by step

Discussion in 'Embedded' started by Pawel_O, Jun 9, 2006.

  1. Pawel_O

    Pawel_O Guest

    Hi,
    Please help me.

    Send me same info how to port gcc for c51 step by step.
    What i have to change in files in gcc to do this.
    If c51 is not popular i will be grateful for informations about: avr or z80
    processors.

    Thanks for your time.
    Kind regards,
    Poul from POLAND
     
    Pawel_O, Jun 9, 2006
    #1
    1. Advertisements

  2. Pawel_O

    Ian Bell Guest

    gcc does not support c51.

    Ian
     
    Ian Bell, Jun 9, 2006
    #2
    1. Advertisements

  3. 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, Jun 9, 2006
    #3
  4. Pawel_O

    Richard Guest

    Send me same info how to port gcc for c51 step by step.

    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.

    http://www.FreeRTOS.org
    *Now for ARM Cortex-M3!*
     
    Richard, Jun 10, 2006
    #4
  5. Pawel_O

    Eric Guest

    Send me same info how to port gcc for c51 step by step.

    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
     
    Eric, Jun 10, 2006
    #5
  6. Pawel_O

    Pawel_O Guest

    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.
     
    Pawel_O, Jun 12, 2006
    #6
  7. Pawel_O

    toby Guest

    toby, Jun 12, 2006
    #7
  8. Pawel_O

    Ian Bell Guest

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

    Ian
     
    Ian Bell, Jun 12, 2006
    #8
  9. 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
    http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html

    ( 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. )
     
    Roberto Waltman, Jun 12, 2006
    #9
  10. Roberto Waltman, Jun 12, 2006
    #10
  11. Pawel_O

    pbreed Guest

    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:
    http://www.stillhq.com/pdfdb/000290/data.pdf

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

    Paul
     
    pbreed, Jun 13, 2006
    #11
  12. Pawel_O

    Tauno Voipio Guest

    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, Jun 13, 2006
    #12
  13. Pawel_O

    Ian Bell Guest

    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
     
    Ian Bell, Jun 13, 2006
    #13
  14. Pawel_O

    David Brown Guest

    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.
     
    David Brown, Jun 13, 2006
    #14
  15. 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
    HTTP://WW1.Microchip.com/downloads/en/DeviceDoc/C30_v2_02README.html
    that Microchip still offers GCC as that webpage is dated "7 April 2006".

    Perhaps Microchip never submitted this code to the Free Software
    Foundation or perhaps members of the Free Software Foundation who do not
    deem Microchip's contributions to have a high priority have not added
    these contributions to the mainstream releases (e.g. several months'
    delay can be expected for contributions for some Atmel AVR processors
    before someone with sufficient authority within the Free Software
    Foundation will commit them to be distributed with mainstream
    Free Software Foundation releases but in the meantime they can be
    obtained from the open AVR community such as in the FreeBSD ports
    collection).

    On Tue, 13 Jun 2006, David Brown wrote:

    "[..]

    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.
     
    Colin Paul Gloster, Jun 13, 2006
    #15
  16. Pawel_O

    David Brown Guest

    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.




     
    David Brown, Jun 13, 2006
    #16
  17. Pawel_O

    Pawel_O Guest

    Hi,

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

    Pawel_O




     
    Pawel_O, Jun 13, 2006
    #17
  18. Pawel_O

    toby Guest

    As does lcc, which in other respects would be easier to build a machine
    description for. http://www.cs.princeton.edu/software/lcc/

    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.
     
    toby, Jun 13, 2006
    #18
  19. Pawel_O

    toby Guest

    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.
     
    toby, Jun 13, 2006
    #19
  20. 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, Jun 13, 2006
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.