From owner-freebsd-arch Thu Jan 31 14:36:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by hub.freebsd.org (Postfix) with ESMTP id 5E5A337B405 for ; Thu, 31 Jan 2002 14:36:14 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by renown.cnchost.com id RAA00395; Thu, 31 Jan 2002 17:36:12 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200201312236.RAA00395@renown.cnchost.com> To: Jeroen Ruigrok/asmodai Cc: arch@FreeBSD.ORG Subject: A C dialect called GCC C (was Re: __P macro question) In-reply-to: Your message of "Thu, 31 Jan 2002 08:34:30 +0100." <20020131073430.GR22384@daemon.ninth-circle.org> Date: Thu, 31 Jan 2002 14:36:11 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > -On [20020130 20:45], Bakul Shah (bakul@bitblocks.com) wrote: > >Similarly, if Terry were to make the changes to the FreeBSD > >kernel to compile it with TenDRA (and make it work) at least > >I would be very grateful to him -- I do think relying so much > >on GCC is a bad idea but I am realistic (and lazy) enough to > >not want to fix that on my own. > > As someone who has been hacking TenDRA for a while now and trying to get > it up-to-date a bit, I can tell you FreeBSD is written in a C dialect > called GCC C. Yeah, I am well aware of it; which is why I raised this issue + the fact this is a much more serious issue than to __P or not to __P! I'd be interested to know what you found from your TenDRA hacking. From what I know, the GCC-isms used are: long long -- this is already in the C9x standard __attribute -- the common use seems to be for better type checking. I think one can live without this. asm() -- this is different for different processors in any case. But I agree some sort of asm support will most likely be needed. Also, the ability to mix C expressions as operands inline -- needed for performance. Already in C9x. typeof -- handy especially in macros but we can live without this with an extra macro arg where the type is passed in. ({...}) -- this is a way to declare local temp vars in an expression. There is no need for this given inline functions (though a bit more verbose) int array[n] -- variable length array. This is in C9x. // comments -- in C9x. I am not sure the following extensions are used in the kernel: alignment -- not sure if specifying alignment is needed in .c files int x = y; -- non constant initializers. Need an _init() section to deal with this. a?:b -- lazy conditional. Handy but can do without vararg macros -- this is in C9x in a slightly different form computed goto -- labels as lvalues. Improves interpreter performance but I doubt this is used in the kernel. global registers cast to unions etc. I am sure I have missed quite a few things but on first glance it seems the work needed to use TenDRA for compiling the kernel will also take it in the direction of C9x compliance, which is a good thing. Until TenDRA comes close to compiling the kernel there is no incentive for people to not use gccisms let alone remove the existing ones. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message