HDTenEightyP/NetNews huggingface dataset:
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Mon, 31 Aug 1992 16:26:30 GMT

In article <1992Aug28.222616.2251@merlin.dev.cdx.mot.com> lezz@merlin.dev.cdx.mot.com (Lezz Giles) writes:
>
>Once again, I don't want to say that assembler is a Bad Thing.  Also
>notice that I'm not saying anything about ease of programming, speed,
>or anything else.  I'm just saying that if you program in assembler for
>an 80386 then your program will run well on an 80386, sub-optimally on
>an 80486 and not at all on an 80286 (and forget about a 68030).  If you

This is patently wrong.  I write for the 8086/8088 model as do most people.
It runs on 8088, 8086, 80186, 80188, 80286, 80386SX, 80386DX, 80486SX,
80486DX, 80486DX2, and about 20 non-Intel clones from AMD, NEC, ULSI, TI,
and a few other cpu clone maker's cpu's.  I can choose to exclude the 8088
and 8086 with a simple assembler directive, which merely enables extensions
available in the '286 and up, or I can us the larger models and write for
protect-mode on either 286 and up or 386 and up as I choose.  There is
hardly any difference between 386 and 486 save speed and a few instructions
(very few) that were added to the '486.  There is virtually no software
significence to the 486 over the 386, and for all indications, as posted on
this newsgroup, the '586 won't change this either.

A very popular and recent piece of software is DR-DOS Version 6, which 
is written in mostly assembler and runs on all of these, picking up options
along the way in a seamless manner where applicable.

Any architecture worth investing effort in generally stays around for awhile;
I think a consensus was reached for a number around 15 years.  This tends to
squelch the arguments about "porting" difficulties in assembler.  Moreover,
there are insidious differences in C implementations that are *almost* the
same, which causes true havoc to a maintainer of programs across multiple
and thoroughly incompatible systems where the only measure of compatibility
is the *hope* of C compatibility which may not quite measure up.

Within the world of Kermit, we have frustrating cases of even small programs
that need worlds of conditionals to satisfy the bizarre variations floating
around the industry.  Compounding the problems are systems that "bend over
backwards" in that they attempt to conform to each other's quirks, often
not quite successfully  (such as Microsoft C compatibility switch in Borland
C, etc.).

Sometimes it's easier to totally rewrite the code for the new environment,
since you know afresh all of the new situation's requirements :-).

cjl

Newsgroups: alt.folklore.computers
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: Itty Bitty Machines (was: Better dead than IBM)
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Tue, 1 Sep 1992 23:52:16 GMT

jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
>The first personal computer store in Evanston was the Itty Bitty Machine
>Company, named, clearly, after that other, somewhat larger company with
>the same initials.  Does anyone know what became of it?  It got into

You mean besides having their asses sued off?

I think these guys had to change their name when IBM send along more lawyers
than they had employees.  (Or am I thinking of "Big Blue Computers"?)

-- 
Paul Tomblin, pt@geovision.gvc.com
(This is not an official opinion/statement of GeoVision Systems Inc.)
"Ok dear, want me to call the bike shop and see if they'll sponsor your
mid-life crisis?" "Yeah.  Ask them if they'll upgrade my shifters, too"
Newsgroups: alt.folklore.computers
From: fstuart@eng.auburn.edu (Frank Stuart)
Subject: Better dead than IBM
Organization: Alphabetical
Date: Thu, 27 Aug 1992 16:23:30 GMT

What does IBM *really* stand for?  Let me know if you know the answer and
I'll post a summary in a week or two.

To get the ball rolling, here are some suggestions from the Jargon File:

   Inferior But Marketable
   It's Better Manually
   Insidious Black Magic
   It's Been Malfunctioning
   Incontinent Bowel Movement
   International Business Machines

I also like "Incredibly Boring Machines".

Frank Stuart           |   Slower traffic keep right.  |  Don't Panic
fstuart@eng.auburn.edu |   MMMMMmmmmm lutefisk.        |  Never moon a werewolf
Newsgroups: alt.folklore.computers
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: You know you've been using X too long...
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Sun, 30 Aug 1992 13:20:18 GMT

aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:

>taste in colors anymore!", and prompty decided to make the rivers a deep red,
>and the skies shades of grey, by thinking "*River*background: #FF0000" and
>"*Sky*background: #808080".
Not much of an improvement, if you ask me.

