gcc for any microcontroller?

gcc for any microcontroller?

[Petr Danecek]

Hi,
i suppose that gcc cannot be ported to compile just for any
microcontroller. are there any requirements on a microprocessor which it
must fullfil? 
thank you,
petr

Re: gcc for any microcontroller?

[Mike Stump]

On Friday, March 21, 2003, at 04:23 AM, Petr Danecek wrote:
> i suppose that gcc cannot be ported to compile just for any
> microcontroller. are there any requirements on a microprocessor which 
> it
> must fullfil?

Yes, turing completeness is a requirement.  :-)  Ok, stop laughing...

16+ bit address space, 8/16 bit operations, byte addressing, ability to 
fetch memory from arbitrary place with uniform instructions, register 
architecture...  The closer the processor is to real, the easier it 
will be to port.

Re: gcc for any microcontroller?

[tm_gccmail]

On 21 Mar 2003, Petr Danecek wrote:

> Hi,
> i suppose that gcc cannot be ported to compile just for any
> microcontroller. are there any requirements on a microprocessor which it
> must fullfil? 
> thank you,
> petr

Since I'm a processor geek, I'll take a fling at answering this one.

Yes, probably gcc can be ported for any microcontroller. The real question
is whether a good port can be done for a microcontroller.

GCC emits good code for processors which have:

o Many general-purpose registers
o Orthogonal and reasonable addresing modes
o Few or no special-purpose registers
o Homogenous memory space

GCC has trouble generating code for processors which have:

o Few or no general-purpose registers

  Many microcontrollers use an accumulator-based architecture, which does
  not work with common register allocation algorithms at all, so you wind
  up emulating general-purpose registers using strange techniques.

  Also, stack-based architectures are difficult to accomodate as well.

  Applies to: 68HC11, 8051, Z80, 6502, PicoJava, x86 FPU, etc.

o Lack of standard addressing modes

  Some processors have no or very few bits of displacement on the indirect
  addressing mode, which causes gcc problems. Unfortunately, some people
  are publishing papers which say "you don't need displacement addressing
  modes because they can be easily simulated" (Crispin Cowan, etc) and
  some processors have actually been built without displacement addressing
  modes. This problem complicates many optimizations including CSE, loop
  optimizations, instruction scheduling, etc.

  Applies to: NIW architecture, IA64, etc.

o Many special-purpose registers

  This complicates register allocation and instruction scheduling greatly,
  and makes code generation very difficult.

  Applies to: SH, etc

o Special areas of memory which can only be accessed by special addressing
  modes and/or banked memory

  This usually applies to DSPs and DSP-like processors which have internal
  memory which can be accessed in parallel with the external bus, or to
  funky processors that have been extended past their normal lifespan by
  artificially extending the address space.

  Applies to: 8051, etc

o Modal instructions

  Some processors have instructions whose behavior change depending upon
  the state of the processor status bits. 

  Applies to: SH, 65816, etc.

o Literal pools

  Some procesors can only encode short constants into immediate loads
  and require a PC-relative reference to load long constants. These
  long constants are usually stored in small batches called
  "literal pools".

  Applies to: SH, S390, etc.

Having said all that, I suppose the minimal instructions necessary to
support gcc are:

o load indirect
o store indirect
o load immediate
o negate
o add
o compares
o boolean ops
o conditional branches
o jumps
o subroutine calls

I think most other operations can be synthesized from those instructions
(albeit somewhat inefficiently).

Toshi

Re: gcc for any microcontroller?

[Svein E. Seldal]

tm_gccmail@mail.kloo.net wrote:
> o Special areas of memory which can only be accessed by special addressing
>   modes and/or banked memory
> 
>   This usually applies to DSPs and DSP-like processors which have internal
>   memory which can be accessed in parallel with the external bus, or to
>   funky processors that have been extended past their normal lifespan by
>   artificially extending the address space.
> 
>   Applies to: 8051, etc

