[ECOS] small issue regarding hal_jmp_buf type declaration

[sandeep]

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