[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:

DEFUN_INLINE ("car", Fcar, Scar, ....)
  Lisp_Object list;
EXFUN(Fcar, 1);


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?)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]