AVR Harvard architecture -- worst of both worlds?

Rene Tschaggelar wrote:
> David Brown wrote:
> 
>> Ulf Samuelsson wrote:
>>
> 
>>> I copy constants to the stack when needed.
>>> A little hassle, but not dramatic.
>>>
>>
>> I'm not sure I can think of any reason why that might help.  The only 
>> two problems with constants in flash are the awkward syntax (either 
>> you've got extra keywords or macros added, or you've got a broken 
>> "const" implementation), and for pointers (such as passing around 
>> strings in flash).
>>
> 
> 
> 
> David,
> the syntax is a matter of the compiler. The
> syntax of C has never been phantastic either.
> 
> Rene

The point is that to get constant data in flash, you need to go beyond 
the usual C syntax (such as by using a "flash" keyword or "progmem" 
macro) - your code is even uglier than standard C.  It is also 
inconsistent between different compilers for the same target.  (Some avr 
compilers misuse "const" to mean flash - that works fine for simple 
code, but can cause problems for some code.)

David Brown wrote:

>
> > David,
> > the syntax is a matter of the compiler. The
> > syntax of C has never been phantastic either.
> >
> > Rene
>
> The point is that to get constant data in flash, you need to go beyond
> the usual C syntax (such as by using a "flash" keyword or "progmem"
> macro) - your code is even uglier than standard C.  It is also
> inconsistent between different compilers for the same target.  (Some avr
> compilers misuse "const" to mean flash - that works fine for simple
> code, but can cause problems for some code.)

ISO/IEC 18037 adds named address space that makes multiple
address space access a lot easier. Many non Harvard architectures
have multiple address spaces.

The other thing that happens as soon as you use tools that support
multiple address spaces is devices on I2C buses suddenly become
more accessible and easier to add as part of a design.


Walter Banks
--
Byte Craft Limited
Tel. (519) 888-6911
 http://www.bytecraft.com
walter@bytecraft.com

"Ulf Samuelsson" <ulf@a-t-m-e-l.com> writes:
> >>
> >> An "interesting" situation arises when dealing with constants in 
> >> programs.
> >> One would like to put these in ROM but with a Harvard architecture, one
> >> can't access the locations as directly (if at all) as one can if the 
> >> values
> >> are in RAM.  Thus, one has to have either special functions to call to 
> >> copy
> >> the constants to RAM when needed or copy them to RAM at program 
> >> initialization.
> >> The latter runs the risk of the RAM location getting overwritten and the
> >> constant not being as constant as one wishes.  The former adds a layer of
> >> complexity and additional execution time to the programming that one 
> >> would
> >> just as soon avoid.
> >>
> >
> > Copying constants to RAM on startup does not run any risk of the locations 
> > getting overwritten unless your program is totally messed up, and then 
> > "varying constants" is only one of your many problems.
> >
> > If you can arrange for the compiler to see the constant's values before 
> > using them, it will generally use the values directly in the code. 
> > Otherwise, the only disadvantage of copying them into RAM is the RAM space 
> > used - for lookup tables, you might want to make sure they are in flash.
> 
> I copy constants to the stack when needed.  A little hassle, but not dramatic.

But they have to be copied each and every time they're needed.  The
tradeoff is to copy once at startup or every time needed.

> I seems to remembed someone telling me that the Harvard architecture
> of the AVR improved performance by about 35% performance.

Compared to what, where, when.

