From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Redundant type checking in window.c and w32menu.c Date: Thu, 21 Jun 2007 13:38:17 -0400 Message-ID: References: <4677EBCA.7020405@yandex.ru> <467935CA.9020808@yandex.ru> <467945AF.6010305@gnu.org> <46796A22.000002.16656@pantene.yandex.ru> <46799227.3070905@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182447513 14621 80.91.229.12 (21 Jun 2007 17:38:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Jun 2007 17:38:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 21 19:38:31 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I1Qc0-0005gU-NY for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 19:38:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1Qc0-00026q-Ck for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 13:38:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I1Qbv-00025i-A2 for emacs-devel@gnu.org; Thu, 21 Jun 2007 13:38:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I1Qbu-00025M-F6 for emacs-devel@gnu.org; Thu, 21 Jun 2007 13:38:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1Qbu-00025B-7x for emacs-devel@gnu.org; Thu, 21 Jun 2007 13:38:22 -0400 Original-Received: from sccrmhc15.comcast.net ([204.127.200.85]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I1Qbs-0006c1-Bt; Thu, 21 Jun 2007 13:38:20 -0400 Original-Received: from raeburn.org (c-65-96-188-63.hsd1.ma.comcast.net[65.96.188.63]) by comcast.net (sccrmhc15) with ESMTP id <20070621173819015007r3bje>; Thu, 21 Jun 2007 17:38:19 +0000 Original-Received: from [69.25.196.100] (fwoosh.raeburn.org [69.25.196.100]) by raeburn.org (8.12.11/8.12.11) with ESMTP id l5LHcJJv000814; Thu, 21 Jun 2007 13:38:19 -0400 (EDT) In-Reply-To: <46799227.3070905@gnu.org> X-Mailer: Apple Mail (2.752.2) X-detected-kernel: NetCache Data OnTap 5.x X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73536 Archived-At: 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