HDTenEightyP/NetNews huggingface dataset:
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: 4 Sep 92 04:27:04 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <1992Sep01.163246.19563@yarc.uucp> scott@yarc.UUCP (Scott Beckstead) writes:
>  Look CJL we're talking about porting to DIFFERENT processors not 20 
>year old 8080 emulators that ALL run the same code!  Try taking Dr. Dos to 
>a 68000 or maybe a MIPS or a 29000.  Get real dude! Keep your apples and 
>oranges straight!

You apparently belong to a different "we" group.  The response was directly
towards a remark claiming that there were serious programming development
problems or vast differences between several of all of those models.  I
refuted that, and gave a little detail as to why.

You show your ignorance if you believe that any of those machines are 8080
emulators.  Further, none of them are 20 years old.  However there is an
8088 and up program to emulate not only the 20 year old 8080, but the CP/M
environment it requires to run specific programs on.  In any case, why would
anyone make any claims of running anything from a PC on totally different
architectures; you get real!

The non-portability of code to incompatible architectures is well known and
usually an acceptable tradeoff to writers of assembly code.  The previous
poster was attempting to take a pile of nits and claim incompatibility as
opposed to a readily adaptible situation it actually is.

The ability to "port" techniques from one architecture to another is part of
the repertoire of any good assembly programmer.  Ideas and techniques are not
machine-dependent.

cjl
From: kcj@dptspd.sat.datapoint.com (Kevin Jones)
Newsgroups: alt.folklore.computers
Subject: Re: DataPoint (Was: Non Unix-OS's)
Date: 27 Aug 92 23:06:52 GMT
Organization: Datapoint Corporation, San Antonio, TX

We're still here and doing much better than some of our former competitors.  By the way,  RMSXA is to UNIX as UNIX is to TRS80-DOS.  Thats the only relationshipbetween the two that readily comes to mind.
Newsgroups: alt.folklore.computers
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Subject: Re: Longtime PDP-11 users, tune in now
News-Software: VAX/VMS VNEWS 1.41    
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
Date: Fri, 28 Aug 1992 23:17:00 GMT

In article <l9t0gjINNjon@exodus.Eng.Sun.COM>, linden@positive.Eng.Sun.COM (Peter van der Linden) writes...
>Has it ever struck you as strange that the output file
>from compiling any C file goes into "a.out"?
>...
>Are there any longtime PDP-11 users who can remember details like
>this about its assembler?  Is there any basis to my theory?
>Maybe it even came from the PDP-7 implementation of C?

	I worked with assemblers on the 11 for DOS (yes, single user disk
	operaing system,) RSX11D/IAS, RSX11M, early RT11, but never had any
	assembler default to A.OUT. 

	Definitely sounds like something from the same group that brought
	you Biff, Awk, Grep, and other terminology that looks like it was
	run thru ROT-13.

   Frank R. Borger - Physicist    __       Internet:  Frank@rover.uchicago.edu
Michael Reese - Univ. of Chicago |___      Phone : 312-791-8075 fax : 567-7455
  Center for Radiation Therapy   | |_) _   There is but one way for a newspaper-
    2929 South Ellis Avenue        | \|_)  man to look at a politician and that
    Chicago, Illinois 60616           |_)  is down. - Frank H. Simonds
From: ddb@tdkt.kksys.com (David Dyer-Bennet)
Sender: FredGate@tdkt.kksys.com
Newsgroups: alt.folklore.computers
Subject: Flash Pictures Of The Sunset
Date: Wed, 26 Aug 1992 21:37:14 -0600

 CEB> The cameras are simpler than you
 CEB> imagine.  They are set up so that if there
 CEB> isn't enough light for the picture, the camera does the flash itself. 
The
 CEB> users have no choice whether the flash goes off or not.  If you're going
to
 CEB> sneer at someone for his/her stupidity,
 CEB> sneer at people who work at removing
 CEB> choice from other people's lives.

Like those who design cameras where you can't override the flash.

Or cameras who don't correlate the exposure with the autofocus system and
realize that it's hopeless.

 * Origin: This tagline not to be removed under penalty of law (1:282/341.0)
Newsgroups: alt.folklore.computers
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: CyC project
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Fri, 28 Aug 1992 01:25:28 GMT

jimf@centerline.com (Jim Frost) writes:

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

