This is the mail archive of the
mailing list for the GCC project.
[RFC] Gcc and harvard architectures (towards AVR)
- From: "Svein E. Seldal" <Svein dot Seldal at solidas dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 17 Dec 2002 16:56:56 +0100
- Subject: [RFC] Gcc and harvard architectures (towards AVR)
How are Harvard architectures handled in gcc? Let me take you in on a
Lets imagine a processor which have more than one address-spaces (thus
the architecture type Harvard). In most processors we are talking about
code-space and data-space, but there might as well be more. These CPU's
have a set of operators to access the data-space and another set of
operators to access the code-space. CPU's like microcontrollers and
high-performance DSP's are typical users of this architecture because it
yields high data throughput. Because the application data and the
program code is transferred simetaneously on separate internal buses.
One example of this is the AVR processors. This architecture has two
memory spaces; .text and .data. A typical AVR har plenty of flash
(.text) but virtually no memory (.data + .bss). An application must use
separate addressing/opcodes for accessing data from the memory than from
The problem arises when using the avr-gcc compiler. It places (const)
string tables, const structs etc, into the .data segment (even those
defined as const). As you probably can understand, this memory is
starved pretty quick.
I guess the main reason behind this method is because gcc has no way of
knowing when to use the flash-accessing addressing from the
data-accessing addressing, thus all data is placed into the data segment.
There are attributes for placing data into the .text section, but you
have to manually write inline assembly for accessing the flash memory.
This limit imposes several effects which makes the code far less
efficient. (And error-prone.)
I've disussed this with the avr-maintainer, but he rejects this
suggestion as this would require global gcc changes. (He also mentioned
that Linus has asked for something similar.). So now I'm asking these
questions in a global forum
- _does_ gcc support Harvard arch's at all?
- I will be surprised if there aren't other targets using Harvard
architectures? How have they solved this problem?
My suggestion would be to place all initialized const variables into a
.const section which in turn would be placed into flash. But for this to
work properly, gcc must be able to identify pointers and accesses to the
flash and use the correct addressing methods for that information. As
stated earlier, data accesses and flash accesses are fundamentally
different as seen from the targets opcodes.
I have a technical suggestion for how to implement this, but I would
like to discuss the issue in a general basis before entering the