[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redundant type checking in window.c and w32menu.c
From: |
Ken Raeburn |
Subject: |
Re: Redundant type checking in window.c and w32menu.c |
Date: |
Thu, 21 Jun 2007 13:38:17 -0400 |
On Jun 20, 2007, at 16:46, Jason Rumney wrote:
Is this optimisation really worth the confusion of having two versions
of these functions in the code?
We could use a new macro DEFUN_INLINE, like so:
#if CAN_DO_INLINE || defined PROVIDE_ADDRESSABLE_IMPLEMENTATION
DEFUN_INLINE ("car", Fcar, Scar, ....)
(list)
Lisp_Object list;
{
...;
}
#else
EXFUN(Fcar, 1);
#endif
where:
PROVIDE_ADDRESSABLE_IMPLEMENTATION: Is defined in exactly one Emacs
source file, say, data.c, before lisp.h is included.
CAN_DO_INLINE: Is true if the compiler, with the current options,
supports inline functions in some useful form. (E.g., it could
expand to test __GNUC__, __OPTIMIZE__, __STDC_VERSION__, etc.) For
brevity, we could also define a macro that tests both this property
and PROVIDE_ADDRESSABLE_IMPLEMENTATION.
DEFUN_INLINE: If inline functions are not supported, expands to the
same as DEFUN. Otherwise, tests PROVIDE_ADDRESSABLE_IMPLEMENTATION
and makes an addressable version if it's defined, and an inline
version if not. Depending on the compiler, "inline", "static
inline", "extern inline", or other keywords may be used.
In older GCC compilers, "extern inline" means "expand inline or
generate a reference to an external copy defined elsewhere, but don't
provide an external definition or static copy", while "inline" would
produce an external definition. ISO C 99 has a different meaning for
"extern inline", in fact I think the handling of "extern inline" and
"inline" may be almost exactly reversed from the old GCC handling,
and GCC is adapting to the spec but providing some attributes for
finer control I think. Using "static inline" sidesteps the issue but
risks producing multiple static copies of the function if it's not
expanded inline. But there are also GCC version number macro tests
and autoconf feature test cases possible. This could make defining
DEFUN_INLINE a little bit complicated, but the use of it should be
pretty straightforward.
Then, data.o gets an addressable copy of the function for use in
defining the Lisp symbol, and it can be expanded inline in other
source files when the compiler supports it. Debuggers on some older
platforms may not handle functions defined in header files very well,
but with inline expansion happening, you're not likely to be able to
set breakpoints in these functions usefully anyways.
(On a vaguely related note, is it time to start assuming at least
ANSI C '89 support, like prototypes, in the Emacs sources yet?)
Ken
Re: Redundant type checking in window.c and w32menu.c, Stefan Monnier, 2007/06/19