One major drawback with GCC is that is does not support multiple 
memory-space addressing. Some microcontrollers and DSP's have separate 
memory-space for code and for data (for performance reasons). E.g. 
address 0x1000 can both refer to a point in the code memory (usually 
flash or similar) and to a point into data memory. These processors 
usually uses different op-codes and addressing methods to access the 
correct address and memory-space.

Applies to: AVR, 8051, high-performance DSP's.

Today, gcc selects one of these spaces (usually the data-space) and 
sticks to it. If the user needs to access another memory-space, e.g. 
constants in flash, he needs to do it manually himself (usually by 
inline assembly).


Technical about gcc's limitation:
---------------------------------

If it would be possible to declare attributes on pointers in gcc, this 
limitation could be solved in a rather simple way. Example:

1)	int in_flash __attribute__((progmem)) = 1234;
2)	int in_data = 5678;
3)	int * __attribute__((progmempointer)) code_pointer = &in_flash;
4)      int * data_pointer = &in_data;
5)      printf("%d %d\n",*code_pointer);
6)      data_pointer = code_pointer;

1) stores some information in the flash/code memory (this works today 
with the AVR port).
2) stores some information in data memory
3) declares a pointer to code memory using the proposed attribute
4) declares a pointer to data memory
5) will generate the target-specific opcodes required to access the data 
from progmem (because of the progmempointer attribute)
6) would fail because the types are different.

But as the operation in 3) is not possible with gcc, this need work with 
gcc. You can declare attributes on storages and implementations, but not 
on pointers. Gcc need to have these new features:

- Possibility to declare attributes of pointers. I.e. the attribute 
becomes a part of the type definition.

- For those targets with multiple memory-spaces, add the new 
memory-access methods. (E.g. in the AVR use 'lpm' to access code-memory, 
and 'lds' to access data-memory.)


Svein

Re: gcc for any microcontroller?

[Petr Danecek]

thank you for your answer, Toshi.
if i understand it correctly, HC08 would be difficult to port, though
not impossible. now, is it worth of it? maybe there is a more suitable c
compiler somewhere. i doubt that writing cc from scratch is a good
choice...?
petr

On Sat, 2003-03-22 at 02:48, tm_gccmail@mail.kloo.net wrote:

> Since I'm a processor geek, I'll take a fling at answering this one.
> 
> Yes, probably gcc can be ported for any microcontroller. The real question
> is whether a good port can be done for a microcontroller.
> 
> GCC emits good code for processors which have:
> 
> o Many general-purpose registers
> o Orthogonal and reasonable addresing modes
> o Few or no special-purpose registers
> o Homogenous memory space
> 
> GCC has trouble generating code for processors which have:
> 
> o Few or no general-purpose registers
> 
>   Many microcontrollers use an accumulator-based architecture, which does
>   not work with common register allocation algorithms at all, so you wind
>   up emulating general-purpose registers using strange techniques.
> 
>   Also, stack-based architectures are difficult to accomodate as well.
> 
>   Applies to: 68HC11, 8051, Z80, 6502, PicoJava, x86 FPU, etc.
> 
> o Lack of standard addressing modes
> 
>   Some processors have no or very few bits of displacement on the indirect
>   addressing mode, which causes gcc problems. Unfortunately, some people
>   are publishing papers which say "you don't need displacement addressing
>   modes because they can be easily simulated" (Crispin Cowan, etc) and
>   some processors have actually been built without displacement addressing
>   modes. This problem complicates many optimizations including CSE, loop
>   optimizations, instruction scheduling, etc.
> 
>   Applies to: NIW architecture, IA64, etc.
> 
> o Many special-purpose registers
> 
>   This complicates register allocation and instruction scheduling greatly,
>   and makes code generation very difficult.
> 
>   Applies to: SH, etc
> 
> o Special areas of memory which can only be accessed by special addressing
>   modes and/or banked memory
> 
>   This usually applies to DSPs and DSP-like processors which have internal
>   memory which can be accessed in parallel with the external bus, or to
>   funky processors that have been extended past their normal lifespan by
>   artificially extending the address space.
> 
>   Applies to: 8051, etc
> 
> o Modal instructions
> 
>   Some processors have instructions whose behavior change depending upon
>   the state of the processor status bits. 
> 
>   Applies to: SH, 65816, etc.
> 
> o Literal pools
> 
>   Some procesors can only encode short constants into immediate loads
>   and require a PC-relative reference to load long constants. These
>   long constants are usually stored in small batches called
>   "literal pools".
> 
>   Applies to: SH, S390, etc.
> 
> Having said all that, I suppose the minimal instructions necessary to
> support gcc are:
> 
> o load indirect
> o store indirect
> o load immediate
> o negate
> o add
> o compares
> o boolean ops
> o conditional branches
> o jumps
> o subroutine calls
> 
> I think most other operations can be synthesized from those instructions
> (albeit somewhat inefficiently).
> 
> Toshi
> 
> 

