From mboxrd@z Thu Jan 1 00:00:00 1970 From: mjn3@codepoet.org (Manuel Novoa III) Subject: Re: More dev86 changes (0.16.5) Date: Thu, 25 Jul 2002 09:42:19 -0600 Sender: linux-8086-owner@vger.kernel.org Message-ID: <20020725154219.GA2577@codepoet.org> References: <449ac7bad6f7380a@mayday.cix.co.uk> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Riley Williams Cc: Robert de Bath , Linux-8086 Robert and Riley, First, thanks Robert for all the work you've done in integrating and improving these changes. It will certainly make my work easier. On Wed, Jul 24, 2002 at 11:02:44PM +0100, Riley Williams wrote: > >> 1) #elif support. > > > In 0.16.5 > > Do we want #elifdef too? > > If we support it as a variant of #if then we also want it as a variant > of #elif as well, in my opinion. Therefore, we will want... > > #elif > #elifdef > #elifndef > > ...together with any other variants that may exist. > Also (inspired by the way it's used in your example below, but taken > from a C compiler I once used on a Burroughs B6700 mainframe), could > support be added for the following... > > a. #debug msg > b. #debugn msg > c. #info msg > d. #onerr msg #elif is C89. While the others could be convenient at times, I know that I wouldn't use them for portability reasons. > I would like to see the code produe a warning for the fact that the > macro defenition for strong_alias() includes the terminating semicolon > that should never be present on macro definitions - and yes, I know the > Linux kernel uses several macros that break this rule. Linus himself > states that they're wrong, but they're so well embedded that it's more > hassle than it's worth to fix the problem... The trailing semicolon was strictly a convenience thing. The uClibc code contains several instances of strong_alias(). Generally where it is used, there is no trailing semicolon. This caused a problem when building with bcc since, although the patch allowed asm() to be used at file scope, it was still a statement and needed trailing semicolon for bcc to be happy. Rather than change all the offending instances in uClibc at the time, I just put the ';' in the bcc macro definition. I've got no problem changing this before the port is committed. > One other thing I would like to see, which is an optimising measure more > than anything: When bcc lays out the variables at any level, if it sorts > them in descending order of size before laying them out, it will really > minimise the number of padding bytes needed to ensure correct alignment. > It is for this reason that when I am writing C code, I always list all > of the variables in descending size order, Same here. ;-) > but the compiler could make > this irrelevant, as many other optimising measures have become totally > irrelevant over the years. Manuel