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: Sat, 5 Sep 1992 04:40:36 GMT

In article <9224903.15845@mulga.cs.mu.OZ.AU> fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>
>Although I have been following this thread for quite a while, I apparently
>missed the start of it, and I haven't seen any examples posted at all.
>Perhaps you could post them again.
>
>(Otherwise I might be forced to agree with the poster who suggested that
>perhaps the references to examples were just a smokescreen :-| )

Perhaps you should read an archive of a.f.c, and then see if your post was
somewhat hasty or not.  In any case, there have been other more recent posts
from others addressing the issues of stuff better done/only done in assembler
or did you miss them too?

>
>>>The fact is that a compiler can emit whatever assembler code it likes.
>>>People HAVE written compilers that identify certain particular constructs
>>>and then emit carefully hand-crafted assembler that does the same thing.
>>>It IS possible, at least in principle, for a compiler to emit exactly the
>>>same code as anything a human could write.
>>
>>The stuff in question can't be syntactically expressed in the kind of hll
>>you are talking about.  If a hll largely consists of library calls to
>>closed functions or is an interpreter, then the details of some of the code
>>supporting the closed functions may indeed contain these features.  Hopefully
>>more than a few do; I personally know of some.  But, these features are 
>>off-limits at the hll level, and of course the code in question is written
>>in assembler.
>
>I suspect that your claim that "The stuff in question can't be syntactically
>expressed in the kind of hll you are talking about" stems from a
>misunderstanding of HLLs and compilers, especially when you go on to
>show that it *could* be syntactically expressed, as a call to a library
>subroutine.

Wrong, I stated that you can *call* closed routines written in assembler
that internally implement some things not expressable in the hll, and
that a higher hll could be written that could take advantage of it; other
posters alluded to similar ideas.


>Actually, since computers are in actual fact basically finite state automata,
>and since in the abstract sense HLL's are equivalent to Turing Machines,
>HLL's are in fact abstractions of *supersets* of what a computer does.
>Of course, this means that sometimes the abstraction will break down; the
>usual error message in this case is something like "stack overflow" or
>"insufficient core" :-)

I hope you aren't seriously attempting to backup any of that argument; the
performance issue of different code has little to do with arguments about
what is/is not "equivalent" based only on the concept of (eventually) getting
the same results (although not necessarily on one's own lifetime!).

cjl
Newsgroups: alt.folklore.computers,comp.lang.c
From: rob@guinness.eng.ohio-state.edu (Rob Carriere)
Subject: Re: bogosort revisited (with source)
Organization: The Ohio State University Dept of Electrical Engineering
Date: Wed, 9 Sep 1992 05:58:43 GMT

In article <23629@alice.att.com> ark@alice.UUCP () writes:
>In article <1992Sep2.175607.23225@grebyn.com> richk@grebyn.com (Richard
>Krehbiel) writes: 

>> In alt.folklore.computers, there has been a discussion of the worst
>> possible sorting algorithm, which has been called "bogosort".

>> My interpretation of the algorithm is this: Exchange two randomly
>> chosen elements of the array to be sorted.  Check to see if the array
>> is in order.  Iterate until done.

>It is possible to do ***much*** worse than that.

I don't understand.  This sort can take forever[1].  Therefore, the worst case
bound is O(\infty).  How much worse can you do than that?  :-)

In order to have a smaller bound :) one needs to know something about the
distribution from which the random permutation are drawn.

SR
[1] This event has probability zero, but is not impossible, for a `fair'
    (uniform probability dist.) generator of random permutations.
---


Newsgroups: alt.folklore.computers
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: The need for an assembler
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 5 Sep 1992 18:06:52 GMT

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:

>Matthews' example is very interesting; considering the assembly version is
>FIVE instructions.
>
>cjl

Whereas Matthew's example was basically ONE line? Yes, we already knew that
most code can be expressed more concisely using a HLL, so what?

Matthew wrote:

Matthew> This is not the example that I e-mailed cjl.  What I e-mailed him
Matthew> was basically the last line in "foo.h".
[...]
Matthew> I personally don't see any point to continue
Matthew> the discussion with cjl, because he repeatedly makes claims that
Matthew> are so far off base that it's clear that either he doesn't know
Matthew> what he's talking about or he does and is just baiting the rest of
Matthew> us, but either way, there's not much point to continue.  I suspect
Matthew> he'll have some off-the-wall objections to the example produced below,
Matthew> but pointing out the error in those will be left as an excercise for
Matthew> the reader.
    ... anything to occupy my spare time ;-)

[...]
Matthew> cjl declined to answer any of the points I raised in my last two
Matthew> posts, but that's OK.  I don't think it's likely that I'll convince
Matthew> him of anything, and you, the gentle reader, have seen enough to make
Matthew> up your own mind.

	Yes, I've seen enough. I think that this will be my last post on this
	thread.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: alt.folklore.computers
From: spc@pineal.sci.fau.edu (Sean 'Captain Napalm' Conner)
Subject: Obfuscated BASIC (was: Re: Branching in HLL vs. Assembler)
Organization: Florida Atlantic University, but who cares?
Date: Sat, 12 Sep 1992 18:34:26 GMT

In article <OLDMAN.92Sep11161048@titan.ucc.umass.edu> oldman@titan.ucc.umass.edu (Tig Stone) writes:
>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:
>> 
  [ some obfuscated BASIC code stored in the bit bucket ]

>> 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.
>

  Ah, I remember writing one line BASIC programs on my Color Computer (from
Radio Shack).  In fact, I think (hope hope) I remember how one went ...
(I've typed it in as you would see it on the screen, all 32 columns of
it 8-)

1 INPUTA,B,C,D,E,F,G,H:PMODE4,1:
SCREEN1,1:COLOR0,1:PCLS:I=0:FORX
=0TO1STEP0:X1=SIN(I+A)*B:Y1=COS(
I-C)*D:X2=SIN(I*E)*F:Y2=COS(I/G)
*H:LINE(X1,Y1)-(X2,Y2):I=I+0.5:I
FINKEY$=""THENNEXTELSE1

  You input 8 values, and then it uses those values to produce a strangely
flowing pattern on the screen until you press a key, at which point it
will start over again (hopefully, I got this correctly.  What was it, 5 or
6 years ago since I've programmed the Coco in BASIC? 8-)

  -spc (10 A$="FUNNY SIG":PRINTA$:GOTO10)

Newsgroups: alt.folklore.computers
From: ericj@eskimo.celestial.com (Eric Jorgensen)
Subject: Re: Flash Pictures Of The Sunset
Organization: -> ESKIMO NORTH (206) For-Ever <-
Date: Fri, 4 Sep 1992 13:30:25 GMT

ddb@tdkt.kksys.com (David Dyer-Bennet) writes:
> Like those who design cameras where you can't override the flash.

I've mastered the one handed photo-snap for just this reason.  If I don't want
a flash (with a friend's camera which automatically flashes), I just cover it
with a corner of my OTHER hand.  :)

Newsgroups: alt.folklore.computers,comp.unix.misc
From: swaim@owlnet.rice.edu (Michael Parks Swaim)
Newsgroups: alt.folklore.computers,comp.os.ms-windows.apps,comp.os.ms-windows.misc
Subject: Re: PROGRAM BLOAT - was Re: Ye Olde Secrete Screene Cheete Sheete .....
Date: 5 Sep 92 23:40:14 GMT
Organization: Rice University

In article <chil.715674735@sfu.ca> chil@fraser.sfu.ca (Keith Lim) writes:
>huot@cray.com (Tom Huot) writes:
>
>>This is just my $.02. It certainly is no wonder that this commercial
>>software is so bloated and expensive, when totally worthless crap
>>such as faces, fireworks, undocumented cheats are actually placed
>>in these programs.
>>AREN'T THE DAMN PROGRAMS GETTING BIG ENOUGH ALREADY???
>
>Even Easter Eggs and backdoors and "undocumented features" aren't enough
>to bloat programs from one disk to, say, twelve.

  Especially compared to the sillyness they have to put in there already.
A friend of mine works for a minor commercial Mac software company, and
they were thinking of adding sound hooks for all the major functions. Use
resedit to add the named resources, and boom! cut and paste have sound
effects. Meanwhile, higher ups wanted them to have color AND b&w bitmaps
for the "about..." box. Not an easter egg, but fairly expensieve in
terms of bytes.



-- 
Mike Swaim            | I can see clearly now my brain is gone.
swaim@owlnet.rice.edu | I can see all the bicycles in my way.
Rupp doesn't even know who I am,
 much less care what I think
Xref: sparky alt.folklore.computers:13749 comp.unix.misc:3576
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 8 Sep 92 09:40:05 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <7X0JVP5@taronga.com> peter@taronga.com (Peter da Silva) writes:
>In article <1992Sep5.022817.19437@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
>>In article <1992Sep3.091928.22081@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>>In article <id.7MVS.5EK@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>>>>In article <1992Aug31.162630.23913@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>>>> 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 guarantee you it won't run on *any* of my 80286 or 80386 or 80486
>>>>systems.
>
>>>>But Ckermit will.
>
>>>Totally incorrect; just setup the descriptor tables and change the directives
>>>and a tiny amount of code and it does run in less time than it takes to
>>>recompile C-Kermit.
>
>Nope. Your *assembly language* program will not run on a single one of my
>non-DOS-based 80x86 systems. But C-kermit will. And it runs at full 80386
>speed instead of having every third instruction juggling segment registers,
>so you don't even have the excuse that your hacked 8086 code is faster.

You really don't know what you're talking about here :-).  The registers
aren't juggled hardly at all, and the same amount goes on regardless of
who generates the code.  On the contrary, the '386 protect mode is where the
most register juggling goes on, but in each case it's mostly initialization.
Who cares if code written for one O/S does/does not run on another one.  When
more than a few egocentric usenet types are using your code, then you can
criticize what goes on.  In the mean time, most of these machines are *not*
being used for what you imaginge they are used for.

>
>>	I suspect that what he is running is various unix implementations on
>>those Intel processors which he listed, and I suspect that you need more
>>than just the tweaks described above to make it work with the unix
>>filesystem and system calls in place of the MS-DOS/OS-2 versions.
>
>And I suspect that it will be a lot easier to get Ckermit running under
>OS/2 instead of in the DOS compatibility box than to get your assembly
>language version that includes (and probably interacts intimitely with)
>its own device driver.

In a word, yes.  Working well? NO!  If you know what you're doing, you
can talk to the OS/2 driver in ways that C generally is ignorant of.  There
is already an OS/2-specific Kermit variant out that is doing this.  Eventually
it will be combined in with the MS-DOS version for a dual-.EXE capability.
However, under IBM's OS/2 v2.0, Kermit seems to run fine, although it sucks
under windows.  (In fact *everything* sucks under windows :-(.)

cjl
From: app@shamash.cdc.com ( GSD Advanced Packing/Processes)
Newsgroups: alt.folklore.computers
Subject: Re: Thoughts
Date: 15 Sep 92 17:41:33 GMT
Organization: Control Data, Arden Hills, MN

In article <7318@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <1992Sep14.191821.5712@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) 
> > "Joseph M. Newcomer" <jn11+@andrew.cmu.edu>, said:
> >     Yes, Beechwood Boulevard connects to Forbes Avenue in three places
> > On the other hand, there are two intersections of Beechwood and
> > Foreword.  And Monitor St has both ends on Beechwood and crosses it in
> > between.
>I think it is time for a Postscript map of Pittsburg for all of us that
>never have been there.

For the most part, a good description of the roads in Pittsburgh can
be found in the classic Adventure game, to wit:
    "You're in a twisty maze with all passages different"

(But I grew up on the Midwest, and was warped by graduate school at
CMU)
Steve "Pittsburgh has too many hills, trees and people" Axdal
Computing Devices International
Minneapolis Minnesota
app@shamash.cdc.com
From: csuley@cs.cornell.edu (Christopher Suley)
Newsgroups: alt.folklore.computers
Subject: Re: GOTOs
Date: 11 Sep 92 01:05:58 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

Couldn't it be argued that object-oriented programming has reintroduced
this 'GOTO problem' in a much more insidious form?

If you are reading a page of code that defines a method within an object,
can you know how control reaches that point?  If the method is inherited
or overridden, the problem becomes that much worse... trying to figure
out when the superclass's method will be called, when it won't, etc.

Or do I not understand OOP well enough yet? (A distinct possibility)

PS: does this belong on alt.folklore.computers?  Maybe comp.programming
    or something?
From: jrg@doc.ic.ac.uk (James Grinter)
Newsgroups: alt.folklore.computers
Subject: Re: "GOTO-less" BASIC
Date: 5 Sep 92 18:20:16 GMT
Organization: Apple Haters synonymous, Department of Computing, IC, London
NNTP-Posting-Host: crane.doc.ic.ac.uk
In-reply-to: millernw@craft.camp.clarkson.edu's message of 3 Sep 92 20:06:22 GMT

In article <millernw.715550782@craft.camp.clarkson.edu> millernw@craft.camp.clarkson.edu (Neal Miller) writes:

	   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

Strange that. We were always told that you could have a GOTO to jump
forward in your code, though not backwards, because then you should
have used a loop construct. Our BASIC had REPEAT.. UNTIL tho'.

   But I *could* use:

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

That is of course perfectly reasonable, its the BASIC equiv of a CASE.

James.

--
James Grinter,                              Dept of Computing, Imperial College
jrg@doc.ic.ac.uk or jgrinter@nyx.cs.du.edu   180, Queen's Gate, LONDON SW7 2BZ
                                             "If it ain't broke, don't fix it!"
Newsgroups: alt.folklore.computers
From: aduell@nyx.cs.du.edu (Tony Duell)
Subject: Re: Renumbering BASIC programs (was Re: Branching in HLL vs. Ass
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Sun, 6 Sep 92 16:15:14 GMT


Actually, TRS-DOS 2.3 for the model 1 had a second version of BASIC on the
disk called BASICR/CMD. It had a Renumber command, called NAME (I think
the keyword was in the level 2 ROMS for some reasn and never used). 
-tony ' PDP11 Hacker' Duell
ard@siva.bris.ac.uk


Newsgroups: alt.folklore.computers
From: dpbsmith@world.std.com (Daniel P. B. Smith)
Subject: So who WAS Mel, the real programmer?
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 14 Sep 1992 23:58:05 GMT

So who _WAS_ Mel, the real programmer? I'm assuming the story referred
to is the same one reprinted in "The New Hacker's Dictionary," which does
not identify him other than by first name.


-- 
Daniel P. B. Smith
dpbsmith@world.std.com
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Is there a PDP-11 (or 8, or...) Emulator?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 8 Sep 1992 09:55:30 GMT

In article <SX0JS26@taronga.com> peter@taronga.com (Peter da Silva) writes:
>In article <1992Sep4.051450.22555@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>I know of several PDP-8 emulators for PC's and MACs in various stages of
>>functionality.  At least one is intended to be a "real" emulator meaning that
>>the code will be written in assembler to maximize emulation speed, and
>>more importantly will be a "complete" emulation, not merely a CPU-only thing,
>>so that the actual system software will run on it.
>
>Let's see. Assembler for speed, eh?

Yes, since the C model seems to be running too much slower than assembler
will to make it more than an academic toy.

>
>If it's for the Mac, that means it will never run on but a small fraction of
>the machines out there.

The authors don't care.

>
>If it's for the PC, that means it'll run in a PC emulation box on most
>machines within a few years, so the "non-real" versions in high level
>languages will be faster.

When/if that comes, it's still available.  The rest is conjecture.

>
>Putting the instruction set decoder in assembly makes some sense, if you don't
>know how to write fast code in C. It's hard to do an interpreter in C that's
>at all fast (not impossible, by any means, just hard). But the rest of the
>code is unlikley to get a significant speedup.

The peripheral code is in C already, and likely will stay that way, since it's
not speed-important.  The instruction decode is done by table lookup; there is
no faster way.

cjl
Newsgroups: alt.folklore.computers,alt.religion.computers
From: jfritz@ptolemy0.rdrc.rpi.edu (Joe Fritz)
Subject: Re: Good source code to read?
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Sun, 13 Sep 1992 20:15:21 GMT

In article <NEERI.92Sep1135904@iis.ethz.ch> neeri@iis.ethz.ch (Matthias Neeracher) writes:
>In article <1992Aug31.162303.4148@ibr.cs.tu-bs.de> duening@ibr.cs.tu-bs.de (Lars Duening) writes:
>>I'd like to add that the importance of turing machines come from two facts:
>>first it's possible to build Universal Turing Machines which are capable
>                        ^^^^^ mathematically define
>
>>to emulate every other Turing Machine (even themselves),
>
>>and second, up to
>>today nobody found proof that modern computers aren't just sophisticated
>>turing machines.
>
>They are *memory limited* turning machines, actually.
>
>Matthias

Thus the halting problem *can* be solved on any real machine.  (In
astronomical time, of course.)

Let the "complete state" of the machine by the entire contects on the
tape, the current internal state, and the lication of the tape head.
If a machine is in the same complete state as it was before, it is in
an endless loop, and thus will not halt.  There is a finite number of
complete states, n.  After n+1 intrsuctions, the machine will either
have halted, or, by the pigeon hole princal, it must be in a state it
already was in, and thus it will never halt. QED.

-- 
May God keep and bless you always   | jochen (joe) fritz
And may all your dreams come true   | jfritz@rdrc.rpi.edu   <><
May you always do for others        -----------------------------
And let others do for you.  -- "forever young"  --Dylan
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: Sun, 6 Sep 1992 12:54:12 GMT

In article <1992Sep5.022817.19437@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
>In article <1992Sep3.091928.22081@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>In article <id.7MVS.5EK@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>>>In article <1992Aug31.162630.23913@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>>> 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 guarantee you it won't run on *any* of my 80286 or 80386 or 80486
>>>systems.

>>>But Ckermit will.

>>Totally incorrect; just setup the descriptor tables and change the directives
>>and a tiny amount of code and it does run in less time than it takes to
>>recompile C-Kermit.

Nope. Your *assembly language* program will not run on a single one of my
non-DOS-based 80x86 systems. But C-kermit will. And it runs at full 80386
speed instead of having every third instruction juggling segment registers,
so you don't even have the excuse that your hacked 8086 code is faster.

>	I suspect that what he is running is various unix implementations on
>those Intel processors which he listed, and I suspect that you need more
>than just the tweaks described above to make it work with the unix
>filesystem and system calls in place of the MS-DOS/OS-2 versions.

And I suspect that it will be a lot easier to get Ckermit running under
OS/2 instead of in the DOS compatibility box than to get your assembly
language version that includes (and probably interacts intimitely with)
its own device driver.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
From: Geoff@equinox.gen.nz (Geoff Mccaughan)
Newsgroups: alt.folklore.computers
Subject: Re: The third variable.
Date: 15 Sep 92 21:36:55 +1200
Organization: Equinox Networks
X-Newsreader: Tin 1.1 PL5

Jeff Weisberg (weisberg@ee.rochester.edu) wrote:
>/* 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"

Around this part of the world it's "blarg" then "wibble".

--
Geoff, Sysop Equinox (equinox.gen.nz) +64 (3) 3854406 [4 Lines]
                               Voice: +64 (3) 3852101
        "Hi. You have just entered the fourth dimension. Small isn't it?"
Newsgroups: alt.folklore.computers,comp.unix.misc