HDTenEightyP/NetNews huggingface dataset:
From: peter@taronga.com (Peter da Silva)
Subject: Re: Assembler and Optimization (was Re: The need for an assembler (was: Favorite CPU))
Organization: Taronga Park BBS
Date: Sat, 5 Sep 1992 02:00:23 GMT

In article <1992Aug31.211145.21668@usenet.ins.cwru.edu> rfd@po.CWRU.Edu (Richard F. Drushel) writes:
>	If program size is *utterly critical*, use assembler.

If the program *size* is utterly critical, use Forth or some other tight
pseudocode. At one time I used a 3-user development system that ran in
12K of ROM, compilers, editors, disk, everything fit. RAM was 4 or 16K.

>	HLLs.  If you don't care how big the executable file is,

If the size of the runtime is not important, you mean. Or the runtime
is in a shared file.

>or how fast it runs,

Loads, maybe. Good compilers are as fast as assembly these days, for any
nontrivial program.

>If you have a horrendously complex program,

Like, anything over a few hundred lines.

>	Thesis and antithesis out of the way, it's time for some
>synthesis...In the newer computers (e.g. '286s and up for the DOS line,
>Mac IIs, and all the sundry UNIX boxes I hear you guys talk about)
>RAM and HD storage space go on for ever, the machines run at 25 mHz or
>more, and have all kinds of number-crunching features to the CPUs
>(built-in math coprocessors, hardware division and multiplication).

Let's see, I'm running multitasking operating systems on all my computers
that have more than 128K of RAM. Only two have disk drives, and none
go over 16 MHz. I use HLLs on all of them because MY time is worth more
than THEIRS.

>	HLLs and assembler each have their place.  I am afraid, however,
>that assembler is more and more being relegated to a strictly device-
>driver role, and that its days of being the primary language type for
>composing new application software are over.

Apart from people doing heroic work trying to get an 8088 or x80 to
keep up with a real CPU, the days of writing applications in assembler
were over in the early '70s.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
Newsgroups: alt.folklore.computers
From: zik@aurora.cc.monash.edu.au (Michael Saleeba [Zik])
Subject: Re: Unlistable BASIC (was: YAFP: TRS-80 Super Graphics)
Organization: Monash University, Melb., Australia.
Date: Sat, 5 Sep 1992 00:59:13 GMT

In article <1992Sep1.183035.20969@utdallas.edu> shane@utdallas.edu writes:
>
>On the Apple, I'm pretty sure you could POKE a begin- or end-of-BASIC-program
>address somewhere in zero page which would result in abridged output from
>LIST. You could also make "unmodifyable" code, even if LIST displayed it, by
>replacing line numbers with numbers >63999. Applesoft called a line number
>higher than 63999 a syntax error, so by POKEing 65535 or whatever into the
>line number, it became immune to standard BASIC editing.

And in article <1992Sep03.023833.4079@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes:
>Other neat Applesoft hacks-- there was another POKE which would cause
>LIST to display only the first statement on a line, so by starting all
>lines with a colon, you had invisible code.  Changing address $D6 (I
>think) to a nonzero value caused Applesoft to execute "RUN" no matter
>what you typed-- more primitive copy-protection.  

Applesoft represented programs as a linked list of lines, each of
which had a line number stored with it. Normally you'd just have a
list stored in order, with increasing line numbers. If you wanted to
have some fun you could get into the monitor and create some havoc :-)

Great fun - you could make a program with line numbers that went in
reverse! Better still since the LIST command displayed the lines in
the order they appeared in memory you could make programs which listed
in reverse from the order they executed! Or for total confusion, a
program which _looked_ completely normal, with increasing line
numbers, but which executed them in an apparently random order! Get
your friends to debug _that_ one :-)

+---------------------------------------------------------------------+
|             Zik                   |  "I don't want the world -      |
|       Michael Saleeba             |   I just want your half"        |
|   zik@bruce.cs.monash.oz.au       |                     - TMBG      |
+---------------------------------------------------------------------+
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: alt.folklore.computers
Date: Mon, 14 Sep 1992 03:02:55 -0400 
From: "Joseph M. Newcomer" <jn11+@andrew.cmu.edu>
Subject: Re: Who invented the digital computer

