This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How should -ffixed-@var{reg} global registers be identified for setjump coding?


Hi,

> Thank you, but if the declared global-registers are consistently declared
> at compile-time, including during the compile of an in-line asm coding of
> set/longjump (i.e. not embedded in a pre-compiled library), then as long
> as
> they can be procedurally identified, as the register allocator is
> hopefully
> doing to avoid using them itself, they should be able to be
> correspondingly
> identified and excluded from the save/restore jumpbuf state during its
> compilation if enabled through the use of a __reserved compiler function
> call or shared variable hopefully (I would like to think/hope), as
> otherwise
> the use of compile-time global registers and set/longjump like
> functionality
> is needlessly otherwise mutually exclusive, even if compiled with the same
> compile-time switches?

Rather longish but I hope I have understood it right.
Nice idea, but the problem remains one of consistency. One of the problems
which I can think of is a user inadvertently linking in a non-compliant
object module and then debugging it for the rest of his life to realize a
mistake in a command line option. So the optimization though nice has this
little problem .


Of course one naive foolproof way would be to maintain information about
the register partitioning ( I mean caller saved , callee saved, (GCC has
options to change the caller / callee save conventions) fixed registers)
and then do a simple consistency check at link time.



>
> (if there is no present method by which a source file can access this
> compiler defined data, is their a recommended method to define new
> reserved
> __function calls which may be invoked by a source file to access private
> compiler data?)


These are usually called builtins in GCC . You might like to provide this
as a builtin but the problem mentioned above will remain . Ofcourse if you
have a really tight closed system then it might work fine but someone
would have to remember this. Instead why don't you actually fix the
register you want to in the compiler and tailor it to ur need.


Or another option might be to do the following (well) hack ! Use the spec
file to define a macro for each register fixed using the ffixed-register
option.


Something like this in your specs file ..
*cpp:
%(cpp_cpu) %{fPIC:-D__PIC__ -D__pic__} %{posix:-D_POSIX_SOURCE}
%{pthread:-D_REENTRANT} %{ffixed-register-r1 -D__R1_DEFINED__ }

and so on.

and in your setjmp / longjmp implementation use conditional compilation
and the exact set of options of ffixed-registers . The liability is
ofcourse one of building setjmp and longjmp everytime, but it solves the
problem of maintaining consistency  albeit with a little more of a
headache of recompiling setjmp.c and longjmp.c everytime :-) .

HTH.

cheers
Ramana



----
Ramana Radhakrishnan
Codito Technologies


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]