This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
small issue regarding hal_jmp_buf type declaration
- From: sandeep <shimple0 at yahoo dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 3 Nov 2004 04:29:55 -0800 (PST)
- Subject: [ECOS] small issue regarding hal_jmp_buf type declaration
type declaration for hal_jmp_buf are always of
following form -
typedef cyg_uint32 hal_jmp_buf[CYGARC_JMP_BUF_SIZE];
in case, some structure is defined to contain jump
buffer information, instead of macro
"CYGARC_JMP_BUF_SIZE" it becomes
"sizeof(hal_jmp_buf_t) / sizeof(cyg_uint32)"
what are the issues if one typedefs hal_jmp_buf to hal
specific structure like -
typedef struct some_hal_jump_buffer hal_jmp_buf;
since all the hal_jmp_buf manipulation will be done by
hal specific functions, there doesn't seem to be any
issue, unless there is something i am missing and some
standard for declaring jump_buf type requires it to be
done the way it is done.
please advise.
why i need it? this architecture, on which i am still
working as there is nothing else to do, has some
instructions that can save/load two registers with one
instruction, but require the load/store addresses to
be 64bit aligned. using these instructions code for
hal_setjmp/hal_longjmp would be reduced in
size/execution-time.
the toolchain for this architecture is still in 2.9x
days and doesn't seem to support alignment for newly
defined typename. i.e.
typedef cyg_uint32 hal_jmp_buf[...]
__attribute__((aligned(8));
does not behave same way as it does with gcc 3.3.1 on
cygwin (individual variable declarations are 8 bytes
aligned).
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)
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.
sandeep
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.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