Prev: IAR EWARM vs NXP ARMs, again
Next: CY7C68013A:ezusb.sys driver receives a trash data
From: Jon Kirwan on 30 Jun 2010 15:31
On Wed, 30 Jun 2010 12:29:26 -0700, I wrote:

>The above is general theory and applies broadly.

And I'm still not sure _why_ you actually want position
independence in code and data. If this is the entire
application and there is nothing else present, no operating
system for example, then why do you care? Just let the tools
do their job using mainstream approaches.

Jon
From: Paul Keinanen on 30 Jun 2010 16:13
On Wed, 30 Jun 2010 08:41:42 -0700 (PDT), nono240 <nono240(a)gmail.com>
wrote:

>Hi there !
>
>My CPU has no MMU, very little RAM (8KB),

A few decades ago, this was a typical minicomputer configuration with
8-64 KiD of core, occupying at least one rack.

>and is running a modified
>FreeRTOS.

Running any kind of pre-emptive multi tasking requires some kind of
per task stack.

To be practical, this requires a processor with a stack pointer and
addressing modes that are stack pointer relative. As an absolute
minimum, some index register+offset addressing is required (unless
self modified code is used :-).

>I'd like to have the ability to "load" and run some code
>from USART/DATAFLASH to FLASH as a RTOS task. Of course, for
>convenience, the compiled code must be fully position independent.

You really have to study the instruction set of your processor very
carefully to find the most effective way of handling things.

There is no single "correct" answer to your problem.

From: D Yuniskis on 30 Jun 2010 18:07
nono240 wrote:
> Hi there !
>
> My CPU has no MMU, very little RAM (8KB), and is running a modified
> FreeRTOS. I'd like to have the ability to "load" and run some code
> from USART/DATAFLASH to FLASH as a RTOS task. Of course, for
> convenience, the compiled code must be fully position independent.
> Using the -fPIC or -fpic option, looking at the assembler, the code
> seems OK : a dynamically computed offset is applied to every
> operations.
>
> BUT, looking deeply, both DATA and CODE are applied the base offset !
> While this is the expected behavior for CODE (running anywhere in
> FLASH), moving my CODE over the entire flash space doesn't mean moving
> my RAM ! This make only sense when executing everything from SDRAM !
>
> I'm looking for a solution to generate position independent *code*,
> but with position dependent *data* using GCC/LD... Any help ?

I find, in resource starved applications, using interpreters
is a big win. If you're loading apps dynamically, I suspect
the speed penalty would be insignificant (esp with careful
choice of language)
From: George Neuner on 1 Jul 2010 00:05
On Wed, 30 Jun 2010 08:41:42 -0700 (PDT), nono240 <nono240(a)gmail.com>
wrote:

>Hi there !
>
>My CPU has no MMU, very little RAM (8KB), and is running a modified
>FreeRTOS. I'd like to have the ability to "load" and run some code
>from USART/DATAFLASH to FLASH as a RTOS task. Of course, for
>convenience, the compiled code must be fully position independent.
>Using the -fPIC or -fpic option, looking at the assembler, the code
>seems OK : a dynamically computed offset is applied to every
>operations.
>
>BUT, looking deeply, both DATA and CODE are applied the base offset !
>While this is the expected behavior for CODE (running anywhere in
>FLASH), moving my CODE over the entire flash space doesn't mean moving
>my RAM ! This make only sense when executing everything from SDRAM !
>
>I'm looking for a solution to generate position independent *code*,
>but with position dependent *data* using GCC/LD... Any help ?

Dynamic data, stack and heap (even if static) typically isn't a
problem with PI code because you always need to specify where their
locations and those values can be set dynamically when the code is
loaded ... it's usually only compile time static data that you need to
worry about when relocating code - you either need to copy the static
data with the code maintaining the relative spacing or rebase the data
to where it will be when the code runs.

There ought to be a compiler option to base data references at a
different address from the code. Unfortunately, I have never needed
to do this using GCC so I can't tell you how. A quick manual search
didn't turn up anything, but GCC has so many switches you can go blind
trying to find the right one.

Even so, it won't necessarily help you unless you know at compile time
where the static data will be. Once you rebase, ALL relative
addressing will use the new base - if your CPU has a range limit for
relative addressing, it may not be possible to do what you want.

George
From: Peter Dickerson on 1 Jul 2010 02:34
"D Yuniskis" <not.going.to.be(a)seen.com> wrote in message
news:i0gf3s$kou$1(a)speranza.aioe.org...
> nono240 wrote:
>> Hi there !
>>
>> My CPU has no MMU, very little RAM (8KB), and is running a modified
>> FreeRTOS. I'd like to have the ability to "load" and run some code
>> from USART/DATAFLASH to FLASH as a RTOS task. Of course, for
>> convenience, the compiled code must be fully position independent.
>> Using the -fPIC or -fpic option, looking at the assembler, the code
>> seems OK : a dynamically computed offset is applied to every
>> operations.
>>
>> BUT, looking deeply, both DATA and CODE are applied the base offset !
>> While this is the expected behavior for CODE (running anywhere in
>> FLASH), moving my CODE over the entire flash space doesn't mean moving
>> my RAM ! This make only sense when executing everything from SDRAM !
>>
>> I'm looking for a solution to generate position independent *code*,
>> but with position dependent *data* using GCC/LD... Any help ?
>
> I find, in resource starved applications, using interpreters
> is a big win. If you're loading apps dynamically, I suspect
> the speed penalty would be insignificant (esp with careful
> choice of language)

Any suggestions for such interpretters, Don? Experiences?

Peter


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: IAR EWARM vs NXP ARMs, again
Next: CY7C68013A:ezusb.sys driver receives a trash data