X-Mega AVRs are here!

David Brown wrote:

> As for making it entirely von Neumann, I think that's a bit too big a 
> change - but it would have been perfectly possible to make the flash 
> accessible in the data space as well (in the same way as the eeprom is 
> now mapped into the data space).  You'd need 24-bit pointers to access 
> it, but it would still be a very useful feature.

What AVR has EEPROM mapped into data space?

Using lpm isn't terribly painful. No doubt motivated C compiler authors 
could hide the AVR FLASH constant data access mechanics, if only there 
was motivation.

David Kelly wrote:
> David Brown wrote:
> 
>> As for making it entirely von Neumann, I think that's a bit too big a 
>> change - but it would have been perfectly possible to make the flash 
>> accessible in the data space as well (in the same way as the eeprom is 
>> now mapped into the data space).  You'd need 24-bit pointers to access 
>> it, but it would still be a very useful feature.
> 
> What AVR has EEPROM mapped into data space?
> 

The XMega - at least for reading the eeprom (I haven't read the 
datasheets in detail).

> Using lpm isn't terribly painful. No doubt motivated C compiler authors 
> could hide the AVR FLASH constant data access mechanics, if only there 
> was motivation.

No, you can't hide it.  C only understands a single address space for 
data.  There is no way to express ideas such as a pointer that is 
accessed by "lpm" instead of "ld", and there is no way to write a 
function with a pointer parameter which will work with both a pointer to 
flash and a pointer to ram.  There is plenty of motivation for C 
compiler writers, but they are restricted by the language and by 
existing compiler parts (since most compilers share parts with other 
targets).  Solutions include macro wrappers (used by avr-gcc - fully 
standard C, but a bit ugly), abusing the "const" keyword (used by 
ImageCraft, until recent versions - very clear and neat, but 
non-standard and causes trouble for other use of "const"), a new "flash" 
keyword (used by IAR - neat and clear, but non-standard), and 
generalised pointers (the only standards-compliant way to get full 
pointer functionality - but big and slow).

There are plans for introducing multiple address spaces in the next C 
standards, but I'm not holding my breath waiting for the implementations.

David Brown <david@westcontrol.removethisbit.com> writes:

> David Kelly wrote:
>> David Brown wrote:
>>
>>> As for making it entirely von Neumann, I think that's a bit too big
>>> a change - but it would have been perfectly possible to make the
>>> flash accessible in the data space as well (in the same way as the
>>> eeprom is now mapped into the data space).  You'd need 24-bit
>>> pointers to access it, but it would still be a very useful feature.
>>
>> What AVR has EEPROM mapped into data space?
>>
>
> The XMega - at least for reading the eeprom (I haven't read the
> datasheets in detail).
>
>> Using lpm isn't terribly painful. No doubt motivated C compiler
>> authors could hide the AVR FLASH constant data access mechanics, if
>> only there was motivation.
>
> No, you can't hide it.  C only understands a single address space for
> data.  There is no way to express ideas such as a pointer that is
> accessed by "lpm" instead of "ld", and there is no way to write a
> function with a pointer parameter which will work with both a pointer
> to flash and a pointer to ram.  There is plenty of motivation for C
> compiler writers, but they are restricted by the language and by
> existing compiler parts (since most compilers share parts with other
> targets).  Solutions include macro wrappers (used by avr-gcc - fully
> standard C, but a bit ugly), abusing the "const" keyword (used by
> ImageCraft, until recent versions - very clear and neat, but
> non-standard and causes trouble for other use of "const"), a new
> "flash" keyword (used by IAR - neat and clear, but non-standard), and
> generalised pointers (the only standards-compliant way to get full
> pointer functionality - but big and slow).
>
> There are plans for introducing multiple address spaces in the next C
> standards, but I'm not holding my breath waiting for the
> implementations.

Exactly right, and in the end that was the downfall of the AVR for
me. That's why I don't really see the point of these new big
devices. As the memories get bigger and the I/O more capable, the core
must be taking up proportionally less and less area. So why not go for
a 32 bitter and be done with it?

-- 

John Devereux

David Brown wrote:

> No, you can't hide it.  

Au contraire.  It can be done, and it has been done.

> C only understands a single address space for 
> data.  