>I think I've been hacking X too long...

I think you've found what I've always found: I'm unable to come up with a
better colour selection than the developer's defaults.  For instance, when I
had a DecStation on my desk, I used the Mwm file that came with it, with
only minor tweaking.  When I tried to get radical in changing the colours, I
ended up with something that I hated even more than the defaults.  Now I've
got a SPARC, I'm not even going to _try_ and change the open-windows
defaults.

-- 
Paul Tomblin, pt@geovision.gvc.com or {uunet,revcan}!geovision!pt
(This is not an official opinion of GeoVision Systems Inc.)
"Usenet is like Tetris for people who still remember how to read"
 -- Joshua Heller (heller2@husc.harvard.edu) on rec.humor.funny
Newsgroups: alt.folklore.computers
From: sverkerw@Minsk.docs.uu.se (Sverker Wiberg)
Subject: Re: ISO date format
Organization: UDAC, Uppsala, Sweden
Date: Tue, 25 Aug 1992 21:58:04 GMT

kjell@elixir.e.kth.se (Kjell Rilbe) writes:
>Hey, I didn't know this date format was used anywhere outside Sweden! 

Neither did I! As far as I knew, this was an international standard
used only in Sweden. Which is the reason why I always (nearly) use
the old Swedish date format (DD/MM-YY alt. DD/MM YYYY). That, and
messing with the 'droids. ;-)



--
#include<stddisclaim.h>	         Every interesting data structure is recursive.
sverkerw@mizar.docs.uu.se (Sverker Wiberg)		                  /Cons
     This mission is too important for me to allow you to jeopardize it. -- HAL
     We're on a mission from God.                             -- Blues Brothers
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 26 Aug 92 11:47:10 GMT
 om> <5242@unixhub.SLAC.Stanford.EDU><jimf.714688451@centerline.com>
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: jimf@centerline.com's message of Mon, 24 Aug 1992 20:34:11 GMT

>>>>> On Mon, 24 Aug 1992 20:34:11 GMT, jimf@centerline.com (Jim Frost) said:

> ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:
>>Nonsense. There are many (efficient!) things you can do in assembler
>>but not in C. And I'm sure even the best optimizing compilers don't
>>know all the tricks you can pull in assembler.
>>- If I call any subroutine or function in C, a large set of registers
>>  will be saved in some fashion, often unneccesarily.

> False.  A good C compiler will never save a register it doesn't use.
> Further, it will omit frame generation if a frame is unnecessary or do
> any number of other function-calling optimizations.

However, a human can also not save a register which _is_ used if he knows
the function being called won't touch it. Whether this is worth the
maintenence problems caused is another question...
The few functions where it might be should probably be in the same compilation
unit, in which case an optimiser could spot it.

> I agree that C, or any other HLL language, isn't the right thing for
> all tasks.  Sometimes there just isn't any other way than assembler
> (you can't write C's setjmp/longjmp in C, for instance).  For nearly
> all common tasks an HLL is a better and more efficient tool -- in the
> long run -- than an assembler.  This is particularly true the first
> time you need to move your application to a different hardware base.

This is the other thing assembler is really needed for - defining the 
output of your cross-compiler.

[Actually I don't understand why those really wanting to use assembler for
everything settle for that compromise - why not do what Linn did with the
Rekursiv and design the chip to run the microcode you really want :-)]
--
Alan Braggins, Shape Data (A Division of EDS Ltd), Cambridge, UK +44-223-316673
   "Any technology distinguishable from magic is insufficiently advanced."
 "My employer does not necessarily share my views - but I'm working on it."
Newsgroups: alt.folklore.computers,comp.unix.misc
From: thomas@bitrot.in-berlin.de (Thomas Driemeyer)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Thomas Driemeyer, Berlin
Date: Fri, 28 Aug 1992 15:35:09 GMT

Humans are better writing assembly code than compilers, if the piece of
code in question is small enough. It is hard to justify though.

I once wrote a routine for a windowing system that sends redraw events to
window owners by finding visible subrectangles of all partially obscured
windows. It took only 24 68020 instructions, and I was very proud of it.
It does evil things like recursively descending into the middle of itself,
returning booleans in carry flags, entering and exiting loops in strange
points and so on. No optimizer I know would do all that.