I own property, and I fork all the time...

-- 
Paul Tomblin, pt@geovision.gvc.com or {uunet,revcan}!geovision!pt
(This is not an official opinion of GeoVision Systems Inc.)
"Beebelbrox, over here!" "No, Beebelbrox over here, who you?"
"A friend." "Anybody's friend in particular, or just well disposed to people?"
Newsgroups: alt.folklore.computers
From: aduell@nyx.cs.du.edu (Tony Duell)
Subject: Re: Computers killing people?  (WAS Re: 9 track data storage???)
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, 23 Aug 92 20:59:12 GMT


Actually there is one unexpected place that a PC can load it's program
from, at least if it's an original IBM (I'm not sure how many clone do
this), and that's the _keyboard_
Looking at the XT Bios source, it appears that during the keyboard part of
the POST, if the keyboard fails, it checks if it is a diagnostic tester.
(Which appears to be some IBM test unit that connects to the keyboard port
and sends a particular byte after being reset, different from the one a
keyboard would send). If it finds that a diagnostic tester is plugged into
the keyboard port, it reads 2 bytes from it, which give the length of the
program. It then reads that number of bytes from the keyboard port, and
stuffs them in memory at some constant address. After loading the complete
program, it jumps to the first byte that it has loaded.
This is done early in the POST, before any extension ROMS have been
checked for. 
-tony 'PDP11 Hacker' Duell
ard@siva.bris.ac.uk

Newsgroups: alt.folklore.computers
From: phillips@swanee.ee.uwa.oz.au (Christopher Phillips)
Subject: Re: Indentation
Organization: Elec Eng, Univ of Western Australia
Date:  1 Sep 92 04:16:49 GMT

rh@smds.com (Richard Harter) writes:

>I do wonder though.  Why is it nicer to have a cursor flickering
>back and forth than simply seeing the block structure in front of
>you?  To my way of thinking blocks that stretch across more than
>one page are a pain regardless of how they are delimited -- and
>if blocks are within one page I can see them.

I agree.  Any procedure that has grown beyond a page or so begins to become
unmanageable;  I tend to rip large chunks out of the insides of loops
an turn them into separate procedures.  nonon! I hear people scream;
what of all the overheads of procedure calls etc???  Admittedly there
arn't that many comercial compilers out there yet that are clever enough
to realise that the procedure so created is only called from one point and
inline it, but the improvement in comprehensibility obtained makes
development, debugging, maintainance etc _so_ much saner!

If your _really- desparate for speed, write in assem...

--
Christopher Jam	__________________________________________________
'Another day, another try.  But remember, SHOOT OR DIE!' -turrican
phillips@swanee.ee.uwa.oz.au		c64 forever!!!!
------------------------------------------------------------------
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: Thu, 27 Aug 1992 19:50:16 GMT

