Path: gmd.de!xlink.net!howland.reston.ans.net!cs.utexas.edu!convex!news.utdallas.edu!corpgate!bnrgate!bcars6a8.bnr.ca!bmerha64.bnr.ca!news@bmerha64
From: Hamish.Macdon...@bnr.ca (Hamish Macdonald)
Newsgroups: comp.os.linux.development
Subject: Future development of Linux and affects on other architectures
Date: 15 Mar 1994 21:21:06 GMT
Organization: I speak for nobody but myself
Lines: 21
Message-ID: <2m58s2$86q@bmerha64.bnr.ca>
NNTP-Posting-Host: bmerhae5.bnr.ca
I'd just like to mention here that anyone who is developing new
features in Linux, or is enhancing existing features to add new
functionality should keep in mind that Linux is being ported to other
architectures.
Any time you feel the urge to put inline assembler into code which has
no direct link to either the i386 architecture or the IBM PC clone
architecture, think twice before doing so.
If you absolute must put in inline assembler (speed reasons are the
only possible reason I can see), please abstract it out into an
"inline function" or a preprocessor macro, and keep the definition of
the inline function or macro separate from the main functionality.
If you follow rules like this, then it makes porting of these new
features to Linux on other architectures easier.
An example of the benefits of this is the fact that the "net/unix"
Unix domain socket code ported over to Linux/68k with absolutely no
changes required to the source. I was very happy when I was able to
do this.
Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!howland.reston.ans.net!cs.utexas.edu!uunet!hearst.acc.Virginia.EDU!murdoch!cebaf4!doolitt
From: dool...@cebaf4.cebaf.gov (Larry Doolittle)
Subject: Re: Future development of Linux and affects on other architectures
Message-ID: <CMrHE1.FCH@murdoch.acc.Virginia.EDU>
Sender: use...@murdoch.acc.Virginia.EDU
Reply-To: dool...@cebaf4.cebaf.gov (Larry Doolittle)
Organization: CEBAF
References: <2m58s2$86q@bmerha64.bnr.ca>
Date: Wed, 16 Mar 1994 14:25:13 GMT
Lines: 55
In article <2m58s2$...@bmerha64.bnr.ca>, Hamish.Macdon...@bnr.ca (Hamish
Macdonald) writes:
> I'd just like to mention here that anyone who is developing new
> features in Linux, or is enhancing existing features to add new
> functionality should keep in mind that Linux is being ported to other
> architectures.
I agree fully.
> Any time you feel the urge to put inline assembler into code which has
> no direct link to either the i386 architecture or the IBM PC clone
> architecture, think twice before doing so.
> If you absolute must put in inline assembler (speed reasons are the
> only possible reason I can see), please abstract it out into an
Speed concerns are real! Not everyone has a Pentium, remember.
> "inline function" or a preprocessor macro, and keep the definition of
> the inline function or macro separate from the main functionality.
... When you do, it should take the form:
#ifndef i386
simple {
c;
substitute();
}
#else
high
speed
assembly
hack
#endif
A good example is in linux/drivers/sound/audio, except they chose
to use #ifdef NO_INLINE_ASM instead of #ifndef i386.
I would like to see the fast file name compares in the file system
directories pulled out into a construct like this, and since they
all do about the same thing, it can go into a common asm/ include.
> If you follow rules like this, then it makes porting of these new
> features to Linux on other architectures easier.
Personally, I don't have any grand hopes that "Linux" will become
a mainstream OS for anything other than x86 machines. OTOH, the
code base it has generated (and is continuing to generate) is real,
and will have a lasting effect on *nix for all machines.
> An example of the benefits of this is the fact that the "net/unix"
> Unix domain socket code ported over to Linux/68k with absolutely no
> changes required to the source. I was very happy when I was able to
> do this.
Yahoo! I am looking forward to a Linux-ish R4200 laptop.
- Larry Doolittle doolit...@cebaf.gov
Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!sol.ctr.columbia.edu!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Future development of Linux and affects on other architectures
Message-ID: <CMx6n3.2nu@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <2m58s2$86q@bmerha64.bnr.ca> <CMrHE1.FCH@murdoch.acc.Virginia.EDU>
Date: Sat, 19 Mar 1994 16:18:38 GMT
Lines: 30
In article <CMrHE1....@murdoch.acc.Virginia.EDU> dool...@cebaf4.cebaf.gov (Larry Doolittle) writes:
>> "inline function" or a preprocessor macro, and keep the definition of
>> the inline function or macro separate from the main functionality.
>
>... When you do, it should take the form:
>#ifndef i386
> simple {
> c;
> substitute();
> }
>#else
> high
> speed
> assembly
> hack
>#endif
If we get ports to multiple architectures, this type of coding could be
quite difficult to read. Instead I would suggest that the macros or inline
functions be stored in the header files in include/asm. Ultimately there will
need to be separate asm directories for i386 and other machines, so you would
merely set up a link to the right directory and you would get the right
functions. There could also be some kind of "generic" directory for the C
equivalents.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
Newsgroups: comp.os.linux.development
Path: gmd.de!Germany.EU.net!EU.net!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!uw-beaver!cornell!mdw
From: m...@cs.cornell.edu (Matt Welsh)
Subject: Re: Future development of Linux and affects on other architectures
Message-ID: <1994Mar20.183149.13645@cs.cornell.edu>
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
References: <2m58s2$86q@bmerha64.bnr.ca> <CMrHE1.FCH@murdoch.acc.Virginia.EDU> <CMx6n3.2nu@ra.nrl.navy.mil>
Date: Sun, 20 Mar 1994 18:31:49 GMT
Lines: 24
In article <CMx6n3....@ra.nrl.navy.mil> e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
> If we get ports to multiple architectures, this type of coding could be
>quite difficult to read. Instead I would suggest that the macros or inline
>functions be stored in the header files in include/asm.
I agree, something along these lines is a good way to go. I'd like to see
the Linux kernel abstracted somehwat for porting to other architectures;
at the very least, moving assembly code out of the source proper. (Although
there are many algorithmic things that are tuned to the x86). In theory,
then, to port the heart of the kernel to another architecture you would
only need to rewrite the `far back end' routines (task management, etc.)
for that architecture. Of course, there are many other problems associated
with that: For one thing, the core data structures would change across the
board (such as task_struct) and interrupt handling would be greatly different.
Then you're faced with the problem of porting device drivers to the new
hardware. This is not an easy task for ANY kernel; most popular commercial
UNIXes (SunOS, etc.) are tailored to a particular platform.
I don't want to see the Linux kernel be abstracted to the point where it's
no longer optimized for the x86. However, some of the code can be organized
to (attempt to) separate the machine dependencies from the abstract algorithms.
Unfortunately x86 assumptions run throughout the kernel, and abstracting those
any further would undoubtedly complicate things considerably.
|