Why? Well, I was having fun, of course, and I didn't have a C compiler
for that (homegrown) box. It is one of my very few nifty hacks that
survived for many years. Isn't it sad that the best hacks never make it
into the final version? They are almost never general, maintainable, and
extendable enough. And, if a program requires more than a few lines
of assembly programming, I usually take that as a hint that something is
wrong with the spec or the overall design. Things are different now than
10 years ago; I haven't written assembly code in at least a year.

If you don't believe me, I'll post the code after introducing a subtle
bug. :-) You'll spend more time debugging than the code will ever save.

Thomas
-- 

--
Thomas Driemeyer        thomas@bitrot.in-berlin.de        voice: +49 30 8924936
               1.-20. Oktober: trane!thomas@pacbell.com
From: exuhag@exu.ericsson.se (James Hague)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favori
Date: 2 Sep 92 15:27:16 GMT
Reply-To: exuhag@exu.ericsson.se
Organization: Ericsson Network Systems, Richardson, TX

Ah, so this silly argument has entered the MS-DOS arena.  Now it
all makes sense.

The MS-DOS world is far from perfect (understatement of the year :-)
Yes, the 486 is one fast chip and I would not even consider writing
*any* sort of assembly code for it, save interrupt routines.  But
thousands and thousands of 386sx-16 and 385sx-20 computers are being
sold daily.  And there are millions of them already being used, not to 
mention the millions of 286's still kicking.  If there was a program
which could be made usable on less than a 386-33 by rewriting portions
in assembly, then that may be a smart decision.

I think this mostly affects operating systems and games.  I could easily
get by with a 286-10 if it weren't for things like Windows and various
animated games.  If a compiler takes ten seconds longer to compile my
program then so what?  But if it takes 0.25 seconds longer for something
to get highlighted when I click on it or a game looks very choppy, then it
makes all the difference in the world.

And MS-DOS compilers, even the very best of them, are still really awful
in comparison with those for most RISC machines.  (For most applications
though, it doesn't matter.  I would rather have a well-designed,
understandable, and predictable language/compiler than something which
sacrifices everything for an insignificant bit of extra speed.
Unfortunately, most MS-DOS compilers give you neither.)