Excerpts from netnews.alt.folklore.computers: 8-Sep-92 Re: Who invented
the digita.. by Koen Holtman@blade.stack 
> Apparently, look and feel was unknown in those days.

For which I am grateful.  I would hate to have to fight IBM on the
look-and-feel of my 1401 simulator! :-)
                                joe

Newsgroups: alt.folklore.computers
From: artn@bert.eecs.uic.edu (Ellyn Sandor)
Subject: Re: Renumbering BASIC programs (was Re: Branching in HLL vs. Assembler)
Organization: University of Illinois at Chicago
Date: Sat, 5 Sep 1992 00:27:19 GMT

>>>	Bonus:  guess the BASIC's.

1) The CASE trick was from the Sinclair ZX-80 (one person got it right)
2) The RENUM was from TI-99 Basic, but guessing probably wasn't fair,
	since a lot of basics used tokenizing...

			sm

-- 
--
Stephan Meyers | artn@uicbert.eecs.uic.edu
(Art)^n Laboratories, inventors of the Stealth Negative PHSCologram
(312) 567-3762
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers
Subject: Most PCs are *not* on.. (was: The need for an assembler)
Date: 9 Sep 1992 14:14:48 -0400
Organization: Berkeley Software Design
Distribution: world
NNTP-Posting-Host: rodan.uu.net

In article <1992Sep8.075544.25771@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> obFACT: most PC's are *not* on internet.

Most PCs are hooked tho the net --

110V 60Hz.


(An old Moscow U CS dept.'s gag with minor changes).

--vadim
From: boebert@sctc.com (Earl Boebert)
Newsgroups: alt.folklore.computers
Subject: Any old Honeywell H800/H1800/H8200 programmers out there?
Date: 8 Sep 92 22:48:25 GMT
Organization: SCTC

Well, the title says it all.  Enough of this idle chatter about some
circa 1974 machine being "old" and "weird."  We're talking early
1960's here, *big* iron, eight register sets with hardware
multiprogramming, two instruction counters (with sign bits, no less)
and just about every way to form an address known to man.  Plus a
console right out of a George Pal SF movie.  The 8200 was even
stranger; married this beast (a 48-bit word machine) with a 1401 clone
to form a cross-cultural multiprocessor.

The Air Force had a bunch of 800s (which was where I ran across them)
as did Metropolitan Life Insurance.

Anybody else out there remember this golden oldie, and get teary-eyed
at the mention of Argus and FACT?

Earl
Newsgroups: alt.folklore.computers
From: peter@taronga.com (Peter da Silva)
Subject: Re: Better dead than IBM
Organization: Taronga Park BBS
Date: Sat, 5 Sep 1992 01:08:58 GMT

In article <1992Aug31.050840.12800@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>IBM: you can get better anywhere, but you can't pay more.

I thought that changed when the Macintosh came out.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
From: johnb@searchtech.com (John Baldwin)
Newsgroups: alt.folklore.computers
Subject: Re: GOTOs
Date: 13 Sep 92 03:50:49 GMT
Organization: Search Technology, Inc.

In article <1685E12F5C.IQTI400@INDYCMS.IUPUI.EDU>
	IQTI400@INDYCMS.IUPUI.EDU (macphil) writes:

> In article <1992Sep11.010558.16893@cs.cornell.edu>
> csuley@cs.cornell.edu (Christopher Suley) writes:
> 
>> Couldn't it be argued that object-oriented programming has reintroduced
>> this 'GOTO problem' in a much more insidious form?
>>
>>Or do I not understand OOP well enough yet? (A distinct possibility)
> 
>I'm not an OOP heavy, but it sounds (don't take this wrong) like your
>concerns are either misdirected or a little paranoid...
                                      ^^^^^^


   Those concerns are just a >little< paranoid.  It IS possible to write
   "spaghetti classes"  (er, class vermicelli : public pasta { ... }; )
   just as it is possible to write spaghetti code.

   Sometimes it is more difficult to detect convoluted design in classes
   than it is in procedural code.


-- 
John Baldwin                                        johnb@searchtech.com
Search Technology, Inc.                             uupsi!srchtec!johnb
4725 Peachtree Corners Circle, Suite 200            johnb@srchtec.uucp
Norcross, Georgia  30092   USA
Xref: sparky alt.folklore.computers:13746 comp.lang.c:13319
Newsgroups: alt.folklore.computers,comp.lang.c
Subject: Re: bogosort revisited (with source)
From: chisnall@cosc.canterbury.ac.nz (The Technicolour Throw-up)
Date: 8 Sep 92 22:40:59 +1200
Distribution: world
Organization: Computer Science,University of Canterbury,New Zealand

