[ECOS] Question about CYG_HAL_TABLE usage

[ECOS] Question about CYG_HAL_TABLE usage

[Grant Edwards]

I'm working with an app that uses the CYG_HAL_TABLE macros for seveal
different purposes.  I've always thought that the "END" label was at
the end of the "array" of objects, such that you can iterate a table
like this:


  for (p = __foo_TAB__; p < __foo_TAB_END__; ++p)
    {
      // process object pointed to by p    
    }    

But this seems not to be the case.  At least for Cortex M3 targets The
END label is aligned on an 8-byte boundary so that there may be up to
7 bytes of padding between the end of the table and the END label.

This means that 

 * If you use HAL_TABLE macros for objects smaller than 8 bytes, you
   have no way of knowing where the table actually ends.

 * If object size isn't a mulitple of 8, the last iteration in the
   loop above points to garbage.

Am I understanding this correctly?

Are there asserts that will detect an attempt to use a HAL_TABLE with
objects < 8 bytes long?

If I do understand the implementation, then the loop needs to be

  for (p = __foo_TAB__; p+1 <= __foo_TAB_END__; ++p)
    {
      // process object pointed to by p
    }
    
But again, that requires that object size be >= 8 bytes.

    
-- 
Grant Edwards               grant.b.edwards        Yow! Am I accompanied by a
                                  at               PARENT or GUARDIAN?
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Question about CYG_HAL_TABLE usage

[Daniel Helgason]

On Fri, 2013-10-11 at 21:48 +0000, Grant Edwards wrote:
> I'm working with an app that uses the CYG_HAL_TABLE macros for seveal
> different purposes.  I've always thought that the "END" label was at
> the end of the "array" of objects, such that you can iterate a table
> like this:
> 
> 
>   for (p = __foo_TAB__; p < __foo_TAB_END__; ++p)
>     {
>       // process object pointed to by p    
>     }    
> 
> But this seems not to be the case.  At least for Cortex M3 targets The
> END label is aligned on an 8-byte boundary so that there may be up to
> 7 bytes of padding between the end of the table and the END label.
> ...

Yes, 8-byte alignment is the default alignment for entries in the
tables.

Check out hal/common/current/include/hal_tables.h and in particular
CYG_HAL_TABLE_TYPE macro. That should fix the problem.



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Question about CYG_HAL_TABLE usage

[Grant Edwards]

On 2013-10-11, Daniel Helgason <dhelgason@shaw.ca> wrote:
> On Fri, 2013-10-11 at 21:48 +0000, Grant Edwards wrote:

>> I'm working with an app that uses the CYG_HAL_TABLE macros for seveal
>> different purposes.  I've always thought that the "END" label was at
>> the end of the "array" of objects, such that you can iterate a table
>> like this:
>> 
>> 
>>   for (p = __foo_TAB__; p < __foo_TAB_END__; ++p)
>>     {
>>       // process object pointed to by p    
>>     }    
>> 
>> But this seems not to be the case.  At least for Cortex M3 targets
>> The END label is aligned on an 8-byte boundary so that there may be
>> up to 7 bytes of padding between the end of the table and the END
>> label...
>
> Yes, 8-byte alignment is the default alignment for entries in the
> tables.
>
> Check out hal/common/current/include/hal_tables.h and in particular
> CYG_HAL_TABLE_TYPE macro. That should fix the problem.

Thanks!  I don't know how I missed that. 

Actually I do know: it has to do with the practice of nesting
preprocessor macros 6 deep before you get to actual code.

But, I guess if it weren't for the multiple layers of misdirection,
you would end up having to use gnu binutils and gcc for building eCos
instead of being able to use any toolchain you wanted.

;)

-- 
Grant





-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss