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: Tue, 8 Sep 1992 10:13:02 GMT

In article <6O1JFJF@taronga.com> peter@taronga.com (Peter da Silva) writes:
>In article <1992Sep3.082922.3281@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>When the hll zealots go away, the flames will go away.  My position has
>>been made abundantly clear on the rest.
>
>You *say* you're just advocating the appropriate use of assembly, yet you
>continually argue it's reasonable to write entire applications in assembly.
>
>It's not, and hasn't been for at least 10 years. Writing an application in
>assembly is (1) pointless machismo, and (2) the biggest reason DOS has been
>unable to significantly improve in the past 10 years.

Depending on the application, it may be pointless to use anything less
than 100% assembly or 100% C.  I never claimed anything less.  But what I
did claim is that assembler is underutilized, and that often projects are
clumsily written in hll, in the sense that assembler could do portions a
whole lot better.  If all of the support code for an application already
exists, it's pointless to rewrite it regardless of language.  It just so
happens that for some situations, the pre-existing code is assembler.
Further, certain trade-offs of performance may dictate the direction of
how much is enough, so I would never rule out 100% assembler.  The MS-DOS
Kermit example probably need not be 100% so, but considering that the 
alternative would be to tie the product to the folly of the C-based Kermits,
I would vote against that.

Programs aren't written for machismo, they're written to satisfy engineering
considerations in implementing systems.  Your point is pointless machismo.
DOS improvement considerations are unrelated to an hll versus assembler 
argument.  In fact parts of DOS *are* written in C.  You can alwayws recognize
them, since they take up far too much code space compared to what an assembler
version would.  In this system, space often is a consideration consistent with
reasonable speed.  C-generated code rots on these points.

cjl
From: billj@picasso.ocis.temple.edu (William Jones)
Newsgroups: alt.folklore.computers
Subject: Hacker's Guide..
Date: 6 Sep 92 00:11:22 GMT
Organization: Temple University
X-Newsreader: Tin 1.1 PL5

I don't know if this is the right palce to post this but I am pretty
sure that somebody here knows the answer, so - Could someone tell me 
where to find something called 'The Hacker's Guide to the Universe'?

I understand it is available from anonymous ftp from somewhere, but where
can I find it?

Please mail me the answer as I have had all kinds of problems reading news
here.

Thanks,
  billj@picasso.ocis.temple.edu  Bill Jones
Newsgroups: alt.folklore.computers
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: You know when you're hacking too long when...
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Tue, 08 Sep 92 18:19:38 GMT

In <1992Sep6.021534.17359@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:

>ericj@eskimo.celestial.com (Eric Jorgensen) writes:

>>How about writing (hand-written) ':)' at the end of sarcastic items (yes,
>>sideways)?

>I sometimes do that, but only if I know the person I'm writing to is
>another emailer and/or IRCer. And yes, I usually don't write email
>from my holidays, postcards are nicer :-)

I once wrote email greetinx from abroad, although  that  was  not
from  a  holiday  but  from  a  conference.  The folx here in the
institute were on the one hand amazed I had worked  my  way  into
our  machine  from  overseas, but then they said they still would
have preferred a real postcard...

Greetinx, Jan

 +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
 |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
 |                                                                   |
 *----=<  hierarchical systems are for files, not for humans  >=-----*
From: jimf@centerline.com (Jim Frost)
Newsgroups: alt.folklore.computers
Subject: Re: Please help me identify this Kaypro!
Date: 14 Sep 1992 19:55:03 GMT
Organization: CenterLine Software, Inc.
Distribution: usa
NNTP-Posting-Host: 140.239.3.202
Keywords: HELP!

kharber@ecn.purdue.edu (Keith A Harber) writes:
>I'd appreciate any help in identifying this Kaypro, someone told me that
>Kaypro maybe just had a few Kaypro 1's for testing/prototype purposes, and
>it evolved into the Kaypro 2 and this one was modified to be a 2.

That sounds right, the only problem being that the 1/2-height drives
were too expensive for production machines when the Kaypro II was
first being built.  I have a II at home -- two full-height drives
mounted horizontally one on top of the other.  The 1984 model of the
II used half-height drives.  The original II's only had the keyboard
(4-pin RJ11), one 25-pin serial, and one Centronix parallel port.  I
think the 1984 version had two serial ports but I'm fuzzy on that, and
I have no idea what the 6-pin connector might be.

I have the Kaypro service manual at home which describes all of their
production machines up to about 1986; I'll go see if I can find your
machine -- or anything close -- tonight.

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
Subject: Re: GOTOs
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 5 Sep 92 09:11:33 GMT
Distribution: world
Organization: The Wolery

9125113g@lux.latrobe.edu.au (Mitch Davis) writes:
> var state:integer;
>     leave:boolean;
> 
> begin
>   state := 0;
>   repeat
>     case state of
>       0:leave := init_rs232;
>       1:leave := init_modem;
>       2:leave := dial_modem;
>       3:leave := log_on;
>       4:leave := do_the_business;
>     end;
>     case leave of
>       true :leave := false;
>       false:state := state + 1;
>     end;
>   until (state=5);
> end;

Ah, the standard Pascal way out of using GOTOs... 8-)

Seriously, playing with context variables like that is just pushing the
GOTO to another level -- you're still affecting the flow of control in 
not terribly obvious ways (it is obvious in this trivial example, but bury
that in a couple of megs of source and you'll get the picture).  

At least a GOTO says "Hey, I'm going somewhere else!", whereas this isn't
clear by setting a context variable.

Don's rule of GOTOs: if the algorithm specifies a GOTO, use a GOTO.

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Newsgroups: alt.folklore.computers,comp.unix.misc
From: peter@NeoSoft.com (Peter da Silva)
Subject: Re:  The need for an assembler (was: Favorite CPU)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Tue, 15 Sep 1992 12:32:22 GMT
Summary: Re: the need for this debate.

In article <1992Sep15.072724.25551@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> Why even respond to this smart-ass post?  Juvenile minds on this group
> are attempting to subvert a technically-based argument with either insulting
> personal attacks or insulting infantile remarks.  If you have nothing useful
> to say, don't say anything.

You'll notice that I haven't said anything lately?

That's because this debate long ago degenerated into a futile attempt to get
a couple of basic points through to a single person. After a while I realised
I was making the same points I'd made days earlier, because you were making
the same points you'd made fdays earlier. I think we can all agree on the
following:

	1. There are things you can't do in a portable language. Some
	   things you need to do are machine specific.

	2. There are things that are hard or impossible to do efficiently
	   in a portable language.

	3. All other things being equal, higher level languages are more
	   likely to be portable and maintainable.

Corrolaries:

	4. There is usually a penalty in performance for using a higher level
	   language.

	5. There is usually a penalty in maintainability for using a lower
	   level language.

	6. There is usually a penalty in portability for using a lower level
	   language.

Goals:

	7. Performance and maintainability aside, portability is a desirable
	   goal.

	8. Performance and portability aside, maintainability is a desirable
	   goal.

	9. Maintainability and portability aside, performance is a desirable
	   goal.

The real world:

	10. The importance of these goals and penalties depends on the target
	    market, the quality of the development tools available, the
	    performance of the underlying hardware, the quality of the
	    developers, and a number of other factors I'm too lazy to type
	    in.

These are the technical facts that I believe we've hashed out Now, my
conclusions:

The language to choose in a routine, program, project, or product, is based
on balancing all these points.  If a high level language can not do the job,
for reasons of capability or performance, you have to use assembly. If you
don't have to use assembly, then you should use a higher level language.

All of these arguments should then be repeated, replacing assembly with low
level abstract languages like C, Fortran, etcetera. If you still don't need
this level of detailed control over the problem, jump up another level and
switch to Lisp, Smalltalk, or even shell scripts...

If you've come to a different conclusion, or have disagreements with any of
my technical points, please feel free to comment.
-- 
Peter da Silva.  <peter@sugar.neosoft.com>.
 `-_-'   "Have you hugged your wolf today?"
  'U`
From: kps@cunixb.cc.columbia.edu (Karthik P Sheka)
Newsgroups: alt.folklore.computers
Subject: Re: Indentation
Keywords: tab
Date: 15 Sep 92 19:59:33 GMT
Reply-To: kps@cunixb.cc.columbia.edu (Karthik P Sheka)
Organization: Columbia University

In article <5737@osc.COM> Joe Keane <jgk@osc.com> writes:
>In article <1992Sep2.122451.16343@kth.se> krona@cyklop.nada.kth.se (Kjell
>Krona) writes:
>>In several programming environments on the Macintosh, the code is
>>indented acccording to its scope automatically. In HyperTalk, the
>>programming language of HyperCard, the editor indents the code when
>>the tab key is pressed. This immediately shows up any mistakes in
>>the scope logic, and is very useful (at least for me).
>
>Yes, Emacs does this for me too, when i write C or Lisp.  I think it's a good
>feature to be able to compute indentation based on scoping.  On the other
>hand, i think it's a terrible idea to compute scoping based on indentation.

Are there any DOS editors out there that can indent on scoping?  Most of
the ones I've seen out there (like freemacs) do so horribly, often
indenting too many spaces.  (I would like one that would indent two spaces
for each level of scope.)

Karthik Sheka              | It's not an optical illusion.  It just looks like
kps@cunixb.cc.columbia.edu |    one.
karthik@cs.columbia.edu    | By "recursion" I mean "defined by recursion".
Newsgroups: alt.folklore.computers,comp.unix.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Xenix Support, FICC
Date: Wed, 9 Sep 1992 19:50:14 GMT

In article <mch.716033734@regent.e-technik.tu-muenchen.de> mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann) writes:
> >Frightening, isn't it. If IBM had chosen ANY other existing operating
> >system they might be running something real.

> Why frightening? Few people have the money to buy programs
> or computers which are of no use for them.

Why is that relevant? If IBM had chosen any other operating system for the
PC the software and hardware for that system would be as cheap as DOS stuff
is now... and I wouldn't have to tell people "sorry, you can't do that under
DOS". An enormous amount of time and money has gone into repairing the
deficiencies of DOS, and the result is still a mess.

> So I believe that for most MS/DR-DOS users and IBM-PC/AT owners this setup
> does the job the want to be done. 

So does a CP/M system, just as well in most cases.

> Why were the world happier if they would all use VMS and have a VAX ?

They may well. WNT is basically VMS jr.

> >The green revolution has proved that with enough effort even dtrip-mined
> >and poisoned deserts can be made to flower, but I prefer not to live in one.

> Agreed. You prefer for your tasks Amigas and Macs.

Actually, I'd prefer something better than either. They don't yet exist.

Other people who are currently using DOS would be more productive if they
didn't have to live with the limitations of DOS. Sorry, you can't get there
from here.

> Most users I know don't care about the deficiencies
> their hardware & software (ISA, DOS) certainly has,
> as long as they get their job done w/o hassle. 

And, with MS-DOS, they frequently can't.
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
From: person@plains.NoDak.edu (Brett G Person )
Newsgroups: alt.folklore.computers
Subject: Re: GUIs Considered Harmful
Date: 15 Sep 92 01:46:38 GMT
Organization: North Dakota Higher Education Computing Network

In article <ALANB.92Sep9124903@swordfish.sdl.mdcbbs.com> alanb@sdl.mdcbbs.com (Alan Braggins) writes:

>I've used a Xerox optical mouse that worked whichever way around the mouse
>pad was, and would also work of a photocopy of the original pad, so you could
>choose your own dot pitch.
-- 
Brett Person
Guest Account	
North Dakota State University
person@plains.nodak.edu || person@plains.bitnet
"Freedom's just another word for nothin' left to loose"
Newsgroups: alt.folklore.computers,comp.unix.misc
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: Tue, 8 Sep 1992 09:50:00 GMT

