633 lines
24 KiB
Plaintext
633 lines
24 KiB
Plaintext
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
|
|
******************************
|