From article <1992Sep6.023647.1872@smds.com>, by rh@smds.com (Richard Harter):
> [...]
> The only fair way to approach this is to use a deterministic algorithm.
> For example, generate all permutations in order.  For each permutation
> apply it to the list to be sorted and see whether it produces a sorted
> list.  Simple, elegant, and O(N!).

Not so.  There are n! permutations to generate.  Each permutation takes O(n)
time to check and k, say, time to generate.  We take k to be some nonzero
constant multiple of the time it takes for one comparison.  Each permutation
therefore takes total time O(n+k) to generate and check.  Summing over all
permutations this gives an average running time of O(n!(n+k)) which is
O(n!(n+1) + n!(k-1)) which gives O((n+1)!) as the running time.

--
Just my two rubber ningis worth.
Name: Michael Chisnall  (chisnall@cosc.canterbury.ac.nz)
I'm not a .signature virus and nor do I play one on tv.
Newsgroups: alt.folklore.computers,comp.unix.misc
From: peter@taronga.com (Peter da Silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Taronga Park BBS
Date: Mon, 7 Sep 1992 05:50:48 GMT

I wrote:
>You need to learn how to write portable C, but once it's done it's NOT any
>harder than writing non-portable C and porting it.

That's not quite what I meant to write... let's try that again.

You need to learn how to write portable C, but once it's done it's NOT any
harder than writing non-portable C and a lot easier than writing in non
portable C then porting it.

Of course I also try and factor problems into generally useful routines...
instead of writing a symbol table for an application I'll write a general
purpose symbol table routine.

It's no harder and saves lots of time the next time around.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.folklore.computers
Subject: Re: Is there a PDP-11 (or 8, or...) Emulator?
Date: 14 Sep 92 13:18:10 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <1633@anagld.analytics.com>,
by bob@anagld.analytics.com (Bob Smith):
> 
>  I too would welcome a forum for sharing information on the
> second generation of the first risc machine (defference to PDP5)
> and would be glad to share my knowledge.
> 
I've recently been reading through the CPU schematics of the PDP-8/E, and
I hate to burst people's bubbles, but even though the PDP-8 instruction
set looks like a RISC instruction set, the designers of the -8/E didn't
know a whole lot about RISC design!  They managed to cobble up a design
that needed 4 microcycles per memory cycle, and they used them the way
a good CISC designer uses microcycles.  There was no microcode, as such,
the control logic was all random, but it's clearly not done in the RISC
style.
				Doug Jones
				jones@cs.uiowa.edu
From: jrs8@quads.uchicago.edu (john richard stracke)
Newsgroups: alt.folklore.computers
Subject: Re: IF-less programming
Date: 4 Sep 92 18:39:59 GMT
Reply-To: jrs8@midway.uchicago.edu
Organization: University of Chicago Computing Organizations

In article <18847lINNn0b@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
>In article <Bu14o2.Hvz@world.std.com> dpbsmith@world.std.com (Daniel P. B. Smith) writes:
>>[reimplementing code with branches as code with logical states]
>>
>>So, the way I figure it ... lots of bugs are the result of logic paths not
>>taken, right?  So if you eliminate all the IF statements there is only
>>one logic path, hence it's easy to get 100% test coverage.
>
>Well, to be precise it is not the "path not taken" but "states never
>reached". Thus your approach worth nothing as a tool for improving
>reliablity of software. It is widely employed by modern RISC compilers

No, no--the point is that *all* states are reached, so you don't have
to run it more than once to test everything.

/============================================================================\
| Francis Stracke              | My opinions are my own.  I don't steal them.|
| Natl. Sci. Center Foundation |=============================================|
| Augusta, GA                  | Eat when hungry.  Sleep when tired.         |
| francis@dogwood.atl.ga.us    |   Hack whenever.                            |
\============================================================================/
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: alt.folklore.computers
Subject: Re: Who invented the digital computer (references)
Date: 9 Sep 1992 01:15:24 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


Probably the question that started this is the Sperry Univac vs. Honeywell
suit.  Couple of books are:
1. Burks, Alice R., 1920-
     The first electronic computer : the Atanasoff story / Alice R. Burks and
   Arthur W. Burks.  Ann Arbor : University of Michigan Press, c1988.
       UCSC  Science   QA76.5 .B825 1988

2. Mollenhoff, Clark R.
     Atanasoff : forgotten father of the computer / Clark R. Mollenhoff.  1st
   ed.  Ames : Iowa State University Press, 1988.
       UCSC  Science   QA76.2.A75 M65 1988

-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

Xref: sparky alt.folklore.computers:13724 comp.windows.misc:1360 comp.windows.x:16290 comp.human-factors:2118
From: adrian@milton.u.washington.edu (Adrian Mariano)
Newsgroups: alt.folklore.computers,comp.windows.misc,comp.windows.x,comp.human-factors
Subject: Re: GUIs Considered Harmful
Date: 7 Sep 92 21:30:24 GMT
Article-I.D.: milton.adrian.715901424
Organization: University of Washington

In <1992Sep6.133051.24008@monu6.cc.monash.edu.au> parry@yoyo.cc.monash.edu.au (Tom J Parry) writes:

>The mice on the SG Irises here don't have moving parts at all. They use
>little red LEDs and a reflective metal mouse pad with little squares on
>it! What's more some of the pads have different dot pitches so the mouse
>movement speeds are different.

Fortunately, SGI seems to be moving away from this.  The Iris Indigos
I have used have ball mice. 

The problem with the mice that use the LEDs and reflective mouse pads
is that you must use the mouse pad, and you MUST have it oriented
correctly.  If you turn it 90 degrees, the mouse won't work.  If the
mouse pad gets rotated, then the mouse won't do what you want (or
expect).  
Xref: sparky alt.folklore.computers:13821 comp.unix.misc:3612
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
From: scott@yarc.uucp (Scott Beckstead)
Date: Tue, 08 Sep 1992 17:53:03 GMT
Reply-To: scott@yarc.UUCP (Scott Beckstead)
Organization: Yarc Systems