Re: gcc for any microcontroller?

[Gabriel Paubert]

On Mon, Mar 24, 2003 at 04:29:41PM +0100, Petr Danecek wrote:
> thank you for your answer, Toshi.
> if i understand it correctly, HC08 would be difficult to port, though
> not impossible. now, is it worth of it? maybe there is a more suitable c
> compiler somewhere. i doubt that writing cc from scratch is a good
> choice...?
> petr

There is a Debian packages called sdcc (small device C compiler) and
a companion simulator package (sdcc-ucsim):

"SDCC is a C compiler for the Intel MCS51 family, AVR and Z80
microcontrollers. The package includes the compiler, assemblers and
linkers, and a core library."

If it can generate (probably awful) code for the 8051, it must be 
fairly easy to target almost any architecture, however strange it is.

Disclaimer, I've never used it, I just discovered it a few days ago
when looking for something completely unrelated. But having written
a few thousand lines of 8051 assembly, I've not yet figured how a 
compiler can target such a baroque processor.

	Gabriel.

Re: gcc for any microcontroller?

[Stephane Carrez]

Hi!

Petr Danecek wrote:
> thank you for your answer, Toshi.
> if i understand it correctly, HC08 would be difficult to port, though
> not impossible. now, is it worth of it? maybe there is a more suitable c
> compiler somewhere. i doubt that writing cc from scratch is a good
> choice...?
> petr
> 

Gcc already supports HC11 and HC12.  The generated code is better than
commercial compilers (like Cosmic).  The few registers (3) that HC11/HC12
have made my life difficult in making gcc generate good output.  But it is
do-able (so I disagree with Toshi as far as HC11/HC12 are concerned).

For HC08 I receive regularly requests to support it.  Since it's close to
HC11/HC12 but has only 2 registers I guess the port would be even more difficult.
I think this could be done with some improvements in gcc reload pass.

	Stephane

-- 
         Home                           Office
E-mail: stcarrez@nerim.fr              Stephane.Carrez@solsoft.fr
WWW:    http://stcarrez.nerim.net      http://www.solsoft.com
         Free the Software!             Simplifying Security Policy Management

Re: gcc for any microcontroller?

[tm_gccmail]

On 24 Mar 2003, Petr Danecek wrote:

> thank you for your answer, Toshi.
> if i understand it correctly, HC08 would be difficult to port, though
> not impossible. now, is it worth of it? maybe there is a more suitable c
> compiler somewhere. i doubt that writing cc from scratch is a good
> choice...?
> petr

I took a look at the 68HC08, and it looks like a straight 6800
implementation afaict - it has one 8-bit accumulator and a 16-bit
register.

I haven't ported gcc to an accumulator machine, but did I port lcc to
the 65816 a while back. Based on this, you would probably fake a machine
with 8 16-bit virtual registers, then do post-reload splits to break the
virtual insns manipulating virtual 16-bit  registers down into hardware
machine insns manipulating the real accumulator.

This will create a lot of redundant load/store instructions from the
virtual registers, so you will need to create a machine-dependent pass to
slice the 16-bit operations into two 8-bit operations which will require
fewer load/stores when possible.

Consider:

	sint16_t a, b, c;
	a = (b + c) & d;

If you do this naively, it will generate something like:
(ignoring the carry issues for moment)

	accum = low(b);
	accum += low(c);
	temp1 = accum;
	accum = high(b);
	accum += high(c);
	temp2 = accum;
	accum = temp1;
	accum &= low(d);
	low(a) = accum;
	accum = temp2;
	accum &= high(d);
	high(a) = accum;

