My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 3: Harvard machines need special pointer handling
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  neil.johnson71
Closed:  Dec 2010


 
Project Member Reported by neil.johnson71, Jul 14, 2010
Harvard machines, like AVR, need special code for pointers stored in code ROM (e.g. flash).  Only applies to strings, but affects format strings, %s and %".  Also think about putting padding (space and zero) strings into ROM.  Ideally a unified interface to the consumer function, rather than needing two consumer functions (messy).

One option is a data type with a union for the two pointer types and a type specifier.  Wrap all this up in a struct.  Could be

struct str_ptr {
   union {
      const char * dptr;
      FLASH_MEM  * cptr;
   } u;
   enum { DATA_PTR, CODE_PTR } access;
};

(or whatever goes in "FLASH_MEM")

Then dynamic string would be:

struct str_ptr p;
p.access = DATA_PTR;
p.u.dptr = /* pointer to string */

And ROM string would be:

struct str_ptr p;
p.access = CODE_PTR;
p.u.cptr = /* pointer to string */

Question: where does the string go:

    fmt( "hello" );

And so its type is..?
Nov 24, 2010
Project Member #1 neil.johnson71
Simplify the code to one emitting path.  Then for Harvard machines reduce this further to single character output.  This limits the scope of changes to support two string pointer types.  Then for each character read from ROM into a temporary and send to the consumer, so that does not need to change.
No need for weird data types then.
Mmmm.... it does add complexity in two places - in format() itself and in do_conv().  Also need a new qualifier for the %s and %" conversions to specify that the string pointer is a ROM pointer.  Would be good to use an existing one rather than invent another one.  Perhaps '#'?
Would make it easy to write a wrapper to format() to take a ROM format string, just use the continuation conversion with the new ROM flag.
Dec 8, 2010
Project Member #2 neil.johnson71
In the case of AVR, the following:

   fmt( "hello" );

puts the string both in the .data segment in ROM, and then copied at startup into the .data segment in RAM.  So the wrapper can be really simple with little waste.
Dec 28, 2010
Project Member #3 neil.johnson71
Fixed in change r79.
Status: Fixed

Powered by Google Project Hosting