avr-chat
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] more of the same ;)


From: Michael N. Moran
Subject: Re: [avr-chat] more of the same ;)
Date: Wed, 23 Aug 2006 09:55:53 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Rolf Magnus wrote:
On Tuesday 15 August 2006 10:15, Joerg Wunsch wrote:

Oh, while you are at it, move the vtables out to ROM, please. :-)


I didn't yet find any way to tell gcc that there are separate types of memory that should be accessed with separate assembler instructions (lds vs. lpm). That would have the nice side effect that pgm_read_* from the avr-libc would become pretty much obsolete I guess. Anyway, in the RTL, it seems that the attributes are gone, so I don't know how to propagate that information to that part. There are register classes that can define different types of registers, but no memory classes or something like that. I couldn't find any other target that would do that either. The C and C++ front end are independant of the target, so everything must be done in the AVR target part (directory gcc/config/avr)

Though not a contributer, but I have lurked on the list for many
years on the GCC development mailing list.

The issues surrounding multiple memory spaces are usually
stimulated by the needs of the strict harvard architecture
of the AVR, and many discussions have insued.

My understanding is that there is, at present, a fundamental
assumption in the GCC compiler architecture that assumes
a single memory space. Inevitably, some argue that GCC
supports many "harvard architecture" machines, such as
the PPC and other well know x86 derivatives. However the
difference is that while the data buses (at least at the
cache level) are separate, they share a single address
space from the point-of-view of the user/compiler, wheras
the AVR and some other less common machines have completely
separate memory spaces, each with its own set of addresses
and methods of accessing objects within those spaces (e.g.
different instructions for accessing data in each space.)

I seem to recall discussion about multiple memory
spaces being addressed at the C/C++ standarization
level, but can't seem to google a reference at present.

IMHO, even *with* multiple memory spaces recognized
within the languages, one would either have to live
with run-time type checking to "hide" the effect of
having pointers to different "types" of memory spaces
(yuk!) or extended libraries will be required to
manipulate, for example, strings that live in differnent
memory spaces:

// The tried and true (e.g. AVR RAM)
int strlen(const char* p);

// The new and different (e.g. AVR Flash)
int strlen(const avr_instruction_memory char* p);

BTW, there are other memory "type" attributes that,
as a systems programmer, I would like to see added
to the C/C++ language standards. Most importantaly
memory alignment block size requirements. This would
make it possible for the compiler to do strict type
checking of functions that manipulate, for example,
cache and page aligned data.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1






reply via email to

[Prev in Thread] Current Thread [Next in Thread]