neeri@iis.ethz.ch (Matthias Neeracher) writes:
>In article <1992Aug27.075325.16635@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>In article <NEERI.92Aug26154345@iis.ethz.ch> neeri@iis.ethz.ch (Matthias Neeracher) writes:
>>>>The test for the condition is 
>>>>whether it's possible to transfer out of a loop, and then go back in with
>>>>out losing any context,
[...]
>The
>only HLLs I know that allow jumping back into loops are Fortran and some BASIC
>dialects (I don't know PL/I, nor do I have a real desire to know). The BASIC
>solution leaves the stack in a mess, while Fortran merely leaves the
>Programmer's mind in a mess.

C allows you to do it too, so long as you stay within the scope of the
iteration variable.  Most C compilers will even react predictably if
you jump *outside* of the scope of the iteration variable because they
do not reuse stack space for equivalent depth scopes within the same
function, but I wouldn't recommend doing this.

In fact, lots of unexpected things are legal with C.  Among the
ones I've seen in actual code:

	if (some_test)
	  goto inside_of_switch;
	/* ... */
	switch (var) {
	case X:
	inside_of_switch:
	  /* ... */
	}

and:

	if (some_test)
	  goto error_condition;

	/* ... */

	if (some_other_test) {
	error_condition:
	  /* handle the error */
	}

I was amazed that anyone ever wrote code like that and even more
amazed that so many compilers accepted it (in fact, I haven't seen one
yet that *doesn't* accept these kinds of constructs).

In C you can have your abstraction and eat it too.  Whether or not
this is desirable is another thing entirely.

>In neither language have I seen a convincing
>reason to allow jumping into loops. 

I have to agree wholeheartedly with this statement.

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 29 Aug 92 10:42:46 GMT
Distribution: world
Organization: The Wolery

ivie@cc.usu.edu (CP/M lives!) writes:
> Don't know about anyone else, but I keep getting quite upset at big machines
> like the VAX that can handle nice big addresses but keep giving me rinky-dink
> 8-bit signed conditional branch offsets so that I have to keep branching
> around an unconditional jump in order to get a long conditional branch.

That's one of my gripes with the VAX (that and the difficult-to-pipeline
opcode/operands*).  It looks like the pdp11's conditional branches, _but_
the byte offset on the pdp11 referred to +127 or -128 *words*, not bytes.
To make things worse, VAX instructions are (on the whole) bigger than the
pdp11 equivalents (three bytes vs two for MOV Rn,Rx, bigger differences 
as word or longword literals start getting involved).  

Most of us who like programming "on the metal" of a VAX have a set of macros
along the lines of:

		.macro bleqw, destination, ?skip
		bgtr skip
		brw destination
	skip:	.endm

'course this buggers up the pipelining, because you _always_ have to branch.

There's been a discussion on this in vmsnet.internals lately.


* When one pulls the VAX architecture apart and finds out just what a pig
it is to pipeline, one really comes to respect what the engineers who 
designed the NVAX chip did -- 24 mips/vups/whatever on a 75MHz clock is
quite impressive, when you compare 0.9mips on a 78032 (MicroVAX II) chip
ticking over at 25MHz.... 
 
--
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
From: parry@yoyo.cc.monash.edu.au (Tom J Parry)
Subject: Re: You know when you're hacking too long
Originator: parry@yoyo.cc.monash.edu.au
Organization: Monash University, Melb., Australia.
Date: Thu, 27 Aug 1992 13:05:02 GMT

Jeremy Lawrence (jeremy@snrc.uow.edu.au) wrote:
> 
> New Zealand MacDs have a vegetarian burger on the menu. Why anyone
> interested in healty food would eat at MacDs is beyond me, though.

Many people eat vegetarian for moral reasons, not health.

-- 
Tom J Parry.
Your reality is a figment of my imagination.
From: Charlie_Gibbs@mindlink.bc.ca (Charlie Gibbs)
Newsgroups: alt.folklore.computers
Subject: Re: Better dead than IBM
Date: 28 Aug 92 16:44:30 GMT
Organization: MIND LINK! - British Columbia, Canada

<sigh>  I guess it's time to repost the whole list...

I Became Macintosh
I Been hipMotized
I Beg Mercy
I Believe in Marketing
I Blame Microsoft
I Bought a Macintosh
I Built a Macintosh
Icky Blue Machines
Idiotic Bull Meter
Idiots Become Managers
Idiots' Bewilderment Machines
Idiots Bought Me
Idiots, Bumblers, and Morons
Idolized By Morons
Illustrative of Bad Marketing
I'm Being Mobbedwithwhatdoesibmstandforanswers
I'm Being Moved
I'm Buying a Macintosh
Imitation Burroughs Machine
Immense Bins of Money
Immense Blue Monolith
Immense Blue Mountain
Immense Bowel Movement
Immense Bucket of Manure
Imperialism By Marketing
Impractical, But Marketable
In a Befuddled Manner
In Bleakest Mordor
In Business for Money
Incest Breeds Morons
Incompatible Business Machines
Incontinent Bowel Movement
Increasingly Becoming Moot
Incredible Bunch of Muffinheads
Incredible Bundles of Money
Incredibly Big Machine
Incredibly Big Monopoly
Incredibly Boring Machine
Incredibly Brilliant Marketing
Industry's Biggest Mistake
Inefficient But Marketable
Inept Bull Meter
Inert Blue Monoliths
Inferior But Marketable
Inherently Bogus Measurements
Insert Bug under Mask
Insidious Black Magic
Insipid Brainless Monster
Insolence Breeds Mediocrity
Installed By Masochists
Installed My Mistake
Institute of Broken Minds
Institute of Black Magic
Integrated Bad Manners
Intelligent Bull Meter
Intensely Boring Machines
Interactive Boot Machines
Intercourse Beats Masturbation
Intergalactic Brotherhood of Muthaf**kas
Internal Bowel Movement
Internal Bureaucratic Mess
International Ballistic Missiles
International Big Mother
International Big Mouth
International Brotherhood of Magicians
International Bureaucracy Merchants
International Business Machines
International Business Manipulators
Intrepid Bureaucratic Madness
Involuntary Bowel Movement
Iron Behemoth Makers
Iron Brain Masters
Italian Branch of the Mafia
Italian Business Men
It Beats Mattel
It's a Big Machine
It's a Blue Monolith
It's Backwards, Man
It's Been Malfunctioning
It's Being Mended
It's Better Manually
It's Big Money
It's Black Magic
It's Blue Magic
It's Boring Me
It's Broken, Mommy
It's Busted, Man
Itty Bitty Machines
Itty Bitty Manuals
Itty Bitty Minds
Itty Bitty Monopoly
Itty Bitty Morons
I've Been Misled
I've Been Molested
I've Been Moved
I've Been Mugged

IBM PC:  I've Blown My Power Circuits.
         Intel Bowel Movement / Piece of Crap

PS/2: a Piece of Shit Too

IBM, UBM, we all BM for IBM.

Charlie_Gibbs@mindlink.bc.ca
"Intel Inside" - isn't that a warning sticker?
Newsgroups: alt.folklore.computers
From: ChazL@county.lmt.mn.org (Chaz Larson)
Subject: Re: Better dead than IBM
Reply-To: ChazL@county.lmt.mn.org (Chaz Larson)
Organization: LaserMaster Corporation
Date: Fri, 28 Aug 92 22:50:51 GMT

>The One True Expansion of IBM is "I'll Buy Macintosh."

In light of the success of Windows, I've heard this as:

"I'm Becoming Macintosh"

chaz

--

..must think...bubble pipe will relax me and I think...
Newsgroups: alt.folklore.computers,comp.unix.misc
From: joet@dcatlas.dot.gov (Joe Trott)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: U.S Dept. of Transportation
Date: Thu, 27 Aug 1992 13:38:35 GMT


I've been following this flamefest with some interest; I'm one of those who
realize that the more I know, the more useful/competent I can be.  I've
learned a lot, but nothing as much as how much further I have to go.

I am not a programmer; at least not in any terms that would not cause
someone who truly _is_ a programmer to scoff.  I know less than five
languages (someone asked that question...).  I started with BASIC, then
did some Fortran, and now do most of my stuff in Pascal.  I've dabbled _ever_
_so_slightly_ with C.  I've done some bug fixing/minor mods in COBOL, but
do not claim to know the language.  I've never used assembler.  I used to
be accomplished with my old TI-59.  I recall that after learning Pascal
(*excellently* taught _along_with_structured_programming_ at Georgia
Tech by a professor Goda), I wrote a 640-step program on it with no GTOs.
I know you can do a GOTO in Pascal, but I'm not quite sure how to do it and
I never have.

I am a "user support specialist".  That probably gives some of you the shakes.
Oh well.  In support of specific requirements (sometimes my own), occasionally
I write programs.  I've even done a few small applications.  Almost all of this
I have done while in the midst of the user support circus.

In that context (which I think of as "interrupt driven"), I have never once
considered even remotely the possibility of using assembler.  Nor would I
care for anything cryptic like MUMPS (now *there's* a disease...) or eye-
bending like LISP.  Such languages, assembler in particular, require far
too much *continuous* dedication/concentration to be viable for someone like
me.  One the other hand, I can leave and return to a Pascal project many
times over the course of a day without losing lots of time figuring out
where I was when I left off.  The same is true for database programming,
like Rbase or (better,) Paradox.

The point being, as you argue over which language (or _type_ of language)
to use, in addition to considering the project and the competence of the
programmer(s) and software engineers, I think you will find it useful to
consider the _environment_ in which the development is being done.

My $.02; perhaps several times over...

-JTT
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Thu, 3 Sep 1992 02:53:50 GMT
Organization: University of Auckland, New Zealand.

exuhag@exu.ericsson.se (James Hague) writes:

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

It will be interesting to see wether these also suffer the "Wing
Commander" syndrome. This game, apart from being sloooow on slow
hardware, is really too fast to be played on a fast 486. It is a real
pity that OS-9 did not become the standard desktop OS; apart from
surpassing MS-DOS in every respect in functionality (multitasking,
pipes, runtime loadable device drivers, semaphores), it is also a
realtime operating system, ideal for writing games under :-)

And yes, OS-9 is written in assembler with versions for the 6809 and
68k. However, its newer, redesigned version OS-9000 is written almost
entirely in C for easier portability and mainainability and runs both on
68k and 80x86 :-)
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Newsgroups: alt.folklore.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: The need for an assembler (was: Favori
Organization: CenterLine Software, Inc.
Date: Wed, 26 Aug 1992 14:37:46 GMT

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <1992Aug21.203610.20593@ttinews.tti.com> hollombe@polymath.tti.com (The Polymath) writes:
>>And, once you've figured out these "best" methods for basic procedures,
>>you program them into a compiler so even ignorant hll programmers can
>>use them.

>That presupposes that they can be translated, which isn't always the case.

All it means is the compiler has to figure out what the user meant
given what he said.  There are a number of compilers on the market
which recognize algorithms for the standard benchmarks and emit
hand-coded versions, for instance (I know of two compilers which do
this for the dhrystone test).

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
From: bmb1021@ultb.isc.rit.edu (B.M. Buck )
Subject: Is there a PDP-11 (or 8, or...) Emulator?
Originator: bmb1021@ultb
Organization: Rochester Institute of Technology
Date: Wed, 2 Sep 1992 04:34:15 GMT

Is there a PDP-11 (or PDP-8, 10, 1, 6, etc) emulator available
(perferrably for MS-DOS or similar varients)?  While recently reading a
book on PDP-11 Assembly language, I wondered if it would be possible to
try writing some code for the beasties.  Not having a PDP-11, or even
knowing where to get one, I thought of emulation...

Also suitable would be pointers on how to acquire one cheaply.

  Thank you for your support.
    BP (bmb1021@ultb.isc.rit.edu)



Newsgroups: alt.folklore.computers
From: bmarcum@world.std.com (Bill Marcum)
Subject: Re: Flash pix
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 30 Aug 1992 19:45:33 GMT

In article <1992Aug28.082723.1@bronco.fnal.gov> colombo@bronco.fnal.gov (Rick Colombo - Fermilab) writes:
>
>So this EPROM was sitting on top of the computer mugging for the camera?
>Sounds like real folklore to me, but at least it's in the appropriate place.
>I've seen EPROMs erased, they use UV light and set the timer for 15 minutes.
>
The 15 minute time guarantees that every single bit in the EPROM will be
erased, but a computer program can be ruined by changing just one bit.

Bill Marcum  bmarcum@world.std.com


Newsgroups: alt.folklore.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: The need for an assembler
Organization: CenterLine Software, Inc.
Date: Fri, 28 Aug 1992 19:45:05 GMT

gls@windmill.ATT.COM (Col. G. L. Sicherman) writes:
>Do we really *need* an assembler?

Oh yea.  There really are some things that you cannot do any other
way, or that must perform optimally.  Consider the context switcher in
an OS, for instance.

I'm generally an HLL advocate because you can get more done faster and
with fewer bugs, but there's no way I'd give up my assembler
completely -- when you need it, you need it bad.

>By the way, what's the strangest assembly language you've ever used?
>I'm not talking about instruction sets or registers, now; I mean the
>language itself.

For me it's probably the PA-RISC architecture.  The instructions are
formatted in surprising ways (an immediate is usually not contiguous
in the function, and even if it *is* contiguous it doesn't go in
either MSB or LSB order).  It's a segmented architecture, more or
less: normally a 32-bit address includes the segment register number
but some instructions ignore those bits.

If the assembly weren't bad enough, calling between functions can be a
bit baroque.  The actual calling conventions are a pretty standard
callee-saved deal, but the branch instruction doesn't have enough
range so the linker writes down "export stubs" which are trampoline
functions.  Since lots of arguments are passed in registers and a
misdeclared function can put the arguments in the "wrong" registers,
the linker writes down "parameter relocation stubs" that move
arguments between registers as necessary.  And there are "import
stubs" used to set a data pointer register when calling into or
between shared libraries.

If that weren't confusing enough, there are about two hundred fifty
relocations that fall into about thirty categories, and four modes
that cause variations in how many of the relocations work.

jim frost
jimf@centerline.com