Re: [ECOS] small issue regarding hal_jmp_buf type declaration

[sandeep <shimple0 at yahoo dot com>]

ugh! that was quite stupid doubt to start with in hurry, as i found when i
revisited the issue day before yesterday.

> what are the issues if one typedefs hal_jmp_buf to hal
> specific structure like -
>
> typedef struct some_hal_jump_buffer hal_jmp_buf;
this won't work. a short explanation for interested, is below.

hal_jmp_buf jmp_buf;

hal_setjmp(jmp_buf);

we expect the address of a jump buffer in hal_setjmp call.
in above case, things will obviously go for a toss.

> typedef cyg_uint32 hal_jmp_buf[...]
> __attribute__((aligned(8));

> even if it did work same way, things will not work out
> as expected, if application writer happens to define
> an array of hal_jmp_buf type (array cells at index
> 1/3/5/.... are not 8 bytes aligned)

typedef cyg_uint32 hal_jmp_buf[XX]  __attribute__((aligned(8));
adjusting XX to a multiple of 8 takes care for arrays situation as well. though 
this means unused/padding space per hal_jm_buf type variable/structure 
member/array cell.

> there is alternate solution - that is bit dirty - and
> involves keeping one extra dummy register space in
> jump buffer array, that could be used in get the
> necessary alignment in hal_setjmp/hal_longjmp
> functions, but the macros indicating locations of a
> particular saved register in jump buffer won't make
> sense.
that looked dirty because of confusing it with something else at that time. just
minor rearrangement was needed and not atall dirty.

sandeep
---------------------------------------------------------
visit me at http://members.fortunecity.com/sandeepkumar/


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