That's correct, but not as relevant to the issue at hand as one might 
think.  The trick is that there's no requirement that the single address 
space known by C map directly to any of the address spaces of the CPU. 
E.g. in the Keil C compiler for the 8051, a standard C pointer is 
constructed of two parts: one byte to identify the memory space, and two 
bytes to hold the actual address.

The downside, of course, is that such pointers are big, clumsy and 
CPU-expensive to handle.  Every access has to be decoded by somewhat 
involved code that checks which memory space is being used, and then 
accesses the relevant address.  Which is why in addition to the C 
standard pointer type, Keil supports memory space-specific pointers that 
don't cause the extra cost or storage.

Hans-Bernhard Br&ouml;ker <HBBroeker@t-online.de> writes:

> David Brown wrote:
>
>> No, you can't hide it.  
>
> Au contraire.  It can be done, and it has been done.
>
>> C only understands a single address space for data.  
>
> That's correct, but not as relevant to the issue at hand as one might
> think.  The trick is that there's no requirement that the single
> address space known by C map directly to any of the address spaces of
> the CPU. E.g. in the Keil C compiler for the 8051, a standard C
> pointer is constructed of two parts: one byte to identify the memory
> space, and two bytes to hold the actual address.
>
> The downside, of course, is that such pointers are big, clumsy and
> CPU-expensive to handle.  Every access has to be decoded by somewhat
> involved code that checks which memory space is being used, and then
> accesses the relevant address.  Which is why in addition to the C
> standard pointer type, Keil supports memory space-specific pointers
> that don't cause the extra cost or storage.

Which is precisely what he meant by the "big and slow" "generalised
 pointers" in the bit you snipped!

-- 

John Devereux

David Brown wrote:

> David Kelly wrote:
> > David Brown wrote:
> >
> >> As for making it entirely von Neumann, I think that's a bit too big a
> >> change - but it would have been perfectly possible to make the flash
> >> accessible in the data space as well (in the same way as the eeprom is
> >> now mapped into the data space).  You'd need 24-bit pointers to access
> >> it, but it would still be a very useful feature.
> >
> > What AVR has EEPROM mapped into data space?
> >
>
> The XMega - at least for reading the eeprom (I haven't read the
> datasheets in detail).
>
> > Using lpm isn't terribly painful. No doubt motivated C compiler authors
> > could hide the AVR FLASH constant data access mechanics, if only there
> > was motivation.
>
> No, you can't hide it.  C only understands a single address space for
> data.  There is no way to express ideas such as a pointer that is
> accessed by "lpm" instead of "ld", and there is no way to write a
> function with a pointer parameter which will work with both a pointer to
> flash and a pointer to ram.  There is plenty of motivation for C
> compiler writers, but they are restricted by the language and by
> existing compiler parts (since most compilers share parts with other
> targets).  Solutions include macro wrappers (used by avr-gcc - fully
> standard C, but a bit ugly), abusing the "const" keyword (used by
> ImageCraft, until recent versions - very clear and neat, but
> non-standard and causes trouble for other use of "const"), a new "flash"
> keyword (used by IAR - neat and clear, but non-standard), and
> generalised pointers (the only standards-compliant way to get full
> pointer functionality - but big and slow).
>
> There are plans for introducing multiple address spaces in the next C
> standards, but I'm not holding my breath waiting for the implementations.

The Philips MX51 core extension, handled this by keeping the opcode
basis of separate memory, but also overlaying/re-mapping the DATA
space into the
TOP of code space. That halves the memory span, but once you have gone
past
64K, no uC I have seen get anywhere close to filling up the 24/32 bit
address
space.
The result is the low level stuff stays the same, but you can access
ANY
code as data (and I guess, jump into RAM and run code there.. ?.)

It would have been an obvious thing to do on the XMEGA ?

-jg

>> There are plans for introducing multiple address spaces in the next C
>> standards, but I'm not holding my breath waiting for the
>> implementations.
>
> Exactly right, and in the end that was the downfall of the AVR for
> me. That's why I don't really see the point of these new big
> devices. As the memories get bigger and the I/O more capable, the core
> must be taking up proportionally less and less area. So why not go for
> a 32 bitter and be done with it?
>
> -- 
>
> John Devereux

There are multiple AVR32's on the market already ;-)

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