In article <AX0JNS5@taronga.com> peter@taronga.com (Peter da Silva) writes:
>In article <1992Sep4.042704.21287@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>The non-portability of code to incompatible architectures is well known and
>>usually an acceptable tradeoff to writers of assembly code.
>
>Translation:
>
>	People who write applications in assembly code are people who
>	are willing to trade off a factor of 10 or more in a few years
>	for a factor of two in a portion of the code today.

No, not a translation at all, just some self-serving words you dredged up
to twist my statement.

The factor of two may be more or even less improvement today.  But the 
improvement follows you.  You are attempting an old and incorrect argument
that *never* works: that the new models are better because they have
new and wonderful features that make you stop using the old ones.  The
truth is that for any "family" of machines, the "meat and potatoes" of
the code is the same for all models.  You can get little tweaks along the
way *if* you are willing to create incompatible versions, but the operative
word is *little*.  The main level of improvement comes with overall speedup
of the machine.  *All* programs benefit from that, regardless of source
language.  The only point against assembler is that eventually the machines
become obsolete in favor of something else, and then you have to learn
that new architecture.  However, more than a few people have indicated that
15 years seems to be a good number for one's expectation of the "lifetime"
of a family of machines, which is more than enough time to permit the
devotion of intimate machine knowledge only obtained in assembler.  Moreover,
you take all your knowledge with you to the new machine.  Assembler is never
conceptually different on different machines, just different specifics.  After
you've looked at a few, some "old friends" appear in the form of familiar
quirks of the design, both good and bad.  In any case, experienced people
get accustomed to the new environment with perhaps the same effort that
a hll person learns another vaguely similar hll.  Yes, it takes some doing,
but some here would grossly exaggerate the problem.

