This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc porting


Soha Eyal-RM50194 wrote:
1) The processor has a heap but possibly no stack at all.

A stack is a software concept. The only way that you can not have a stack is if your OS does not provide one to user processes. I know of a Cray OS in that category, but that would be extremely unusual for a microprocessor OS.


Perhaps you mean that there is no architected stack pointer register? We can use any register that can hold addresses, but there does need to be one reserved for this purpose. A C compiler will not work without one.

Worst case, you can dedicate an easy to access region of memory, e.g. zero-page memory, to serve as a register bank. This will work, but will give poor code quality. Some microcontroller ports do this. You want to do this only if having a C compiler is more important than having good quality code.

2) The processor has a general-purpose register that is written to by an outside source but can be accessed as any other GPR. It can be thought of as a "volatile" register. We'd like to be able to access the value there in some natural manner. Is that possible? Has this been done before?

Access how? From C language code? From compiler internals?


We have various asm constructs that can be used from C code to access specific hardware registers or hardware instructions. You can also use builtin functions as Mike mentioned.

From compiler internals, if you define the register, you can access it.

3) How long might it take to port a back end? Assume our team is 2-3 software engineers, all with strong backgrounds in c programming, basic knowledge of compiler principles, plenty of experience with using gcc, but no experience with the code of gcc. Any estimates or accounts of previous similar projects would be helpful!

Mike Stump says 2 months. I'll say 3. Don't forget that you will also need a binutils port, perferably before the compiler port. You will also need a library port (e.g. newlib), and a gdb port. And maybe also a simulator port (see gdb) if you don't already have one, or convenient hardware.


4) What kind of help is available for writing the port? Are there experience engineers willing to do work by contract? What free help is available by way of the GCC community?

Mike answered this.


5) What are the legal implications of the GPL on the back end? As I understand, any back end distributed by Freescale would need to include source code or access to the code, but until Freescale starts distributing the back end, it can remain private. I also read that Freescale could sell gcc with the back end or its source for a profit. Is all that correct?

Note that while you can charge money for copies of the compiler, you can't restrict subsequent redistibution. Thus the first person who buys a copy can put it up on the internet, and you might never sell a second copy. You should not expect to be able to make money this way. People who make money sell support, or conveniently prepackaged binaries for people who can't (or don't want to) build their own binaries. No one makes money by selling gcc sources. They are free.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]