* [ECOS] Problem with CYG_HAL_TABLES
@ 2011-01-20 17:39 Jay Foster
2011-01-20 17:47 ` [ECOS] " Jay Foster
0 siblings, 1 reply; 4+ messages in thread
From: Jay Foster @ 2011-01-20 17:39 UTC (permalink / raw)
To: ecos-discuss
I have used the CYG_HAL_TABLE mechanism before with success, but I am
now running into an alignment problem with a new application. This is
on an ARM architecture.
I have an object defined as:
typedef struct
{
....
} CYG_HAL_TABLE_TYPE MY_TYPE;
I then declare the HAL table array as:
CYG_HAL_TABLE_BEGIN( _MY_LABEL_, _my_name_ );
CYG_HAL_TABLE_END( _MY_LABEL_END_, _my_name_ );
I then place two instances of the object into the HAL table array:
MY_TYPE my_instance1 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 2) =
{
....
};
MY_TYPE my_instance2 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 3) =
{
....
};
I then iterate the table using:
MY_TYPE *p;
for (p=&(_MY_LABEL_[0]); p!=&(_MY_LABEL_END_); p++)
{
}
This fails due to alignment issues:
The _MY_LABEL_ is not at the same address as the first element in
the array (my_instance1) due to alignment issues. The iteration then
fails. _MY_LABEL_ is aligned on a 4 byte boundary and the array
elements are aligned on 16 byte boundaries. Is there any way to make
this work?
Jay
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Re: Problem with CYG_HAL_TABLES
2011-01-20 17:39 [ECOS] Problem with CYG_HAL_TABLES Jay Foster
@ 2011-01-20 17:47 ` Jay Foster
2011-01-25 16:18 ` Sergei Gavrikov
0 siblings, 1 reply; 4+ messages in thread
From: Jay Foster @ 2011-01-20 17:47 UTC (permalink / raw)
To: ecos-discuss
Looking at the definition of CYG_HAL_TABLE_TYPE and CYG_HAL_TABLE_BEGIN,
I see that the CYG_HAL_TABLE_BEGIN uses an alignment of
CYGARC_P2ALIGNMENT and the CYG_HAL_TABLE_TYPE uses an alignment of
CYGARC_ALIGNMENT.
For the ARM architecture, these are defined to be different
(CYGARC_P2ALIGNMENT is 2 and CYGARC_ALIGNMENT is 4). This would result
in the table label being 4 byte aligned and the elements 16 byte aligned.
The question is why has this not caused me problems before this?
Jay
On 1/20/2011 9:30 AM, Jay Foster wrote:
> I have used the CYG_HAL_TABLE mechanism before with success, but I am
> now running into an alignment problem with a new application. This is
> on an ARM architecture.
>
> I have an object defined as:
>
> typedef struct
> {
> ....
> } CYG_HAL_TABLE_TYPE MY_TYPE;
>
> I then declare the HAL table array as:
>
> CYG_HAL_TABLE_BEGIN( _MY_LABEL_, _my_name_ );
> CYG_HAL_TABLE_END( _MY_LABEL_END_, _my_name_ );
>
> I then place two instances of the object into the HAL table array:
>
> MY_TYPE my_instance1 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 2) =
> {
> ....
> };
>
> MY_TYPE my_instance2 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 3) =
> {
> ....
> };
>
> I then iterate the table using:
>
> MY_TYPE *p;
>
> for (p=&(_MY_LABEL_[0]); p!=&(_MY_LABEL_END_); p++)
> {
> }
>
> This fails due to alignment issues:
>
> The _MY_LABEL_ is not at the same address as the first element in
> the array (my_instance1) due to alignment issues. The iteration then
> fails. _MY_LABEL_ is aligned on a 4 byte boundary and the array
> elements are aligned on 16 byte boundaries. Is there any way to make
> this work?
>
> Jay
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Re: Problem with CYG_HAL_TABLES
2011-01-20 17:47 ` [ECOS] " Jay Foster
@ 2011-01-25 16:18 ` Sergei Gavrikov
2011-01-25 18:42 ` Jay Foster
0 siblings, 1 reply; 4+ messages in thread
From: Sergei Gavrikov @ 2011-01-25 16:18 UTC (permalink / raw)
To: Jay Foster; +Cc: ecos-discuss
Hi Jay,
On Thu, 20 Jan 2011, Jay Foster wrote:
> Looking at the definition of CYG_HAL_TABLE_TYPE and
> CYG_HAL_TABLE_BEGIN, I see that the CYG_HAL_TABLE_BEGIN uses an
> alignment of CYGARC_P2ALIGNMENT and the CYG_HAL_TABLE_TYPE uses an
> alignment of CYGARC_ALIGNMENT.
>
> For the ARM architecture, these are defined to be different
> (CYGARC_P2ALIGNMENT is 2 and CYGARC_ALIGNMENT is 4). This would
> result in the table label being 4 byte aligned and the elements 16
> byte aligned.
It seemed for me "P2" stands for "power of 2", so 2^2 == 4 and that is
okay ~ http://sourceware.org/binutils/docs/as/P2align.html
For example for i386 architecture they defined
# define CYGARC_ALIGNMENT 32
# define CYGARC_P2ALIGNMENT 5
i.e. 2^5 == 32
> The question is why has this not caused me problems before this?
Jay, I tried your example 'as is' for a few ARM targets (LE/BE) (well I
could only guess what MY_TYPE is) and couldn't reproduce such a miss-
alignment for _MY_LABEL_.
I just use GDB to test your example for ARM targets
## .gdbinit --
set output-radix 16
target sim
print &(_MY_LABEL_)
print &(my_instance1)
detach
quit
This did print always the same addresses. Hm, puzzle. Just a guess, may
be you use some -falign-* GCC option? However, TAB macros written in
asm. And how did you declare the labels? Hope, that is something like
extern MY_TYPE _MY_LABEL_[],
_MY_LABEL_END_;
Is it possible to reproduce the issue if you will provide more
information?
Sergei
> On 1/20/2011 9:30 AM, Jay Foster wrote:
> > I have used the CYG_HAL_TABLE mechanism before with success, but I am now
> > running into an alignment problem with a new application. This is on an ARM
> > architecture.
> >
> > I have an object defined as:
> >
> > typedef struct
> > {
> > ....
> > } CYG_HAL_TABLE_TYPE MY_TYPE;
> >
> > I then declare the HAL table array as:
> >
> > CYG_HAL_TABLE_BEGIN( _MY_LABEL_, _my_name_ );
> > CYG_HAL_TABLE_END( _MY_LABEL_END_, _my_name_ );
> >
> > I then place two instances of the object into the HAL table array:
> >
> > MY_TYPE my_instance1 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 2) =
> > {
> > ....
> > };
> >
> > MY_TYPE my_instance2 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 3) =
> > {
> > ....
> > };
> >
> > I then iterate the table using:
> >
> > MY_TYPE *p;
> >
> > for (p=&(_MY_LABEL_[0]); p!=&(_MY_LABEL_END_); p++)
> > {
> > }
> >
> > This fails due to alignment issues:
> >
> > The _MY_LABEL_ is not at the same address as the first element in the
> > array (my_instance1) due to alignment issues. The iteration then fails.
> > _MY_LABEL_ is aligned on a 4 byte boundary and the array elements are
> > aligned on 16 byte boundaries. Is there any way to make this work?
> >
> > Jay
> >
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Re: Problem with CYG_HAL_TABLES
2011-01-25 16:18 ` Sergei Gavrikov
@ 2011-01-25 18:42 ` Jay Foster
0 siblings, 0 replies; 4+ messages in thread
From: Jay Foster @ 2011-01-25 18:42 UTC (permalink / raw)
To: Sergei Gavrikov; +Cc: ecos-discuss
I think that I have identified the issue for me. The last member of
MY_TYPE is a thread stack storage. It is declared as:
/* Thread stack */
cyg_uint8 stack[TASK_STK_SIZE] __attribute__((aligned(16)));
This apparently causes gcc to give the entire MY_TYPE object the same
alignment, even though only that one member of MY_TYPE needs it. I
worked around this by defining my own CYG_HAL_TABLE_BEGIN and
CYG_HAL_TABLE_END macros with the alignment changed to
CYGARC_ALIGNMENT. CYGARC_ALIGNMENT is 4, which is equivalent to
__attribute__((aligned(16))).
Although not the cause of my issue, I think that CYG_HAL_TABLE_BEGIN,
CYG_HAL_TABLE_END, and CYG_HAL_TABLE_TYPE should all use the same
alignment.
Jay
On 1/25/2011 6:02 AM, Sergei Gavrikov wrote:
> Hi Jay,
>
> On Thu, 20 Jan 2011, Jay Foster wrote:
>
>> Looking at the definition of CYG_HAL_TABLE_TYPE and
>> CYG_HAL_TABLE_BEGIN, I see that the CYG_HAL_TABLE_BEGIN uses an
>> alignment of CYGARC_P2ALIGNMENT and the CYG_HAL_TABLE_TYPE uses an
>> alignment of CYGARC_ALIGNMENT.
>>
>> For the ARM architecture, these are defined to be different
>> (CYGARC_P2ALIGNMENT is 2 and CYGARC_ALIGNMENT is 4). This would
>> result in the table label being 4 byte aligned and the elements 16
>> byte aligned.
> It seemed for me "P2" stands for "power of 2", so 2^2 == 4 and that is
> okay ~ http://sourceware.org/binutils/docs/as/P2align.html
>
> For example for i386 architecture they defined
>
> # define CYGARC_ALIGNMENT 32
> # define CYGARC_P2ALIGNMENT 5
>
> i.e. 2^5 == 32
>
>> The question is why has this not caused me problems before this?
> Jay, I tried your example 'as is' for a few ARM targets (LE/BE) (well I
> could only guess what MY_TYPE is) and couldn't reproduce such a miss-
> alignment for _MY_LABEL_.
>
> I just use GDB to test your example for ARM targets
>
> ## .gdbinit --
> set output-radix 16
> target sim
> print&(_MY_LABEL_)
> print&(my_instance1)
> detach
> quit
>
> This did print always the same addresses. Hm, puzzle. Just a guess, may
> be you use some -falign-* GCC option? However, TAB macros written in
> asm. And how did you declare the labels? Hope, that is something like
>
> extern MY_TYPE _MY_LABEL_[],
> _MY_LABEL_END_;
>
>
>
> Is it possible to reproduce the issue if you will provide more
> information?
>
>
> Sergei
>
>> On 1/20/2011 9:30 AM, Jay Foster wrote:
>>> I have used the CYG_HAL_TABLE mechanism before with success, but I am now
>>> running into an alignment problem with a new application. This is on an ARM
>>> architecture.
>>>
>>> I have an object defined as:
>>>
>>> typedef struct
>>> {
>>> ....
>>> } CYG_HAL_TABLE_TYPE MY_TYPE;
>>>
>>> I then declare the HAL table array as:
>>>
>>> CYG_HAL_TABLE_BEGIN( _MY_LABEL_, _my_name_ );
>>> CYG_HAL_TABLE_END( _MY_LABEL_END_, _my_name_ );
>>>
>>> I then place two instances of the object into the HAL table array:
>>>
>>> MY_TYPE my_instance1 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 2) =
>>> {
>>> ....
>>> };
>>>
>>> MY_TYPE my_instance2 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 3) =
>>> {
>>> ....
>>> };
>>>
>>> I then iterate the table using:
>>>
>>> MY_TYPE *p;
>>>
>>> for (p=&(_MY_LABEL_[0]); p!=&(_MY_LABEL_END_); p++)
>>> {
>>> }
>>>
>>> This fails due to alignment issues:
>>>
>>> The _MY_LABEL_ is not at the same address as the first element in the
>>> array (my_instance1) due to alignment issues. The iteration then fails.
>>> _MY_LABEL_ is aligned on a 4 byte boundary and the array elements are
>>> aligned on 16 byte boundaries. Is there any way to make this work?
>>>
>>> Jay
>>>
>> --
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-01-25 16:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-20 17:39 [ECOS] Problem with CYG_HAL_TABLES Jay Foster
2011-01-20 17:47 ` [ECOS] " Jay Foster
2011-01-25 16:18 ` Sergei Gavrikov
2011-01-25 18:42 ` Jay Foster
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).