FreeBSD Most wanted

Willie Viljoen will at unfoldings.net
Thu Mar 4 22:44:19 PST 2004


----- Original Message -----
From: "Daniela" <dgw at liwest.at>
To: "Johnson David" <DavidJohnson at Siemens.com>;
<freebsd-advocacy at freebsd.org>
Sent: Friday, March 05, 2004 8:15 AM
Subject: Re: FreeBSD Most wanted


> On Thursday 04 March 2004 23:12, Johnson David wrote:
> > On Thursday 04 March 2004 02:40 pm, Daniela wrote:
> > > Cross platform applications are slower than apps that are optimized
> > > for one particular platform. I know what I'm speaking of. What are
> > > the extended features of a platform good for, when you can't use them
> > > because another platform doesn't have them?
> >
> > Not necessarily true. You won't be able to perform any platform specific
> > optimizations, but in general cross platform code is not any slower
> > than platform specific code. Three examples: NetBSD, Linux kernel, Qt.
> > Neither NetBSD nor Linux are considered "slow" by any stretch of the
> > imagination. Qt is impresively fast, and is only called "sluggish" by
> > biased trolls.
>
> I'm not speaking of your average code, I'm speaking of high-speed assembly
> language programs.
>

True, assembly language, you will generally find, differs for each seperate
platform. This presents a unique hurdle to cross platform development, but
it is not one that cannot be overcome. Again, my favourite new jargon term,
the abstraction layer, can come in to help us get around this problem.

The first step in getting to an environment where every application works
with almost every computer is to begin designing the ultimate abstraction
layer for your program. Yes, you will have to move away from assembly, to
something slightly less low level, but C would be more than sufficient.
Better yet, if you take the time to make your code ANSI C compliant, you've
already crossed one hurdle, any recent C compiler on any platform should now
be able to compile your code.

Next, you want to look at all the different optimizations available for each
platform. The trick here is to identify similarities between extensions on
each platform. Now, writing your abstraction layer, in each of your drivers,
you want to make full use of the extensions in each platform, also, you want
to write compatibility "kludges" for every single feature you use. In this
way, you can write the program to talk to the abstraction layer only. Then,
your abstraction layer can be written to take full advantage of an extension
if it is present, or kludge around it if it isn't.

Furthermore, your application can be seperately compiled on each platform.
The possibility has long existed to compile code selectively, even
conditionally compiling only certain parts of individual files. Compiling on
each platform in this way will only use extensions native to that platform.
The program will only talk to its abstraction layer and won't notice the
difference. The abstraction layer will be compiled with optimizations for
each platform. As all C compilers do not actually compile into machine
language, but generate an assembly dump which is then optimized and compiled
to machine code, this will get you as close as you can be to rewriting the
program in assembly for each platform.

What you will end up with is a program that can move almost effortlessly
between platforms, without sacrificing on performance or the use of
features. If you want a good case in point here, you need only look at
NetBSD, which runs on more platforms than any other operating system, and
can not be accused of being slow or unoptimized. A good demonstration of
writing code in this way can also be found in the Linux kernel. When
compiling Linux, the target platform is one of the first choices you face.
When an appropriate platform is selected, conditional compiling builds the
kernel in such a way that all available extensions for that platform are
made use of.

Writing applications to do the same is not that hard, and the payoff is
better integration and compatibility for everyone.

Will



More information about the freebsd-advocacy mailing list