to use typed data pointers in GCC

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been reading about typed data pointers and I did not realize how important they are to generating faster code compared to generic data pointers or that they even existed.

Can typed data pointers be used in GCC to produce faster or tighter code for our AVR’s? Can someone explain how to use them or what typed pointers are available?

The part that really caught my eye was the bottom

Using a generic pointer, this code requires 571 cycles and 88 bytes. Using a typed data pointer, it needs just 196 cycles and 52 bytes.

Excerpt

Typed data pointers tend to lead to some horrific data declarations. For example, consider the following declaration from the Whitesmiths 68HC11 compiler:

@dir INT * @dir zpage_ptr_to_zero_page; 

Consequently, you may be tempted to simply ignore the use of typed pointers. Indeed, coding an application on a 68HC11 without ever using a typed data pointer is quite possible. However, by doing so the application’s performance will take an enormous hit because the zero page offers considerably faster access than the rest of memory.  This area is so critical to performance that all hope of portability is lost.

To get a feel for the magnitude of the difference, consider the following code, intended for use on an 8051: 


void main(void) 

{ 
  uint8_t array[16];
  uint8_t data *ptr = array; /* Note use of data qualifier */ 
  uint8_t i; 

  for(i=0; i<16; i++) 
    *ptr++ = i; 
} 


Using a generic pointer, this code requires 571 cycles and 88 bytes. Using a typed data pointer, it needs just 196 cycles and 52 bytes.

With these sorts of performance increases, I recommend always using explicitly typed pointers, and paying the price in loss of portability and readability.

Source: http://www.embedded.com/98/9811/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In terms of AVR-GCC's treatment of the AVR architecture's 3 major data spaces (Flash, EEPROM, and SRAM), there is no such concept as a "generic" or a "typed" pointer. All pointers are assumed to point to the unified GPR/SFR/SRAM address space. Code to trivially dereference data pointers in the conventional "C" manner is always generated to operate on the SRAM address space, no matter how the pointers were declared.

This actually renders pointers to the Flash and EEPROM address spaces useless, unless you go out of your way to tell the compiler to act otherwise.

If you want to access data in Flash or EEPROM, you must explicitly write code that does so. It effectively gives you similar optimization benefits as typed pointers, but it arrives there from the opposite direction. (It doesn't strictly require a typed pointer: it actually requires applying special macros each time you write code that dereferences the pointer.)

As far as accessing the SFRs (I/O memory) using optimal IN/OUT etc instructions - well, those instructions are only possible if you are operating on a compile-time constant address. With optimization enabled, AVR-GCC is usually able to recognize those compile-time constant addresses and apply the I/O instructions for you automatically. In general, though, you're more likely to get optimal results if you never explicitly use pointers to access the I/O space at all, but rather use the register names in direct expressions when reading/writing I/O registers.