[RFC] Gcc and harvard architectures (towards AVR)

[RFC] Gcc and harvard architectures (towards AVR)

[Svein E. Seldal]

Hello,

How are Harvard architectures handled in gcc? Let me take you in on a 
little discussion:

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 
flash.

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 
detailed discussion.



Regards,
Svein Seldal

Re: [RFC] Gcc and harvard architectures (towards AVR)

[Denis Chertykov]

"Svein E. Seldal" <Svein.Seldal@solidas.com> writes:

> Hello,
> 
> How are Harvard architectures handled in gcc? Let me take you in on a
> little discussion:
> 
> 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.

[...]

> 
> 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
> detailed discussion.

Look to archive.
Subject: Segment register support for the i386
Date: 31 Dec 1999

Denis.

Re: [RFC] Gcc and harvard architectures (towards AVR)

[Svein E. Seldal]

Denis Chertykov wrote:

>>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
>>detailed discussion.
> 
> 
> Look to archive.
> Subject: Segment register support for the i386
> Date: 31 Dec 1999

Yes, I've seen this before. But it still is an unresolved issue IMHO. 
For the avr-gcc this is a obvious limiation, as it required more 
resources to do something that is simpler if gcc had the page support.

My suggestion is as follows:

A target has two address-spaces; the data (the default) and the code. 
Consider the following example:

Accesses to the data-space is done as normal:

   int a = 1234; // Declares a data storeage in data-space
   int *p = &a;	// Declare a pointer (in data-space) to a data-space
                 // storeage
   x = *p;       // Will fill x with 1234

Accesses using the code-space can be done as follows:

(Please note that code-space is usually read-only, and for this to work 
you'd have to declare the variables and pointers as const - but I'll 
skip this for now)

   // Declare a datastoreage in code-space
   int __attribute__((codespace)) b = 5678;

   // Declare a pointer in data-space which points to a code-space
   // address
   int __attribute__((codespace)) * q = &b;

   // Declare a pointer in code-space which points to a code-space
   // address
   int __attribute__((codespace)) * __attribute__((codespace)) r = &b;

   // Will read the contents of the code-space datastorage 'b' and
   // place it into x, which in this example is 5678
   x = *q;

   // This will fail because 'q' is a codespace pointer, while 'p' is
   // dataspace pointer
   q = p;

*) For those familiar with the avr target this is the same as the 
'progmem' attribute. I just want to use the codespace name as a 
demostration of how to do it.

Would this be a feasable implemenation of address-spaces?

What global (gcc) changes would a implementation like this imply?


Svein

Re: [RFC] Gcc and harvard architectures (towards AVR)

[Richard Henderson]

On Thu, Dec 19, 2002 at 12:02:09PM +0100, Svein E. Seldal wrote:
> What global (gcc) changes would a implementation like this imply?

Lots.  The same ones discussed in the x86 segment register thread.
Namely, being able to distinguish that an address comes from a 
particular address space, and not ever losing this info.


r~

[RFC] Gcc and multiple memory spaces (former Gcc and harvard architectures (towards AVR))

[Svein E. Seldal]

After some helpful pointers by Robert Dewar, I'm going to rephrase my 
questions. It seems like I have used the wrong terms, so I'm trying to 
clear things up by explaining my intentions better this time.

I would really like gcc to have support for several memory-spaces. 
Because some targets, like the AVR, has more than one memory-space; one 
for code (I-space) and one for data (D-space). And these spaces cannot 
normally intermix. The I-space is used by the CPU core to fetch new 
instructions, while the D-space is used for data storeage. While the 
I-space is normally reserved for storing code, it is possible to store 
data there as well in some targets. And these targets usually has 
different sets of opcodes to access these spaces; one set for D-space 
access, and one set for the special I-space access.

The AVR target (for one) has a very low memory (D-space), while it has 
reasonable amounts of flash (I-space). It would be an advantage if const 
variables, strings. etc. could be placed into flash (I-space). While it 
is possible to do so by using the 'progmem' attribute, it is impossible 
to get gcc to natively handle this information. This is caused by the 
simple fact that gcc is only capable of handling one memory space, which 
happens to be the runtime memory (D-space).

If users are to read from the flash (I-space), they have to fiddle 
around with manual assembly. This gives several obvious drawbacks: 
Strings that are placed into flash, are not collected. const structs in 
flash are a mess, because you have to access the members manually (using 
assembly), etc. Very errorprone!

I've spoken to the AVR maintainers about this feature, but they cannot 
implement this because it has global gcc implications.

Please see http://gcc.gnu.org/ml/gcc/2002-12/msg01194.html for a 
description of my suggestion.

It seems to me that this would imply the following changes/additions to gcc:

a) Implement attributes which places data in the appropriate memoryspace 
(ala the AVR-target's 'progmem' attribute)

b) Implement the ability to declare attributes on pointers (not just 
pointer storeage), which would make it possible to have pointers to 
locations in other memoryspaces.

c) Rewrite the target-specific parts of gcc where the memory accesses 
are translated into assembly. -- Take the AVR as an example. It uses 
different opcodes for accessing the D-space from the I-space. This 
implies that gcc must be able to generate the appropriate code for the 
correct address-space/access form.

FYI: The definitions of these memoryspaces are defined by the target 
architecture, never by the user in a runtime environment.

Unfortunately, I'm not a skilled gcc programmer (yet) so I would need 
lots and lots of help to do it. But this is something I'm very keen on 
getting implemented into gcc. The AVR target suffers from this 
limitation, were it is the greatest drawback for using gcc in AVR systems.

However I do not wish to burn too much energy trying to implement this 
feature is nobody wants it...

Is this idea realistically implementable into gcc?

What does the SC say about this? Isn't this food for their tables?

Please give me feedback on the issue if you have some.


Merry Christmas,
Svein

Re: [RFC] Gcc and multiple memory spaces (former Gcc and harvard architectures (towards AVR))

[devik]

> However I do not wish to burn too much energy trying to implement this
> feature is nobody wants it...

At least I can say that our f-cpu port (underway) would appreciate
it too. It uses indirect jumps only (like SHmedia) and has different
insn to manipulate code and data pointers because it starts (D/I)TLB
and cache prefetches early (so that pointer manipulation instructions
has one bit to indicate whether to fill D or I cache and whether to use
D or I TLB).

devik