If you reorder the sequence of operations, you can do this instead,
assuming AND doesn't modify the carry bit:

	accum = low(b);
	accum += low(c);
	accum &= low(d);
	low(a) = accum;
	accum = high(b);
	accum += high(c);
	accum 7= high(d);
	high(a) = accum;

...which eliminates two loads and two stores.

Toshi

Re: gcc for any microcontroller?

[tm_gccmail]

On Mon, 24 Mar 2003, Gabriel Paubert wrote:

> On Mon, Mar 24, 2003 at 04:29:41PM +0100, Petr Danecek wrote:
> > thank you for your answer, Toshi.
> > if i understand it correctly, HC08 would be difficult to port, though
> > not impossible. now, is it worth of it? maybe there is a more suitable c
> > compiler somewhere. i doubt that writing cc from scratch is a good
> > choice...?
> > petr
> 
> There is a Debian packages called sdcc (small device C compiler) and
> a companion simulator package (sdcc-ucsim):
> 
> "SDCC is a C compiler for the Intel MCS51 family, AVR and Z80
> microcontrollers. The package includes the compiler, assemblers and
> linkers, and a core library."
> 
> If it can generate (probably awful) code for the 8051, it must be 
> fairly easy to target almost any architecture, however strange it is.
> 
> Disclaimer, I've never used it, I just discovered it a few days ago
> when looking for something completely unrelated. But having written
> a few thousand lines of 8051 assembly, I've not yet figured how a 
> compiler can target such a baroque processor.
> 
> 	Gabriel.

The homepage for that is on sourceforge: http://sdcc.sourceforge.net.

As mentioned before, the usual strategy for code generation on 
accumulator-based machine is to fake an architecture with general-purpose
registers.

Toshi

Re: gcc for any microcontroller?

[tm_gccmail]

On Mon, 24 Mar 2003, Stephane Carrez wrote:

> Hi!
> 
> Petr Danecek wrote:
> > thank you for your answer, Toshi.
> > if i understand it correctly, HC08 would be difficult to port, though
> > not impossible. now, is it worth of it? maybe there is a more suitable c
> > compiler somewhere. i doubt that writing cc from scratch is a good
> > choice...?
> > petr
> > 
> 
> Gcc already supports HC11 and HC12.  The generated code is better than
> commercial compilers (like Cosmic).  The few registers (3) that HC11/HC12
> have made my life difficult in making gcc generate good output.  But it is
> do-able (so I disagree with Toshi as far as HC11/HC12 are concerned).

You're lucky on the HC11. It at least has 16-bit index registers. Many of
the other processors from that era have index registers with fewer bits
than their addressing (6502, 65816, 8086, etc).

Toshi

Re: gcc for any microcontroller?

[tm_gccmail]

On Mon, 24 Mar 2003 tm_gccmail@mail.kloo.net wrote:

> On Mon, 24 Mar 2003, Stephane Carrez wrote:
> 
> > Hi!
> > 
> > Petr Danecek wrote:
> > > thank you for your answer, Toshi.
> > > if i understand it correctly, HC08 would be difficult to port, though
> > > not impossible. now, is it worth of it? maybe there is a more suitable c
> > > compiler somewhere. i doubt that writing cc from scratch is a good
> > > choice...?
> > > petr
> > > 
> > 
> > Gcc already supports HC11 and HC12.  The generated code is better than
> > commercial compilers (like Cosmic).  The few registers (3) that HC11/HC12
> > have made my life difficult in making gcc generate good output.  But it is
> > do-able (so I disagree with Toshi as far as HC11/HC12 are concerned).
> 
> You're lucky on the HC11. It at least has 16-bit index registers. Many of
> the other processors from that era have index registers with fewer bits
> than their addressing (6502, 65816, 8086, etc).
> 
> Toshi

BTW, I was looking at gcc CVS for the 68HC11 and found a problem.