In article <jimf.715915168@centerline.com> jimf@centerline.com (Jim Frost) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>I doubt that for any
>>practical project, the "restriction" to "only" 16 Mbytes of program space
>>should be cause for alarm, so I'll restrict myself to only the two relevant
>>cases.
>
>16Mbytes is nothing.  It's a drop in the bucket for some applications.
>I've seen people who were having problems with the four gigabyte
>limitation you have with 32-bit addressing.  (Hell, I've run into
>problems with the 256Mb data+stack you get by default on the RS/6000.)
>
>Lots of "practical" programs require more than 16Mbytes to run.
>
>jim frost
>jimf@centerline.com

 Yeah back in the days of the altair 8800 Those far sighted engineers said
that NO ONE would ever need more than 4 kbytes of memory!



-- 
Reply to: scott@yarc.uucp 	|  
				|	Spin my nipple nuts and send me to   
  Smoke me a kipper, I'll be	| 	Alaska.
   back for breakfast	 	|       
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: alt.folklore.computers
Date: Mon, 14 Sep 1992 01:59:51 -0400 
From: "Joseph M. Newcomer" <jn11+@andrew.cmu.edu>
Subject: Re: Flash pix

I have actually worked on a device based on the DRAM-as-camera.  It
was a very interesting device called the "VideoHarp", invented by
Paul MacAvinney and Dean Rubine at CMU.  It was an optically scanned
MIDI controller which imaged a long bar of light projected from
the front of the unit along a surface to a set of mirrors creating a
folded light path onto one of these sensors.  The same technology was
used by the same company to build a device called the "Sensor Frame"
(the company was SensorFrame Corporation), which could detect multiple
images and even allow you to rotate your hand and control a virtual
knob on the screen.

The limitation on these two inventions was the rate at which the
image could be acquired.  What was done was to write all zeroes (or
was it ones?) into the DRAM, wait about 9ms, and read the data out.
It took about 9ms to fully discharge the capacitors reliably.  With
a slightly brigher light source, I believe the best we got was
about 6.5ms.  The best sensitivity was in the IR range; visible light
was less effective.

I wish I had one now.

