From:     Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To:       Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date:     Tue, 13 Sep 94 07:13:09 EDT
Subject:  Linux-Development Digest #165

Linux-Development Digest #165, Volume #2         Tue, 13 Sep 94 07:13:09 EDT

Contents:
  Games Make the OS (was: Re: Can't Run Doom!!) (Pete Deuel)
  LOOPBACK not handling packet load. (Chip Edwards)
  Re: Future of linux -- the sequel (Shannon Hendrix)
  Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Mark Lord)
  Re: Multiprocessing Pentium Systems (Hugh Emberson)
  Re: 3c509 Problems (Alan Modra)
  Re: 3c509 Problems (Brian Kramer)
  Interested in EIDE driver ? (Petri T J Mattila)
  Compiler benchmarking. was Survey: who wants f77,cc,c++,hpf for linux? (Robert Lipe)
  Re: Alpha Linux (Maarten Boekhold (Who'd you expect??))
  Re: Alpha Linux (Maarten Boekhold (Who'd you expect??))
  Re: Acid (Joachim Schrod)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Alan Cox)

----------------------------------------------------------------------------

From: deuelpm@craft.camp.clarkson.edu (Pete Deuel)
Crossposted-To: comp.os.linux.misc
Subject: Games Make the OS (was: Re: Can't Run Doom!!)
Date: Tue, 13 Sep 1994 00:38:16 GMT

In article <351ms1$ccu@bruce.uncg.edu> root@tao.binary9.com (Nicholas J. Leon) writes:

>When I try to run Doom on my Linux box I get the following error
>after I choose which scenerio I want to play:
>U_GetNumForName: SSTMINUS not found
>and then proceeds to exit.
>Does anyone know what I can do about this?

You see!  If you really want a popular OS, you really have to have some good 
games.  Never have I seen so many learn so much about linux all at once!

How many times do you think I was asked "Whass, uhh, I-P-uh-X?" when Doom came 
out for DOS/net (was it IPX?  I can't recall--I may be blocking this!)


Now, just to make it worse:  Doom needs sound support...  Oh, I've heard the 
machine guns and music and explosions galore, but I mean VOICE!  That's right, 
when I'm wandering around the Doom-scape, I wanna have a Mic plugged in to my 
PAS or SB and be able to beg for my life, or try to form alliances, or the 
like...


Jus' somethin' to chew on...


Pete
===================================================
     "Actually, I'm a lab mouse on stilts..."

     E-mail:  deuelpm@craft.camp.clarkson.edu
===================================================

------------------------------

From: gt6444c@prism.gatech.edu (Chip Edwards)
Subject: LOOPBACK not handling packet load.
Date: 10 Sep 1994 01:15:10 -0400

I'm not sure who to send this to soo..
  Some have noticed the ping -f on the loopback device fails miserably.
I have noticed now that certain programs which use udp on the loopback port
have MAJOR packet loss. Can someone PLZ PLZ PLEEAZZ fix the driver.
Or send me a patch. I would most gratiously appreciate it.
Chip
gt6444c@prism.gatech.edu

-- 
Chip Edwards (gt6444c@prism.gatech.edu)
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt6444c
Internet: gt6444c@prism.gatech.edu

------------------------------

From: shendrix@escape.widomaker.com (Shannon Hendrix)
Subject: Re: Future of linux -- the sequel
Date: Sun, 11 Sep 1994 23:23:22 GMT

djohnson@seuss.ucsd.edu (Darin Johnson) writes:

>A Sun *2*?  The one they stopped supported in the mid-80's?
>It had a 68010 in it!  Maybe you mean a Sparcstation 2?

Oops...

>So then, compare the DMA speed of your ISA system to a Sparcstation
>(or even a lowly VME system like a Sun 3).  There's more to a
>computer's performance than cpu speed.

No kidding.  But I wasn't talking about overall performance either.

No doubt, DMA speed is better on *SOME* Sun's.  However, you'll note
that I said *INTEGER* performance, not DMA speed.

Also, I've benchmarked my simple IDE drive in common tasks and
throughput against the Sun's at work and I usually do better on my 486.
The IDE interface is not good for multiple drives but most of my
accesses come from one drive.  IDE is 16-bits, SCSI is 8 so unless you
have multple drives and put them under a severe load, the Sun's I use
are slightly slower (a lot slower in some cases).  Also, with VLB or PCI
you can get SCSI cards that will outrun most of the drives anyway.

Anyway, the day I can afford SCSI fast-wide I'll leave IDE behind.  But
for now IDE is my only choice and it's giving a lot of 8-bit SCSI 
systems a run for their money in the configuration I have.  When I
start making heavy use of the second drive IDE will be hurting me
but there are also IDE interfaces out there now that let both drives
talk at once just like SCSI.  I'm thinking of getting one because a
friend of mine got one and it improved multiple drive accesses quite
a bit.  No idea how though unless it just lies to the drives so they
don't know the other master/slave is doing I/O.  I remember that each
drive was placed on it's own cable.

>--
>Darin Johnson
>djohnson@ucsd.edu
>  - I'm not a well adjusted person, but I play one on the net.
-- 
csh
===========================================================================
shendrix@escape.widomaker.com      | Linux and BSD

------------------------------

From: mlord@bnr.ca (Mark Lord)
Subject: Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
Date: 12 Sep 1994 19:31:12 GMT

In article <CvyKCy.651@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>In <9409091592@fangorn> Michael Haardt <(michael)u31b3hs@pool.informatik.rwth-aachen.de> writes:
>
>>davism@latcs2.lat.oz.au (Mitch Davis) writes:
>
>>        if (stat & (BUSY_STAT|ERR_STAT))
>>!               printk ("hd%c: ST506 interface, %dMB, CHS=%d/%d/%d\n",
>>!                       dev+'a',hd_info[dev].cyl*hd_info[dev].head*hd_info[dev].sect/2048,hd_info[dev].cyl,hd_info[dev].head,hd_info[dev].sect);
>>        else {
...
>>Once I sent this to Linus, but no response...
>
>You wouldn't believe how much stir-up a small patch like this can sometimes
>cause.  I think Linus has become more careful before incorporating things
>like this....

Yeah.  The above patch would cause linux to "recognize" non-existant devices
that are entered in the BIOS tables but not physically present.
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

------------------------------

From: hugh@hugh.cosc.canterbury.ac.nz (Hugh Emberson)
Subject: Re: Multiprocessing Pentium Systems
Date: 13 Sep 1994 00:15:05 GMT

>>>>> "Scott" == Scott Lawrence Lynn <slynn@pyramid.com> writes:

Scott> In article <HUGH.94Sep11203646@hugh.cosc.canterbury.ac.nz>,
Scott> Hugh Emberson <hugh@hugh.cosc.canterbury.ac.nz> wrote:

Scott> I've never looked at the SunOS 4.x.x kernel, but I can't
Scott> imagine that it was done this way.  Spinlocks have timeouts on
Scott> them, and you could easily have a CPU wait for much too long
Scott> due to the inherent possibility of starvation that comes with a
Scott> spinlock.

I hesitate to disagree with someone from Pyramid on something like
this ... but I just spoke with our local SunOS expert and he says that
there is a single mutex around the entire kernel in 4.1.3. 

You do get some serious resource contention problems.  If you run top
on a multiprocessor Sun running 4.1.3 you get something like this:

Cpu states:  7.3% user,  0.0% nice,  7.4% system, 84.5% idle,  0.8% spin

Right now, there isn't much happening, but when you get several
processes which want to use lots of kernel time then the spin field
gets upto 15% or higher.  The spin field seems to measure the total
time spent waiting to get into the kernel.

Scott> One way to handle SMP simply is to put spinlocks around all the
Scott> kernel data structures, or major subsystems.  This will still
Scott> probably take a great deal of work to get it right, and it'll
Scott> have problems.  It's a good start though.

This is effectively what they have done.  They consider the kernel to
be one big data structure or subsystem :-)

Of course the big problem with this is what to do with interrupts and
I guess this will depend on the architecture.  Which processor gets
the interrupts?  Can you designate which processor gets them, or do
they only go to processor 0?  If they only go to processor 0 then only
processor 0 should be allowed to enter the kernel, cause we don't want
to have a processor waiting to get into the kernel to handle an
interrupt.  And there are nasty coherence problems with the cache and
tlb, but hopefully the hardware will handle some/most of these.

I'm not suggesting this as a long term, elegant solution, but as a
(hopefully) quick and dirty hack to get Linux running on these
multiprocessor machines.

Cheers,
        Hugh
-- 
Hugh Emberson              | ... from the end of the Information 
hugh@cosc.canterbury.ac.nz | Super-four-wheel-drive-track.

------------------------------

From: alan@spri.levels.unisa.edu.au (Alan Modra)
Subject: Re: 3c509 Problems
Date: 12 Sep 1994 07:41:10 GMT

Danek Duvall (duvall@sage.wlu.edu) wrote:

: I recently set up my 3Com Etherlink III Combo on my linux machine.
: The first boot after the network stuff was configured, it worked fine.
: In fact, it worked fine continuously for over a day.  Then, today, I
: was having some problems compiling and installing sendmail, I rebooted
: my machine.  At that point, I couldn't find anything on the network.
: I hadn't changed any relevant pieces of the network config files, so
: it couldn't have been that.  Then I checked /var/adm/messages, which
: had the line:

:   eth0: Missed interrupt, status then 2011 now 2011 Tx 00 Rx 383c

: The same line appeared every time I booted, exced that the last number
: would change.  I found the spot where this gets printk'ed, but I know
: nothing more than that.

: Please!  If there's anything anyone can do to help, I would really
: appreciate it, since I have almost no clue about the networking code
: (except what I've read in the NAG and the NET-2-HOWTO).  If there's
: any further information you need to figure out what's going on, please
: get in touch.  (My kernel version, by the way, is 1.1.49.)

This one seems to be a 3c509 driver bug.  I mailed Donald Becker a
report way back in Dec about it, but it still isn't fixed (can't
complain, I didn't fix it either :-) ).  The most annoying result of
the bug, for me, is that crond doesn't get uid's via NIS reliably, and
sometimes your first login fails.

My work-around is to put the following in rc.inet2 after ypbind is
run.

while ! /usr/bin/ypcat passwd >/dev/null; do /usr/bin/sleep 1; done


------------------------------

From: bjkramer@pluto.njcc.com (Brian Kramer)
Crossposted-To: comp.os.linux.help
Subject: Re: 3c509 Problems
Date: 12 Sep 1994 19:17:34 -0400


:   eth0: Missed interrupt, status then 2011 now 2011 Tx 00 Rx 383c

Instead of rebooting turn off the machine (with shutdown of course)
and leave it off for about a minute.  I have the same card and if
I do not do that you can't use the ethernet at all.  I guess the
card needs to reset.

-- 
Brian Kramer - Owner/Systems Administrator - bjkramer@pluto.njcc.com
New Jersey Computer Connection - Public Access Unix Site - pluto.njcc.com
Voice: 609-896-2799 - Fax: 609-896-2994 - Dialups: 609-896-3191
Dialup or Telnet to pluto.njcc.com and log in as guest for more information.

------------------------------

From: ptjmatti@cc.Helsinki.FI (Petri T J Mattila)
Subject: Interested in EIDE driver ?
Date: 13 Sep 1994 08:52:02 GMT

Hello world,

I am working on eide driver for linux,
and have the skeleton up and running.

BUT, I don't have any information about eide controllers,
(programming, technical, etc.)

So, YOU could help me by mailing me info about
- some site to ftp
- some notes
- anything concerning eide controllers

I am also interested in what controllers are there, in general ??


SOME INFO ABOUT THE SKELETON DRIVER:
- currently running on normal AT -bus (8 MHz) controller
- speedup 10-15% compared to the previous code (hd.c with multimode)
- two controller supported by default
- drives them simultaneously
- have lba addressing mode, autodetection, multimode, new pio modes,
  smart error recovery and many more
- a test: 1.8 Mb/sec read, 1.7 Mb/sec write with Seagate decathlon
  in AT -bus (8MHz)

So, If you have any information of controllers, feel free to mail it
to me, I would appreciate it.

I will release the code as soon as I get some timing bugs fixed.
So, stay on line.

Petri.

--

=============================================================================
*  Petri Mattila  *  ptjmatti@kruuna.helsinki.fi  * University of Helsinki  *
=============================================================================  
                                        

------------------------------

Crossposted-To: comp.lang.fortran
From: robertl@arnet.com (Robert Lipe)
Subject: Compiler benchmarking. was Survey: who wants f77,cc,c++,hpf for linux?
Date: Mon, 12 Sep 1994 18:11:12 GMT

rsanders@mindspring.com (Robert Sanders) writes:

>On Sun, 11 Sep 1994 17:31:04 GMT, mcastle@umr.edu (Mike Castle) said:

>> In article <CvyynF.Lxp@news.cern.ch>, Dan Pop <danpop@cernapo.cern.ch> wrote:
>>> Could you post some examples where a commercial native compiler for x86
>>> produces _significantly_ faster codes than the free gcc?

>> IBM's C compilers under OS/2.
>> Watcom compilers under OS/2 and DOS (do they have unix versions?)
>> Zortech C compiler (I presume under OS/2 and DOS as well).
>> Most likely the Mark Williams C compiler (they produce better
>>   compilers than operating systems (coherent)).

>I think Dan meant he wanted to see the C source, timings, and the
>assembly produced by each, as well as other relevant benchmark
>information (input data, RSS, host machine, etc.).

I'm certainly not trying to slam GCC - there's certainly a 
permanent place for it in my toolbox, but here is an excerpt
from some internal tests I ran with identical dhrystone tests
this spring.......


All systems running SCO 3.2v4.2 or ODT 3.0. (Eliminating the OS 
vs. Executable part of the debate...)

Amsg    25Mhz 486.  One of the original Intel motherboards.
Bytebox 486DX2/66.  Generic Clone.
Pooter  60Mhz Pentium Dell

Notes:

GCC is compiled with 486, so -m486 makes no diff.
ICC is the Intel compiler (a.k.a. the "SCO Optimizing C Compiler") 1.3.11
RCC and CC are straight of the ODT 3.0 DS.
Register was set in all cases.  (Even though I believe the
        compiler should figure this stuff out, not me...)
Set ts to 8 to read this.


The same array of binaries were run on all three machines.  While
I'd like to convince you that I'd automated the hell out of this,
I didnt - a lot of this is massaged by hand.  I was just trying
to decide if the compiler really makes any difference...I didn't
want to make a career of it.

First, the tallies by machine:

14039   amsg            cc      SCO ODT 3.0 compiler (ms 6.0 derived)
15639   amsg            rcc -O  The restricted c compiler (think it's pcc in
16056   amsg            cc -O
22411   amsg            gcc -O2 -funroll-loop      2.5.6 i486-unknown-sco3.2v4.2
22416   amsg            gcc -O2 -m486 -funroll-loop
22983   amsg            cc -Ox
31113   amsg            icc -O
31142   amsg            icc  Intel compiler.
41858   amsg            icc -O -mem -ip
41893   amsg            icc -O -mem -ip -p4
41963   amsg            icc -O -mem -ip -p5

34211   bytebox         cc      SCO ODT 3.0 compiler (ms 6.0 derived)
39339   bytebox         rcc -O  The restricted c compiler (think it's pcc in
42408   bytebox         cc -O
54525   bytebox         gcc -O2 -funroll-loop      2.5.6 i486-unknown-sco3.2v4.2
54525   bytebox         gcc -O2 -m486 -funroll-loop
56274   bytebox         cc -Ox
70372   bytebox         icc -O
71581   bytebox         icc  Intel compiler.
95147   bytebox         icc -O -mem -ip -p4
95877   bytebox         icc -O -mem -ip
97560   bytebox         icc -O -mem -ip -p5


50505   pooter          cc      SCO ODT 3.0 compiler (ms 6.0 derived)
56882   pooter          cc -O
58445   pooter          rcc -O  The restricted c compiler (think it's pcc in
76887   pooter          cc -Ox
86655   pooter          gcc -O2 -funroll-loop      2.5.6 i486-unknown-sco3.2v4.2
86730   pooter          gcc -O2 -m486 -funroll-loop
139860  pooter          icc -O
140252  pooter          icc  Intel compiler.
207039  pooter          icc -O -mem -ip -p5
208333  pooter          icc -O -mem -ip
208333  pooter          icc -O -mem -ip -p4

Here's the same table, pumpted through reverse numeric sort.

208333  pooter          icc -O -mem -ip -p4
208333  pooter          icc -O -mem -ip
207039  pooter          icc -O -mem -ip -p5
140252  pooter          icc  Intel compiler.
139860  pooter          icc -O
97560   bytebox         icc -O -mem -ip -p5
95877   bytebox         icc -O -mem -ip
95147   bytebox         icc -O -mem -ip -p4
86730   pooter          gcc -O2 -m486 -funroll-loop
86655   pooter          gcc -O2 -funroll-loop      2.5.6 i486-unknown-sco3.2v4.2
76887   pooter          cc -Ox
71581   bytebox         icc  Intel compiler.
70372   bytebox         icc -O
58445   pooter          rcc -O  The restricted c compiler (think it's pcc in
56882   pooter          cc -O
56274   bytebox         cc -Ox
54525   bytebox         gcc -O2 -m486 -funroll-loop
54525   bytebox         gcc -O2 -funroll-loop      2.5.6 i486-unknown-sco3.2v4.2
50505   pooter          cc      SCO ODT 3.0 compiler (ms 6.0 derived)
42408   bytebox         cc -O
41963   amsg            icc -O -mem -ip -p5
41893   amsg            icc -O -mem -ip -p4
41858   amsg            icc -O -mem -ip
39339   bytebox         rcc -O  The restricted c compiler (think it's pcc in
34211   bytebox         cc      SCO ODT 3.0 compiler (ms 6.0 derived)
31142   amsg            icc          Intel compiler.
31113   amsg            icc -O
22983   amsg            cc -Ox
22416   amsg            gcc -O2 -m486 -funroll-loop
22411   amsg            gcc -O2 -funroll-loop      2.5.6 i486-unknown-sco3.2v4.2
16056   amsg            cc -O
15639   amsg            rcc -O  The restricted c compiler (think it's pcc in
14039   amsg            cc      SCO ODT 3.0 compiler (ms 6.0 derived)

While I doubt this reflects anything like "real world" cases, one
thing is evident:  This Intel C compiler makes *HOT* code.

Please, no flamage about how bogus the tests are, etc.  I think
my conclusion is correct - icc smokes gcc.  I've stared out the 
assembly output of this beasty and it's incredible. 

Lessee, if ibcs is running correctly, an industrious linuxer could
probably generate a version of gas that would read icc's output.
This compiler is avilable from SCO and a few other vendors.

----
Robert Lipe     Sr. Software Engr.     Arnet Corp.    robertl@arnet.com

------------------------------

Subject: Re: Alpha Linux
From: boekhold@morra.et.tudelft.nl (Maarten Boekhold (Who'd you expect??))
Date: 13 Sep 94 11:25:46 +0200

N J Plant (nick@lepton.demon.co.uk) wrote:
> In article <im14u2c.779230562@cegt201>
>            im14u2c@cegt201.bradley.edu "Joe Zbiciak" writes:
> >
> >In <JEM.94Sep10192807@delta.hut.fi> jem@snakemail.hut.fi (Johan Myreen)
> >writes:
> > 
> >>What is the natural word size of the 68000?  Or the 8088?  Or a
> > 
> >Even better:  The 68008...  8 bit data path, 16 bit registers, 32 bit ALU.
> >By 32 bit ALU, I mean two registers would combine together and make a 32 bit
> >register for ADD & SUB and MUL & DIV (I think.) 
> > 

> On the 68000 the external address bus is 20 bits and the external data bus
> is 8. Internally, the registers, buses and ALU are all 32 bit. It can ADD
> and SUBtract 32 bit numbers or MULtiply 2 16 bit numbers to give a 32 bit
> result. It has fewer pins than a 68040, but its still a 32 bit chip. The
> sizeof the integral types should be the same as any other 68K chip.

Ho, hold it right there...... The 68000 has a 16 bit external databus. 
You're right about the other things though... :-)

Maarten
boekhold@morra.et.tudelft.nl

------------------------------

Subject: Re: Alpha Linux
From: boekhold@morra.et.tudelft.nl (Maarten Boekhold (Who'd you expect??))
Date: 13 Sep 94 11:32:07 +0200

Chris Bitmead (chrisb@wombat.cssc-syd.tansu.com.au) wrote:
> In article <DHOLLAND.94Sep8170917@husc7.harvard.edu> dholland@husc7.harvard.edu (David Holland) writes:

> >adc@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
> >
> > > Why drop one? 
> > > 16 bits = short int
> > > 32 bits = int
> > > 64 bits = long
> >
> >Over in the next thread people were talking about Unicode; why not
> >
> >16 bits = char
> >32 bits = short
> >64 bits = int, long

> None of these is the best solution. The best solution is to say exactly
> what you mean. E.g. If you want to store numbers between -500 and +1000
> you should declare this and let the compiler work out how many bits to
> use. e.g. int{-500,1000} foo; int{0,65535} bar;
> Naturally you could use typedef's for common ranges. This has the added
> benefit of not assuming that the computer is binary, assuming one day
> someone invents a non-binary computer.
> In any case stating what you *really* want to do and letting the compiler
> decide on the optimum number of bits has to be the best.

I really like this solution. It might take some time to get used to, but I 
like the idea.

Maarten
boekhold@morra.et.tudeft.nl

------------------------------

From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Acid
Date: 13 Sep 1994 10:43:29 GMT

In article <Cw07vG.Dso@shako.sk.tsukuba.ac.jp>, turnbull@turnbull.sk.tsukuba.ac.jp (Stephen J. Turnbull) writes:
> 
> >    Actually, TeX/LaTeX would come closest...and its available for several 
> >languages.
> 
> Including Chinese and Japanese.  But I don't know if Don Knuth thought
> about multidirectional languages.

There is support for typesetting approximately 50 languages, including
such beasts as Khmer. Multi-directional, of course. There exists also
a Unicode-TeX.

Don't expect the stuff to be easy to install, though. It still have
its rought edges, in particular on the font side. But I did see it
work... :-)

        Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod                  Email: schrod@iti.informatik.th-darmstadt.de
TeX Users Group
Technical Working Group on Multilingual Coordination, member

------------------------------

Crossposted-To: comp.lang.fortran
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Tue, 13 Sep 1994 09:53:00 GMT

In article <1994Sep11.173104.10758@umr.edu> mcastle@umr.edu (Mike Castle) writes:
>In article <CvyynF.Lxp@news.cern.ch>, Dan Pop <danpop@cernapo.cern.ch> wrote:
>>Could you post some examples where a commercial native compiler for x86
>>produces _significantly_ faster codes than the free gcc?
>Watcom compilers under OS/2 and DOS (do they have unix versions?)

I've benchmarked the Watcom compiler (pre-pentium one which they claim is
much quicker) and gcc beat it fairly soundly.
>Zortech C compiler (I presume under OS/2 and DOS as well).

You must be kidding.

>Most likely the Mark Williams C compiler (they produce better
>  compilers than operating systems (coherent)).

It produces code about as fast or fractionally slower but much much smaller,
and although its not a proper ANSI compiler so speed comparisons are not
totally fair it compiles much quicker than gcc.

>GCC is designed to be PORTABLE first, optimal last.  In almost
>all cases, a DECENT architecture specific compiler will be as
>good as or beat GCC.  

Very few compilers do beat it - Sun's sparc compiler does. The DOS compilers
I would like to have a good benchmark for but they are 16bit currently. Some
figures for 32 bit Borland code would be interesting because the 16bit code
it writes is very very good.

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  iialan@www.linux.org.uk   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