wscrollbar.i: In function `SBarManage':
wscrollbar.i:19909: error: unable to find a register to spill in class
`A_REGS'
wscrollbar.i:19909: error: this is the insn:
(insn:HI 2494 2493 2495 357 0x406d35ac (parallel [
            (set (mem/s:SI (plus:HI (reg/v/f:HI 54 [ sb ])
                        (const_int 2 [0x2])) [4
<variable>.visibility_state+0 S4 A8])
                (mem/s:SI (plus:HI (reg/v/f:HI 59 [ event ])
                        (const_int 18 [0x12])) [0
<variable>.xvisibility.state+0 S4 A8]))
            (clobber (scratch:HI))
        ]) 17 {movsi_internal} (nil)
    (expr_list:REG_DEAD (reg/v/f:HI 59 [ event ])
        (expr_list:REG_DEAD (reg/v/f:HI 54 [ sb ])
            (expr_list:REG_UNUSED (scratch:HI)
                (nil)))))

Somethign somewhere generated a memory-to-memory move instruction, it
looks like?

The testcase is wscrollbar.i from stress-1.17 - I can send you the
testcase if youw ant.

Toshi

Re: gcc for any microcontroller?

[Stephane Carrez]

Hi!

tm_gccmail@mail.kloo.net wrote:
> On Mon, 24 Mar 2003 tm_gccmail@mail.kloo.net wrote:
> 
> 
>>On Mon, 24 Mar 2003, Stephane Carrez wrote:
>>
>>
>>>Hi!
>>>
>>>Petr Danecek wrote:
>>>
>>>>thank you for your answer, Toshi.
>>>>if i understand it correctly, HC08 would be difficult to port, though
>>>>not impossible. now, is it worth of it? maybe there is a more suitable c
>>>>compiler somewhere. i doubt that writing cc from scratch is a good
>>>>choice...?
>>>>petr
>>>>
>>>
>>>Gcc already supports HC11 and HC12.  The generated code is better than
>>>commercial compilers (like Cosmic).  The few registers (3) that HC11/HC12
>>>have made my life difficult in making gcc generate good output.  But it is
>>>do-able (so I disagree with Toshi as far as HC11/HC12 are concerned).
>>
>>You're lucky on the HC11. It at least has 16-bit index registers. Many of
>>the other processors from that era have index registers with fewer bits
>>than their addressing (6502, 65816, 8086, etc).
>>
>>Toshi
> 
> 
> BTW, I was looking at gcc CVS for the 68HC11 and found a problem.
> 
> wscrollbar.i: In function `SBarManage':
> wscrollbar.i:19909: error: unable to find a register to spill in class
> `A_REGS'
> wscrollbar.i:19909: error: this is the insn:
> (insn:HI 2494 2493 2495 357 0x406d35ac (parallel [
>             (set (mem/s:SI (plus:HI (reg/v/f:HI 54 [ sb ])
>                         (const_int 2 [0x2])) [4
> <variable>.visibility_state+0 S4 A8])
>                 (mem/s:SI (plus:HI (reg/v/f:HI 59 [ event ])
>                         (const_int 18 [0x12])) [0
> <variable>.xvisibility.state+0 S4 A8]))
>             (clobber (scratch:HI))
>         ]) 17 {movsi_internal} (nil)
>     (expr_list:REG_DEAD (reg/v/f:HI 59 [ event ])
>         (expr_list:REG_DEAD (reg/v/f:HI 54 [ sb ])
>             (expr_list:REG_UNUSED (scratch:HI)
>                 (nil)))))
> 
> Somethign somewhere generated a memory-to-memory move instruction, it
> looks like?
> 
> The testcase is wscrollbar.i from stress-1.17 - I can send you the
> testcase if youw ant.
> 
> Toshi
> 
> 

Yes please so that I can fix it (this pb does not happen very often and
I don't see it in the gcc testsuite).

	Stephane

-- 
         Home                           Office
E-mail: stcarrez@nerim.fr              Stephane.Carrez@solsoft.fr
WWW:    http://stcarrez.nerim.net      http://www.solsoft.com
         Free the Software!             Simplifying Security Policy Management