Date: Wed, 30 Jan 2002 00:55:55 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Dallas De Atley <deatley@apple.com> Cc: arch@freebsd.org Subject: Re: __P macro question Message-ID: <3C57B51B.F38D1906@mindspring.com> References: <FD5651F8-1537-11D6-993F-003065766C3C@apple.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dallas De Atley wrote:
> My question was: What is the __P macro used for in all those
> function declarations in the BSD libraries and do we still need it?
>
> It was explained that this macro is used for pre-ANSI C compilers
> and that while Darwin and thus Mac OS X compile with gcc 2.95, we retain
> it in our code so that the diffs between our code and yours is small.
> This enables the Darwin team to keep on top of changes between FreeBSD
> and Darwin.
[ ... ]
> Is the __P macro still necessary? Are there pre ANSI C compilers
> FreeBSD wishes to support or is this macro effectively benign but
> useless?
>
> If it is still neccesary I'll move on to bothering the resident
> experts with other annoying questions, otherwise I'd like to pursue this
> issue further.
The first thing to note is that, unlike Linux, FreeBSD is
an entire UNIX-alike system, which means that it includes
a huge amount of code, not necessarily just kernel code,
and the protability of that code depends on the headers,
as well.
For example, if I wanted to replace libc on my Altos Xenix
system, it's possible for me to do so with the macros there
(the Altos supplied compiler is non-ANSI, and has the side
benefit of being able to generate code that runs on about
16 different platforms, unlike the SCO Xenix compiler, the
Microport UNIX compiler, the Oregon compiler, etc., etc.,
including GCC, which would require multiple SKUs, one per
platform, were it used to generate the program images).
Current policy is to not add the macro to new code, but to
not remove it on old code, in order to minimize gratuitous
changes to the source tree.
At one point in time, FreeBSD was x86 only, and 386BSD very
early on discarded the Net/2 multiple platform/architecture
source tree layout. This is generally recognized as a
mistake these days (now that every *BSD *except* 386BSD is
multiple platform/architecture), so minimizing gratuitous
differences is considered an important project objective,
allowing easy movement of source code between the *BSD
systems.
Not everyone agrees with the complete conversion to code
that can only be compiled with an ANSI C compiler; I don't,
and several other conservative *BSD people from way back
like the idea that the code will compile with an old K&R
standard compiler.
Another argument (a good one, I think) is that, as the *BSD
code is intended as a reference implementation from which
technology may be excerpted, increasing the barrier to
entry by requiring an ANSI C compiler increases the
probability that a company would write its own code, which
would then fail to interoperate correctly. We can see an
example of this in a recent thread on the -hackers list, in
which a programmer wrote a telnet client from scratch, and
did not realize that the option negotiation sequence order
was used by the telnet to identify older TCP/IP stacks to
the server in order that clients on such systems could
interoperate correctly with servers running a newer stack;
if the telnet code itself had not been so opaque with all
sorts of "magic" security code, the author could have used
it as a starting pointm and the problem would not have
occurred in the first place.
Whether this is because we wish to take code and run it on
an older UNIX or UNIX-like system (e.g. SVR3.2, Altos
Xenix, Ultrix 4.2, Unice on VMS, etc.), or because we feel
that bootstrapping on an older architecture will probably
use the native compiler, which may be a K&R compiler, is
less relevent than overall portability, though there are
portability and interoperability issues as well (as noted
above).
One real problem, at least from my perspective, is that I
don't want to have to port GCC, and then be its maintainer
for two years (in order to comply with the distribution
requirements of the GCC), should I wish to port FreeBSD to
an older system, or an embedded system where there is not
already a GCC port, backe end code generator, or both. It
is unlikely that the modifications to the compiler needed
to support such a platform would be rolled into the GCC
distribution proper, which makes you liable for two years
of distribution of the code, following any minor compiler
modification. This doesn't even take into account the
cost of porting both the compiler and the OS, instead of
merely the OS.
A company, once in this position, ends up having to set up
a trust to maintain source availability, should they fail
and go out of business ("Who ever heard of a startup failing?").
Another problem is that moving to code that compiles only
with an ANSI compiler has a tendency to increase reliance
on GCC-specific constructs. Right now, there are several
GCC-isms in the code, and they will only be encouraged to
spread by making the code GCC-compliant (as opposed to
merely ANSI-compliant). Some of these are:
1) auto array declaration with a variable element
size, as in:
foo( int n)
{
int myarray[ n];
}
This is legal in GCC, but not legal in ANSI-C, and
is used in at least one place that I know of in
FreeBSD, making it written in GCC-C, not ANSI-C.
2) Use of inline asm(), rather than seperation of
source files into machine dependent and independent
parts; while this is getting better, there's a lot
of code in /sys/i386/*.c that should probably be
shared, instead of repeated on a platform basis.
3) Use of __attribute() tags. These are used for the
so-called "dead" code attribute, and also for the
identification of "printf-like" functions -- the
varradic functions that take format identifiers and
require that there be a format element per argument
in the remaining argument list following the format
specifier. Some of these are warapped with "#ifdef"
for GCC specificity, but most are not. Other use of
this tag would be better handled through the use of
"#pragma", as in "#pragma pack(1)" for structure
packing for direct mapping of hardware registers;
this is complicated by architectures with strict
alignment requirements for objects a multiple of a
byte in length (e.g. Alpha or 486 and up, with the
alignment flag set in the CPU control word).
4) Use of linker sets. Most of these are wrapped; I
have to admit that it was my introduction of the
"SYSINIT" mechanism that really made these a pain
to live without. However, compilers capable of
handling C++ can handle this as well, and it's also
possible to deal with this less graciously: my
originally submitted SYSINIT() code could handle
this by the SYSINIT()'s being sed'ed out, and a ".c"
file generated to manually create a statically
linked object file containing what would have been
in the linker set, had linker sets been available.
Personally, I'd really like to see the code stay portable,
and where it's not, abstract the portability problems out,
as time goes on -- not add to them by orphaning environments
where reference implementations are sometimes in fact the
most useful.
I'd also like to see the system able to compile self-hosting
on the Alpha with the Compaq compiler (a *significantly*
better compiler than the GCC compiler on Alpha, particularly
with the introduction of GCC 3.x, which so far produces
broken Alpha code, and the most recent binutils import, which
also causes problems on the Alpha, which currently can not
even make it successfully through a "make world").
I rather expect that, even if there is not sufficient interest
(and, honestly, the compiler doesn't generate as nice code) in
getting FreeBSD capable of self-hosting with the TenDRA
compiler system, getting a good (read: "commercial") Alpha or
SPARC compiler able to self-host FreeBSD would be a good thing
in most people's books. The Intel notes on compiling code for
the Pentium 4 processor read more like a "don't do what GCC
does!" criticism, than release notes.
There has also been rumors that Intel would release the IA64
and even Pentium 4 (and perhaps earlier) versions of their
compiler un some form of Open Source license... perhaps even
as the GCC code generator for Intel systems, getting it
adopted by GCC.
There are a number of sound commercial reasons for doing this,
in particular, if you control the compiler technology for the
compiler that people grab off the net in order to benchmark
hardware, this could not but help make your hardware look
better than anyone elses; it remains to be seen if this rumor
is true, but if it is, then it would be nice if FreeBSD were
capable of being compiled with the compiler when it became
available, instead of 8-10 months down the road.
PS: Given that you represent Apple, which has a strong
commitment to the Motorolla PowerPC architecture, you might
want to put a bug in someone's ear about considering doing
the same for a Motorolla or IBM originated PPC compiler,
which will certainly outperform GCC's PPC code generator
on that platform as well.
PPS: If anyone from Sun is reading this... same for SPARC.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C57B51B.F38D1906>