BTW, there are two fairly complex MS-DOS games being released shortly
which were written *entirely* in assembly language in order to get the
necessary performance (and I'm sure size was also an issue):  Disney's
Stunt Island and a helicopter simulator (something with "overdrive" in
the title?).  I have a feeling that the design of something as intricate
as a real-time flight simulator is a _lot_ more difficult than its
implementation in any language.  The difference between writing it in C 
and writing it in assembly language probably probably pales in comparison.
Programming is programming.

--
James Hague   
exuhag@exu.ericsson.se
Newsgroups: alt.folklore.computers
From: smith@sctc.com (Rick Smith)
Subject: Re: Nonfiction Computer History Book List Wanted
Organization: SCTC
Date: Wed, 26 Aug 1992 14:26:18 GMT

Digital Press did a series of computer history books about ten years
ago. I think they're all out of print now. I don't have the full
references, but there was Nancy Stern's book "From ENIAC to Univac,"
and a book on Whirlwind by Redmond and Smith. MIT Press' latest
book sale flyer had several computer history books in it.

If you have a long term interest, subscribe to the "Annals of the History
of Computing," now published by the IEEE Computer Society Press.

Rick.
smith@sctc.com         arden hills, minnesota
From: smith@sctc.com (Rick Smith)
Newsgroups: alt.folklore.computers
Subject: Re: SAGE
Date: 2 Sep 92 15:14:28 GMT
Organization: SCTC


 .The last SAGE was retired and declassified in 1983(!), and large chunks of
 .it are on display at the Computer Museum in Boston.  Well worth a visit.

I once read that SAGE is essentially a production version of the MIT
Whirlwind, their pioneer vacuum tube computer. The late Saul Rosen
claimed that the Whirlwind influenced numerous early computing
projects because they printed up a detailed set of block diagrams that
illustrated its internal construction.

The block diagrams were classified at least until 1961, presumably
because of their relationship to SAGE. Rosen implied that this
restricted their circulation somewhat, but not their influence.

The Whirlwind's central bus architecture is clearly evident in several
other computers (the IBM 701/4/9 series, the early Sylvania work,
DEC's early computers) but I haven't seen anyone except Rosen
explicitly cite the block diagrams as a source of inspiration.

Is anyone else familiar with them?

Rick.
smith@sctc.com         arden hills, minnesota
Newsgroups: alt.folklore.computers
From: millernw@craft.camp.clarkson.edu (Neal Miller)
Subject: Re: "GOTO-less" BASIC
Organization: Clarkson University
Date: Thu, 3 Sep 1992 20:06:22 GMT

dpbsmith@world.std.com (Daniel P. B. Smith) writes:

>I should have saved it. Nobody will believe me. But it's true, and the
>article didn't appear in an April issue.  I think it was in Softalk,
>or maybe one of the Commodore hobbyist publications.  IT WAS SERIOUS.

>The author had discovered that most versions of BASIC allow two forms of 
>the IF...THEN statement:

>    IF <condition> THEN <general BASIC statement>
>    IF <condition> THEN <linenumber>

>He was deprecating the use of statements like

>    IF <condition> THEN GOTO 210

>and recommending their replacement by statements like

>    IF <condition> THEN 210

>HE WAS NOT TALKING ABOUT EXECUTION EFFICIENCY OR SAVING TOKENS OR 
>ANYTHING LIKE THAT.  His point was that by using the second form,
>you were ELIMINATING THE USE OF GOTO.

>Yes! I swear it!  HE MEANT IT!  It was a great way of avoiding GOTO's!
> 

	Back in my high school years, I took a class in BASIC, working
on some ancient IBM-XTs.  Our teacher held fast to the "rule" that we should
under no circumstances have any "bare GOTOs" in our program.  All this
meant is that all GOTOs in our program had to be conditional, and not
"stand-alone", so I couldn't use:

140 GOTO 270

But I *could* use:

140 IF (X/2) = Y THEN GOTO 270   (or just THEN 270)

I just used the line near the beginning:

5 LET Q = 5

And wherever I needed it, I'd use:

150 IF Q = 5 THEN GOTO 350

.... She never caught on. ;-)


--
-----------------------------------------------------------------------------
 Neal Miller         | "Why not go mad?"  | millernw@craft.camp.clarkson.edu
 Clarkson University |     - Ford Prefect |     dark@craft.camp.clarkson.edu
-----------------------------------------------------------------------------
Newsgroups: alt.folklore.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: CyC project
Organization: CenterLine Software, Inc.
Date: Wed, 26 Aug 1992 20:49:15 GMT

berry@athos.pei.com (Berry Kercheval) writes:
>This of course, leads to the question:  "If CyC is intelligent, is
>turning it off murder?" (much beloved of SF writers...)

>Is it still murder if you turn it back on?  If you restore from a
>backup?  Does it have rights?  Can it make contracts?  Own property?
>Vote?

...and if it owns property, then forks, which is the owner?

jim frost
jimf@centerline.com
From: ddb@tdkt.kksys.com (David Dyer-Bennet)
Sender: FredGate@tdkt.kksys.com
Newsgroups: alt.folklore.computers
Subject: Deutsches Museum (was: Zuse Computers
Date: Sun, 23 Aug 1992 13:30:01 -0600

 >|> >> It was kind of funny seeing people try to take flash pictures of the
 >|> >> planetarium screen...
 >|> >Will those tourists _EVER_ learn?
 >|>
 >|> I once visited the Peter's Church in Rome, the biggest church in
 >|> Christianity. You can see the tourists standing there, trying to
 >|> lighten the really huge dome with the flash of their pocket cameras.

 DS> Aw, come on. I can beat that easily. I've seen people take flash pictures
 DS> of the sunset.

Or in movies.  Really, I've seen it.  


 * Origin: Taste happens (1:282/341.0)
From: mcovingt@athena.cs.uga.edu (Michael A. Covington)
Newsgroups: alt.folklore.computers
Subject: Re: Norman/Turn signals (was: flash pix of sunset)
Date: 27 Aug 92 04:33:23 GMT
Organization: University of Georgia, Athens

In article <BtKIK2.M8p@world.std.com> dpbsmith@world.std.com (Daniel P. B. Smith) writes:
>In "Turn Signals are the Facial Expressions of Automobiles," (Addison-Wesley,
>ISBN 0-201-58124-8), Donald A. Norman has a very interesting essay on
>flash pictures of sunsets, recording events rather than experiencing them,

My wife recently watched someone take a horse-drawn-cart tour of Old Quebec
viewing it _entirely_ through the eyepiece of a camcorder.

And no, this person did not look like any kind of serious filmmaker.
Just a tourist.


-- 
+ Michael Covington - Artificial Intelligence Programs - U of Georgia - USA 
+ Unless otherwise noted, these are private opinions, not official statements.
+ VOTE NO GEORGIA LOTTERY - don't tie education to an unpredictable income.
Newsgroups: alt.folklore.computers,alt.religion.computers,rec.humor
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Assembly joke (offensive)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Thu, 27 Aug 1992 07:18:06 GMT

In article <17fpotINNjlm@early-bird.think.com> sandee@Think.COM (Daan Sandee) writes:

>Actually, I prefer a more obvious interpretation : an Assembly of God
>is a place where they managed to make sense of the manual that came 
>with the kit, and created a working model.

But were the batteries included?

cjl
Newsgroups: alt.folklore.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: CenterLine Software, Inc.
Date: Wed, 26 Aug 1992 14:24:44 GMT

alanb@sdl.mdcbbs.com (Alan Braggins) writes:
> On Mon, 24 Aug 1992 20:34:11 GMT, jimf@centerline.com (Jim Frost) said:
>> ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:
>>>Nonsense. There are many (efficient!) things you can do in assembler
>>>but not in C. And I'm sure even the best optimizing compilers don't
>>>know all the tricks you can pull in assembler.
>>>- If I call any subroutine or function in C, a large set of registers
>>>  will be saved in some fashion, often unneccesarily.

>> False.  A good C compiler will never save a register it doesn't use.
>> Further, it will omit frame generation if a frame is unnecessary or do
>> any number of other function-calling optimizations.

>However, a human can also not save a register which _is_ used if he knows
>the function being called won't touch it. Whether this is worth the
>maintenence problems caused is another question...

Oh, you're thinking of caller-saved calling conventions.  Most new
compilers (read: RISC compilers) have the callee save the registers
since the callee knows whether or not it's going to use them.  This is
much more efficient (as you might imagine).

I haven't used a compiler that had caller-saved calling conventions in
several years; I'd forgotten that most CISC compilers did it that way.

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
From: kris@tpki.toppoint.de (Kristian Koehntopp)
Subject: Re: Flash illiteracy; was: Re: Deutsches Museum (was: Zuse Computers
X-Copyright: (C) Copyright 1992 Kristian Koehntopp -- All rights reserved.
		 Reproduktion, auch auszugsweise, ausserhalb elektronischer,
		 nichtkommerzieller Datennetze nur mit ausdruecklichem,
		 schriftlichem Einverstaendnis des Autors.
Organization: Toppoint Mailbox e.V.
Date: Thu, 03 Sep 1992 19:58:49 GMT
X-Excuse: X-Copyright wegen Emma, Suedwestpresse und /C'T/DISKUSSIONEN.

In <1SEP199208373024@rover.uchicago.edu> frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger) writes:
>	Even more difficult. If you want to get the stars in the picture,
>	you must also fire up your flash from 8 years to ??? years before
>	for each star you wish to include.

Actually, this has been done. You can still get some of the
photons of this flash at 3 Kelvin.

Kristian
-- 
Kristian Koehntopp, Harmsstrasse 98, FRG W-2300 Kiel, +49 431 676689
			The cult of Koehntopp (tm)
Newsgroups: alt.folklore.computers
From: claird@NeoSoft.com (Cameron Laird)
Subject: Crashing in hacker haven (was: You know when you're hacking too long when...)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Wed, 26 Aug 1992 13:36:58 GMT
Keywords: hacking

In article <1992Aug25.060803.4021@u.washington.edu> fetrow@biostat.washington.edu (David Fetrow) writes:
>richg@hatch.socal.com (Rich Greenberg) writes:
>>. . . instead of phoning someone local (same company, same city) you
>>send email even when you know they have voicemail/answering machine.
>
> Naw. Email doesn't usually wake a person up when they've been on a hacking run.
>
> That includes the office number (I suspect many of us have sleeping materials
>stashed in the office for the occasional allday+allnight+allday).
			.
			.
			.
Some don't?
-- 

Cameron Laird
claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net)	+1 713 267 7966
claird@litwin.com (claird%litwin.com@uunet.uu.net)  	+1 713 996 8546
Xref: sparky alt.folklore.computers:13245 comp.unix.misc:3407