avr-gcc-list
[Top][All Lists]
Advanced

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

Re: [avr-gcc-list] fixed address for PROGMEM


From: Simon Han
Subject: Re: [avr-gcc-list] fixed address for PROGMEM
Date: Thu, 13 Nov 2003 14:49:14 -0800 (PST)


On Wed, 12 Nov 2003, Joerg Wunsch wrote:

> As Erik Christiansen <address@hidden> wrote:
>
> >There may be relevant expertise on the list. I don't know if building
> >gcc with "-fPIC" or "-fpic" is realistic for this target.
>
> Not in the general case.  AVRs with <= 8 KB of ROM do use PC-relative
> addressing anyway, but for devices with larger ROMs, it's impossible
> to reach an arbitrary destination with a relative jump or call.  So I
> figure it's not possible to implement PIC (position-independent code)
> there.  (A completely self-contained library module could perhaps be
> made position-independent, as long as it fits into this 8 KB limit.)

I do not totally understand the detail of "-fPIC".  However, above
description seems to refer to calling system functions in the module.

I am trying to figure out a way to dynamically insert a new module during
run-time.  The idea is similar to linux insmod.  Basically, each module
defines a function to be called when a message is destinated to it.
Module requests service by sending message using known function with known
address.

One question comes out of this.  How can I handle static data defined in
the module.  Assume the module has follow layout.

static int16_t state;

int16_t handler(Message *msg){
  Do_Something_With_msg();
}

Now if I compile this code to SREC format, do I have to change every
reference to "state" when I change the location of module during runtime?

Will "-fPIC" help in this case?

>
> > Where would
> >the shared library be loaded from?
>
> Good question. ;-)  It has to be brought into ROM (Harvard
> architecture), but newer AVRs can do self-programming.

Right!  The runtime system (operating system?)  will keep a map of free
flush space.  When module comes in, it will remap to the empty space.
Register the message handler and now we have new module.

Of course, module will need to keep some state information.  One way is to
always ask runtime system to pass the state information.  Then, message
handler will become

int16_t handler(void *state, Message *msg){

}

I am not expert of either linux module or compiler.  Just thought this
idea is cool.  :-)

Thank you for any help,
Simon


reply via email to

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