The problem was that the company that made the sensors was the same group
of turkeys that got DRAM prices raised out of sight; after they got DRAMs
sufficiently expensive that nobody could afford them any longer, they
were making so much money that they didn't need their low-profit operations
such as the sensors, so they discontinued manufacture of them (without
notifiying any of their customers).  This meant that SensorFrame could
only get about 100 chips instead of the 1,000 they had ordered.  Since a
Sensor Frame required 4 sensors, and a VideoHarp only one, the decision
was to try to sell 100 VideoHarps instead of 25 SensorFrames, and to use
the time to redesign the Frame to use CCD devices (which were far more
expensive).  But VideoHarps didn't sell very well, and the company
suspended operations.  Paul is off working on more exciting technology
using different sensors, but
I can't talk about that as I'm under nondisclosure.  One thing he will
*NEVER* do again, however, is predicate the success of a company on a
sole-sourced product! 
Newsgroups: alt.folklore.computers
From: oldman@titan.ucc.umass.edu (Tig Stone)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assemble
Organization: University of Massachusetts at Amherst
Date: Fri, 11 Sep 1992 21:10:48 GMT

In article <NHaHqB7w164w@lorc.UUCP>, lowen@lorc.UUCP (Lamar Owen) writes:

> Well, this whole thread reminds me of the Obfuscated BASIC contest held by
> 80-Micro Way-Back-When(TM) for the TRS-80 dialect of MS BASIC.  I love code
> like this:
> 
> ...
> 120 IF (X=0) OR (K=X) THEN FOR I=1 TO 30:K=I-X^2+35:POKE 16385,(K MOD 256):
> NEXT I:IF K=245 THEN K=36 ELSE K=56: ELSE X=35:POKE 16385,X
> ...
> 
> And, even more insidious:
> 
> ...
> 120 FOR K=X TO Y STEP -2:IF K=2Y THEN GOSUB 3500:NEXT K:ELSE GOSUB 3530:
> K=K+2: NEXT K
> ...
> 
> The REAL winners of the ObBASIC contest were even more convoluted, with whole
> games being written in one, two, or three lines.  
[ code reformatted a tiny little bit -- sorry ]

I remember the days of writing 1 and 2 liners in BASIC on the Apple
II.  Since the line length was limited in Applesoft (I forget to how
many characters) in order to squeeze the maximum amount of code into
one logical line you had to take out all of the spaces!  Fortunately,
the parser didn't care if you had ANY space in there because if it
wasn't a keyword it assumed it was an identifier.

I'd write an example but it's been SO long that I have (fortunately)
all but forgotten how to write BASIC code.

> Ah, the memories... :-)

Yup.


--
T. Stone 
(oldman@titan.ucc.umass.edu)
Xref: sparky alt.folklore.computers:13859 comp.unix.misc:3635
From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 11 Sep 92 04:10:16 GMT
Organization: D & D Data

In article <id.__2T.SWB@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Sep8.093152.15699@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> would believe the mess of existent problems there are.  I suspect that
>> most readers on this group have insufficent "broad" experience to appreciate
>> just how bad this problem can be, especially with a program such as Kermit
>> that reaches into so many "corners" of a system all at once.
>
>What? Kermit doesn't reach into so many corners of a system. It talks on
>precisely two I/O streams, both of which are handled by the O/S. It's a

	Well, ... It depends on which version of unix you're trying to run
it on.  There is code in there (or was in earlier versions, I haven't
checked recently) which did a kernel dive to find out how many characters
were waiting in the input buffer, because the versions were either too old
to have a system call (actually, an ioctl, if I remember correctly) which
would return that information, or because the ioctl was present, but didn't
work with that particular hardware.  (This latter case was what the problem
was with the old 68000 v7 system I had (CMS-16/UNX) with the Systech
multi-terminal-I/O-card (16 serial ports).  Other (later) systems properly
implemented this ioctl, so it was a limitation of that early UniSoft port,
or the drivers written, perhaps, by SysTech - I'm not sure which.

	In any case, I would consider this a case of "reaching into obscure
corners", but it was conditional code, and didn't bother most users with
reasonably modern versions of unix.


-- 
Donald Nichols (DoN.)     | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
D&D Data                  |  Email: <dnichols@ceilidh.beartrack.com>
I said it - no one else   |         <nichols@nvl.army.mil>
	--- Black Holes are where God is dividing by zero ---
Newsgroups: alt.folklore.computers