>>> If you can arrange for the compiler to see the constant's values before 
>>> using them, it will generally use the values directly in the code. 
>>> Otherwise, the only disadvantage of copying them into RAM is the RAM 
>>> space used - for lookup tables, you might want to make sure they are in 
>>> flash.
>>>
>>
>> I copy constants to the stack when needed.
>> A little hassle, but not dramatic.
>>
>
> I'm not sure I can think of any reason why that might help.  The only two 
> problems with constants in flash are the awkward syntax (either you've got 
> extra keywords or macros added, or you've got a broken "const" 
> implementation), and for pointers (such as passing around strings in 
> flash).
>
>> I seems to remembed someone telling me that the Harvard architecture
>> of the AVR improved performance by about 35% performance.
>>
>
> Having separate buses for code and data is certainly a good thing for 
> making simple and fast processors, although I think that any figure put on 
> it is taken out of thin air (did someone make a complete AVR core with a 
> shared bus for comparison?

I think the tradeoffs were evaluated during th e initial design of the AVR 
core.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

>> I copy constants to the stack when needed.  A little hassle, but not 
>> dramatic.
>
> But they have to be copied each and every time they're needed.  The
> tradeoff is to copy once at startup or every time needed.
>

Yes, but so far, that has not been a problem, since the AVR
has been fast enough and power consumption has been low enough.

>> I seems to remembed someone telling me that the Harvard architecture
>> of the AVR improved performance by about 35% performance.
>
> Compared to what, where, when.

Compared to an AVR implementation with a shared bus.
The study was done during the design of the AVR core,
but it is before my time, so I do not have any details.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

Walter Banks wrote:
> 
> David Brown wrote:
> 
>>> David,
>>> the syntax is a matter of the compiler. The
>>> syntax of C has never been phantastic either.
>>>
>>> Rene
>> The point is that to get constant data in flash, you need to go beyond
>> the usual C syntax (such as by using a "flash" keyword or "progmem"
>> macro) - your code is even uglier than standard C.  It is also
>> inconsistent between different compilers for the same target.  (Some avr
>> compilers misuse "const" to mean flash - that works fine for simple
>> code, but can cause problems for some code.)
> 
> ISO/IEC 18037 adds named address space that makes multiple
> address space access a lot easier. Many non Harvard architectures
> have multiple address spaces.
> 

I haven't read through the new standard yet, but it will be good to get 
a single consistent way to handle this sort of issue.  Of course, it 
will probably take a decade or so before it is implemented in enough C 
compilers to make it a portable solution - there are still compilers on 
sale that view ISO C90 as the bees knees.

ISO 18037 also seems to standardise hardware access (I've got as far as 
the contents page), but it does not tackle interrupts - it would have 
been nice if there were a common way to specify interrupt functions and 
other non-standard ABI functions.


> The other thing that happens as soon as you use tools that support
> multiple address spaces is devices on I2C buses suddenly become
> more accessible and easier to add as part of a design.
> 

That can have its good sides and its bad sides.  It would certainly be 
convenient to be able to read and write things like EEPROMs like normal 
memory.  But it can also lead to problems - reading data over an I2C 
bus, for example, is going to be a lot slower than reading it from local 
memory, and it could give you conflicts if the bus is shared with other 
peripherals.  I'll read some of the ISO document before commenting 
further, however.

Ulf Samuelsson wrote:
>>>> If you can arrange for the compiler to see the constant's values before 
>>>> using them, it will generally use the values directly in the code. 
>>>> Otherwise, the only disadvantage of copying them into RAM is the RAM 
>>>> space used - for lookup tables, you might want to make sure they are in 
>>>> flash.
>>>>
>>> I copy constants to the stack when needed.
>>> A little hassle, but not dramatic.
>>>
>> I'm not sure I can think of any reason why that might help.  The only two 
>> problems with constants in flash are the awkward syntax (either you've got 
>> extra keywords or macros added, or you've got a broken "const" 
>> implementation), and for pointers (such as passing around strings in 
>> flash).
>>
>>> I seems to remembed someone telling me that the Harvard architecture
>>> of the AVR improved performance by about 35% performance.
>>>
>> Having separate buses for code and data is certainly a good thing for 
>> making simple and fast processors, although I think that any figure put on 
>> it is taken out of thin air (did someone make a complete AVR core with a 
>> shared bus for comparison?
> 
> I think the tradeoffs were evaluated during th e initial design of the AVR 
> core.
> 

No doubt they were considered at that time (although I find it hard to 
believe that a shared bus version would have been made) - but the AVR 
core was initially designed with slightly different priorities than if 
one were to design a cpu to take the place of the current AVRs.  When 
the AVR core was designed, things like die space and the simplicity of 
integrating it in Atmel's ASICs were more important than its convenience 
for C compilers.  If one were to make a new, modern version without 
requiring binary compatibility, then it would have a single address 
space (with separate buses for speed, of course - just like most modern 
cpus), more pointer registers, better stack pointer access, and more 
16-bit operations.

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:46e8e32b$0$3210$8404b019@news.wineasy.se...
> Walter Banks wrote:
>>
>> ISO/IEC 18037 adds named address space that makes multiple
>> address space access a lot easier. Many non Harvard architectures
>> have multiple address spaces.
>>
>
> I haven't read through the new standard yet,

It is not a standard, it is a Technical Report so it can safely be ignored. 
And I'm sure it will be.  Hell, C99 isn't pervasive yet.

> but it will be good to get a single consistent way to handle this sort of 
> issue.

The TR doesn't address the issue of what qualifiers you can legitimately 
use.  They will be implementation-defined.

> Of course, it will probably take a decade or so before it is implemented 
> in enough C compilers to make it a portable solution - there are still 
> compilers on sale that view ISO C90 as the bees knees.

As I said, it codifies only where you place namespace qualifiers, it does 
not codify what you mean.  So it's a free-for-all in the implementation and 
portability is certainly not assured.  I agree with you that C90 is just 
fine for embedded work, C99 is a standard that should never have been 
accepted IMHO (sorry if there are any ISO WG members here, it's not personal 
it's just business as they say).

> ISO 18037 also seems to standardise hardware access (I've got as far as 
> the contents page),

It tries to standardize and what is inherently non-standard.  I see 
absolutely no value in the I/O "abstraction", it's not portable so why try 
to make it so?

> but it does not tackle interrupts - it would have been nice if there were 
> a common way to specify interrupt functions and other non-standard ABI 
> functions.

That would be difficult, IMO.  Interrupt controllers are shockingly bad 
sometimes.  I think Motorola had interrupts working pretty well on the 
MC68000 so long ago.

-- Paul.

David Brown wrote:

> Walter Banks wrote:
> > ISO/IEC 18037 adds named address space that makes multiple
> > address space access a lot easier. Many non Harvard architectures
> > have multiple address spaces.
> >
>
> I haven't read through the new standard yet, but it will be good to get
> a single consistent way to handle this sort of issue.  Of course, it
> will probably take a decade or so before it is implemented in enough C
> compilers to make it a portable solution - there are still compilers on
> sale that view ISO C90 as the bees knees.
>
> ISO 18037 also seems to standardise hardware access (I've got as far as
> the contents page), but it does not tackle interrupts - it would have
> been nice if there were a common way to specify interrupt functions and
> other non-standard ABI functions.
>
> That can have its good sides and its bad sides.  It would certainly be
> convenient to be able to read and write things like EEPROMs like normal
> memory.  But it can also lead to problems - reading data over an I2C
> bus, for example, is going to be a lot slower than reading it from local
> memory, and it could give you conflicts if the bus is shared with other
> peripherals.  I'll read some of the ISO document before commenting
> further, however.

ISO 18037 has multiple sections. The definition of fract and accum data
types was  long overdue.

Named address space and user defined address space opens the
possibility that applications can place data in slow memory by design
and that memory space can be managed by the normal symbol table
manager. We have quite a few high volume appliance customers that
use this technology to manage unused RAM in many generic LCD
controllers for application storage.

The combination of named address spaces and the new data types
suddenly made it possible to create portable in C dsp code that
didn't by necessity have to be written in asm. There are many portable
DSP applications being written in Cell phone and automotive applications.

I buy your comments about standardized interrupt support.

Walter Banks
--
Byte Craft Limited
Tel. (519) 888-6911
 http://www.bytecraft.com
walter@bytecraft.com

Paul Curtis wrote:

> "David Brown" <david@westcontrol.removethisbit.com> wrote in message
> news:46e8e32b$0$3210$8404b019@news.wineasy.se...
> > Walter Banks wrote:
> >>
> >> ISO/IEC 18037 adds named address space that makes multiple
> >> address space access a lot easier. Many non Harvard architectures
> >> have multiple address spaces.
> >>
> >
> > I haven't read through the new standard yet,
>
> It is not a standard, it is a Technical Report so it can safely be ignored.
> And I'm sure it will be.  Hell, C99 isn't pervasive yet.
>
> > Of course, it will probably take a decade or so before it is implemented
> > in enough C compilers to make it a portable solution - there are still
> > compilers on sale that view ISO C90 as the bees knees.
>
> As I said, it codifies only where you place namespace qualifiers, it does
> not codify what you mean.  So it's a free-for-all in the implementation and
> portability is certainly not assured.  I agree with you that C90 is just
> fine for embedded work, C99 is a standard that should never have been
> accepted IMHO (sorry if there are any ISO WG members here, it's not personal
> it's just business as they say).

I won't take it personally :)

C99 did a number of things that many compilers were implementing
independently. // comments and size specific variable types to name
two.

ISO/IEC 18037 is important as the first cut to define of fract
and accum data types. Named and user defined address spaces
and full access in C to processor registers brings C back to its roots.

Walter Banks
--
Byte Craft Limited
Tel. (519) 888-6911
 http://www.bytecraft.com
walter@bytecraft.com