cjl
Newsgroups: alt.folklore.computers
From: peter@taronga.com (Peter da Silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Taronga Park BBS
Date: Thu, 10 Sep 1992 10:48:45 GMT

In article <1992Sep8.090511.15166@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <O7ZIWJC@taronga.com> peter@taronga.com (Peter da Silva) writes:
>>In article <1992Aug31.050254.12657@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>>In any case, the point was made abundantly clear: there are untranslatable
>>>features expressable only in assembler.

>>Some languages allow access to any machine code instruction from quite a high
>>level (A-Natural, the C variant on the Bellmac-32, any Forth worth using),
>>and other high level languages allow access to any machine facility (PL/M,
>>for example, is about the same level as C and provides direct access to all
>>80x86 capabilities).

>Yes, you can *access* the capabilities, an oversimplification is to claim
>that BASIC can *access* *anything* using PEEK and POKE.

You really have no idea what any of the languages I described other than
C are like, do you? Apart from PL/M these are much lower level languages
than C, but much more readable and less error prone than assembly. PL/M,
A-Natural, and Bellmac C are not portable in the same way as C, but Forth
is... I've written code in Forth that's run without change on HP, DEC,
Intel, and Signetics processors. And Forth certainly qualifies as a tight
language... most Forth programs are *smaller* than assembly equivalents.

>But what's wrong
>is that you have to call closed assembly-language-written functions to allow
>certain structures to be expressed, since C doesn't have the means to
>express the actually running code.

You've never used a compiler that provided inline assembly? And applied
optimizations to the resulting code? You can write a program in 99% C and
still get down and dirty when you need to. When you need to. Not all the
time because it makes you feel better.

>Sloppy mathematically "equivalent" code doesn't count here.

Sure it does. If it produces the same result and runs fast enough (and
let's not get into a fight over "fast enough"... we're talking about
a factor of a few percent in substantial programs), why doesn't it?

In a very few cases (interrupt handlers, other small time-critical codes
like BitBlt or a microkernel) assembly is substantially faster. For
anything larger, it all comes out in the wash.
-- 
                                                                `-_-'
                         Har du kramat din varg idag?            'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
Newsgroups: alt.folklore.computers
From: u734120@bruny.cc.utas.edu.au (John Lamp)
Subject: Re: automatic CP/M to MS-DOS migration?
Keywords: assembler, 8080, 8088, 8086
Organization: University of Tasmania, Australia.
Date: Tue, 8 Sep 1992 11:33:18 GMT

ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:

>If I remember correctly, one of the points in favour of MS-DOS 1.0 when
>it was introduced was the easy porting of CP/M software (^Z as end of
>file marker, COM - files, file control blocks).

>Just how far was this automated? Are 8080 and 8086 related closely enough
>that you could write an assembler which translated 8080 assembly into
>8086 code? Was this how, for example, WordStar was ported?

Indeed yes - there was a program called Xlate-86, from memory, which did
just that.  While I have no first hand info I believe that's how WS 3.3
and dBase II got onto the IBM-PC so quickly.

Found it!

"As we said when we first tested the IBM last year, the BASIC interpreter of the
PC is lamentably slow - approximately equivalent to running the 8-bit
version on a 3MHz Z-80.

The reason for this is that Microsoft presumably translated its 8-bit software
to 8086 code using a translator program such as Intel's CONV-86 or Digital
Research's XTL-86.  Such programs cannot make intelligent assumptions
about what the programmer is doing and will always produce conservative code.
In addition many of the 8080 instructions have no single equivalent on the
8088 but must be emulated with a sequence of instructions."

Your Computer, Jan/Feb 1983

Cheers
John
--
   _--_|\             John Lamp, originating in Hobart, Tasmania
  /      \                 Phone: 002 23 1366 - Fax: 002 34 5685
  \_.--._/                   email: u734120@bruny.cc.utas.edu.au
        v <-----------------------------------------------------
Newsgroups: alt.folklore.computers
From: jack@jato.jpl.nasa.gov (Jack Kobzeff)
Subject: Re: "GOTO-less" BASIC
Followup-To: alt.folklore.computers
Organization: Jet Propulsion Lab
Date: Fri, 11 Sep 1992 17:59:20 GMT

In article <1992Sep5.155332.9272@bsu-ucs.uucp>, 01ksdavis@bsu-ucs.uucp
wrote:
> 
> In article <samw.715627675@bucket>, samw@bucket.rain.com (Sam Warden) writes:
> > dpbsmith@world.std.com (Daniel P. B. Smith) writes:
> > 
> > (Please note: I am NOT suggesting that professional coding is
> > done in line-numbered BASIC.  On the other hand, from some of
> > the management I've seen....)  8-)  8-)  8-) 
> > -- 
> 
> 	I don't know about professional programs written in BASIC.  I have some
> programs that are very useful (a file monitor, even a program that makes 
> signs, and even a reasonably easy database) and a host of other programs I 
> wrote for my own amusement (like a tabloid generator or something else.)
> 
> 		You know, I am sick of language superiority.  It is ALMOST as
> silly as computer superiority.  I.E.  My computer is better than yours, so 
> die!

It does seem that many people have lost sight of the main purpose of these
boxes we use, and that is to do work. (Work isn't always serious.;-) ) The
computer doesn't care what it's programmed  in. And sometimes, the extra
programming overhead of the 'more efficent' languages offsets the ability
to quickly knock out a quick and dirty tool in Basic or the like. Many,
many times, I have seen useful number crunchers done quickly in BASIC
before the 'high level' language people could get their compilers warmed
up.

Jack Kobzeff     (jack@jato.jpl.nasa.gov)
From: weisberg@ee.rochester.edu (Jeff Weisberg)
Newsgroups: alt.folklore.computers
Subject: Re: The third variable.
Summary: foo bar baz
Date: 11 Sep 92 23:59:02 GMT
Organization: Univ of Rochester, College of Engineering and Applied Science

/* Alright....the first variable is foo, and the second variable is bar.  What
/* is the third?  Is is sna -->sna foo bar, or is it toe -->toe foo bar?  Is

No, it is "baz"

-jeff
Newsgroups: alt.folklore.computers,comp.unix.misc