HDTenEightyP/NetNews huggingface dataset:
From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 27 Aug 1992 17:03:24 GMT

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

>In article <9224002.2167@mulga.cs.mu.OZ.AU> fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>
>>It's been said before, but I'll say it again: ANYTHING that an assembly
>>language programmer can do, a compiler can do to, and probably does
>>already. If it doesn't yet, it may well do so tommorrow, and you only
>>have to improve the compiler ONCE and it will keep optimizing your
>>programs as long as you keep writing them.
>
>Yes, it was said before, and it's still just as wrong now as then.

I maintain that ANY given assembler "trick" CAN be built into a compiler.
If it is seriously worthwhile, then it WILL be.

>Only someone who has never used the items discussed throughout this thread
>that never get translated would defend such a statement.

This is known as "attacking the man, not the argument".
If you disagree with my argument, then state your reasons, don't
simply insult those who disagree.

-- 
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!
-- 
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: phillips@swanee.ee.uwa.oz.au (Christopher Phillips)
Subject: Re: Indentation
Organization: Elec Eng, Univ of Western Australia
Date:  2 Sep 92 06:15:32 GMT

don@zl2tnm.gen.nz (Don Stokes) writes:

>Sod the call overhead.  How about making the thing readable?

>My favourite counterexample to the "procedurise everything" crowd had code
>along the lines of:

<deliberately obfuscated code deleted>

>... several pages apart, of course.  Made trying to follow what the blazes 
>was going on a real bear.

>Personally, I find that chunks of related code should stay together, not
>be distributed throughout the program.  I much prefer to be able to follow
>through the details when debugging.

I don't disagree with you here.  I am not saying everything should be
procedurised, not that all procedures longer than 50 lines should be
artificially split.

However, where a clean functional split can be made, it is better to
have two neighbouring procedures than one monolithic.  Recent case in
point:  
The raytracer I am writing (yes, yet another...) uses a techinique
similar to fractint's solid guessing to reduce the number of rays traced.
The scheme used has a relatively complex looping algorithm (passes forward
and backwards through gradually refined grids, every second refinement at 45 
degrees), in the middle of which are some strange tests and neighbour 
averagings and things.  Rather than have half a dozen odd levels of nesting,
I moved all the inner junk to a procedure called ProcessPixel.

The functionality of both routines is obvious, and there are fewer
sets of coordinates and things to keep track of in either than there
otherwise would be.  One is immediately below the other in the source,
not 'distributed throughout the program'

>Actually, I often find an assembly dump of a misbehaving program useful
>(assuming I know the assembly language of the machine I'm debugging on); it
>can reveal errors in assumptions about things that have been hidden by all
>the unnecessary abstraction in modern languages.... 

I do more than half my coding in 6502 assembly language.  Reason is speed:
only way to get it on a c64.  The algorithm I mentioned above was developed
on a c64 in 6502 assem for doing fast mandlebrots.  13 seconds for
64x128 zoomed by 4.
--
Christopher Jam	__________________________________________________
phillips@swanee.ee.uwa.oz.au			c64 forever!!!!
300,000 c64's were sold in the fiscal year ending June 1991 :)
------------------------------------------------------------------
Newsgroups: alt.folklore.computers
From: whit@milton.u.washington.edu (John Whitmore)
Subject: Re: Flash pix
Organization: University of Washington, Seattle
Date: Wed, 2 Sep 1992 06:23:01 GMT

In article <1992Aug28.151517.12100@EE.Surrey.Ac.UK> D.Banks@ee.surrey.ac.uk (Danny Banks) writes:
>In article <1992Aug28.082723.1@bronco.fnal.gov>, colombo@bronco.fnal.gov (Rick Colombo - Fermilab) writes:

	<about photo flash erasing an EPROM>

>|> 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 be "erased" by a photo-flash, too. These had printed paper
>lables stuck over their windows (cheap, and they were going into cabinets
>anyway).
>PS. I've also seen "flash" UV erasers advertised recently .....

	While the specifications on EPROMs assume that they will be
illuminated by a mercury vapor lamp (2450 angstrom line), a photographic
flash (typically Xe vapor) delivers quite enough UV to be troublesome.
My old Vivitar Speedlight 44 (guide number 44 for ASA 32 film) was
originally (1968 vintage) supplied with a clear lamp.  I amused myself
triggering it against plaster, and watching the wall glow for a
few seconds after... until the lamp burned out.

	The replacement unit was yellow-tinted (had a UV filter
integrated into the tube), and wasn't nearly so much fun.
This was a rather powerful little beast; with a fast lens and
good color film, it would allow exposures at 100 yards distance.
Professionals undoubtedly had more watt-seconds available...

	John Whitmore

Newsgroups: alt.folklore.computers
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: Fri, 4 Sep 1992 05:35:02 GMT

In article <6422@vtserf.cc.vt.edu> valdis@vttcf.cc.vt.edu (Valdis Kletnieks) writes:
>
>I've been in this boat before - I wrote a program for a Zenith Z-100
>to do instrumentation for a research project that involved irradiating
>memory chips and quantifying the results.  Lots of ugly assembler
>code doing lots of very slick things. Worked fine when designed
>for the 64K DRAMs that were available at the time.  On the other hand,
>I just about fainted when I was told "OK, now re-do it for these shiny
>new 256K chips we just got samples of".  If I had been working in C,
>I'd had to have just changed a #define.  As it was, I ended up spending
>the better part of 2 weeks fighting around the brain-dead segment
>architecture of the 8088.

And in assembler I would have changed a few equates that control the
"geometry" of the problem.  If you are ignorant of the sizes of DRAMs
that exist, then you weren't fully qualified to write the program regardless
of language.  Do you seriously expect that one size out of the many available
was the only value that would ever be chosen?  You are equating your
current experience benefiting from hindsight with the problems of assembler.

All of us can't always anticipate where a program's requirements might 
migrate to, but that's not a language issue per se, just a universal
design problem.

I have written code that was for one specific case, that later got
conditionalized into a more generalized situation.  The code got modified
somewhat, but not seriously.  I have also created control parameters to
allow all sorts of flexible options that were never needed.  You can't win
them all.

cjl
Newsgroups: alt.folklore.computers
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: Wed, 26 Aug 1992 07:21:45 GMT

In article <1992Aug21.073815.15046@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>>Moreover, there is far too much modeling of code generation based on a model
>>using a stack.  While it is true that occasionally a stack structure is needed,
>>it often isn't.  Perhaps statistically speaking most of the time, yet most
>>code is generated (ab)using a stack.
>
>From the release notes of ftn 3.4, running on an SGI under IRIX 4.0.5
>(MIPS - architecture):
>
>       5.  Known_Problems_and_Workarounds
>[...]
>	o Compiling old	Fortran	code (SCR 3526)
>	  Fortran, by default, allocates local variables on the
>	  stack	for faster execution speed.  These local automatic
>		^^^^^^^^^^^^^^^^^^^^^^^^^^
>	  variables are	uninitialized, as opposed to being
>	  initialized to zeros,	which occurs using the static
>	  allocation of	older Fortran systems.	Also, the value	of
>	  an automatic variable	is not retained	between	successive
>	  calls	to a subroutine	as for a static	variable.
>[...]
>
>ABusing a stack?

Fortran need not allocate in the first place.  The program can be statically
loaded.  Only one DMA cycle per word to get it loaded. 

Statement stands.  Faster than what?  I can imagine some horrible methods
they could have used that using the stack is better than. :-).

cjl

Again, please don't take this to another newsgroup; keep it here.
Newsgroups: alt.folklore.computers
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Indentation
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Fri, 28 Aug 1992 00:17:57 GMT

In article <1992Aug27.174750.13997@bert.eecs.uic.edu>, artn@bert.eecs.uic.edu
(Ellyn Sandor) writes:

|>TS> Graphics computers have been shipping since 1976 (Apple II).
|>TS> Why are you all still programming completely in text?

|>	Interface builders have also gotten a lot of typing out of
|>programming for me.  _Forms Library_ for the SGI computers lets you
|>draw your user interface and rearrange it, and spits out C code for
|>compiling into your program.  You still have to write all the callback
|>routines, etc, etc, but the user interface can be built in minutes.
|>	In fact, it is sort of silly that most people working in
|>graphical environments (Mac, etc) still have to program the user interface
|>all in text.  After using Forms, I don't want to ever waste my time
|>changing code to move buttons, sliders, etc again.

Compare the advantages of a typesetting system such as TeX over a Wysiayg system
like the MAC. I have several custom algebras, fonts etc which are beyond the
reach of all but the very top end graphical tools. People keep saying things
like "but you can always do it by hand". This either involves use of a text mode
interface somewhere or placing the objects by hand - this is not a solution if
you are designing an algebra (hint you have just written 1000 equations and have
decided to use a superscript to denote something...).

We have a graphical user interface builder and a text mode one. The text mode
one is the only one that is in frequent use. The reason being that it is easy to
interface the text mode system to an AWK script and get everything done from the
code - no bugs! Theoreticaly we could then massage the stuff using the graphical
tool.


--

Phill Hallam-Baker
Newsgroups: alt.folklore.computers,comp.unix.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: peter@ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Date: Tue, 1 Sep 1992 16:36:56 GMT

In article <1992Aug31.162630.23913@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> This is patently wrong.  I write for the 8086/8088 model as do most people.

I see. You give up about a decimal order of magnitude in performance when
dealing with objects larger than 64K in a protected mode O/S so you can save
a factor of *maybe* 2 over C, for the compute-bound portion of your code only,
on MS-DOS.

> 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.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Xref: sparky alt.folklore.computers:13076 alt.religion.computers:552
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers,alt.religion.computers
Subject: Re: Good source code to read?
Date: 25 Aug 1992 20:03:35 -0400
Organization: Berkeley Software Design

In article <8629.Aug2522.20.1992@virtualnews.nyu.edu>
brnstnd@nyu.edu (D. J. Bernstein) writes:
>So what did you want, Vadim?

Separate flies from burgers :-) Well, back from the dry theory
to the greener practice...

>The interesting practical question is whether you can, with your
>compiler's help, detect loops in real programs without wasting too much
>*extra* time. The answer is yes.

Surely! And i think it can be a valuabe addition to the present
programming instrumentalia. I think the detection of exact loops
is not quite useful, cathching "long" loops (i.e. ones which
will theoretically end but not until tomorrow) is better :-)

It's interesting is there any practical value in the three-step
scheme? I used it once to determine the length of a cycle of a
random-number generator but have no idea of a different usage.

--vadim
Newsgroups: alt.folklore.computers
From: IQTI400@INDYCMS.IUPUI.EDU (macphil)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Organization: IUPUI
Date: Sat, 29 Aug 1992 02:48:52 GMT

In article <1992Aug28.221421.18061@ttinews.tti.com>
hollombe@polymath.tti.com (The Polymath) writes:
 
>
>I've written one (count 'em) one GOTO in the last 7 years.  I tried hard
>to avoid it, but someone else had done something stupid and a GOTO was the
>cleanest way to handle it.  I commented the heck out of it and the label
>it branched to (and apologized anyway).
 
Hence Plauguer's statement of "Never document bad code - rewrite it."
 
But this is why there is a comment in the current (rag) Information Week:
 
"IBM plans to spin off its PC hardware unit.  But to succeed, it must also
make dramatic changes in PC software."
 
and as the Chicago Tribune said in a recent review of a book about
Gates/Microsoft:  "about 3 in 2'000 people actually have the innate
required skills to be a good programmer".
 
there's no shortage of programmers...there's a shortage of GOOD programmers.
 
there's a shitload of people who took one or two classes (if that) in
computer programming and got a job.  unfortunately, these are the same
people who wrote a goodly sum of the software in many businesses and
as entry-level people who knew & understood the importance of
writing quality code (and not just because it came out of a textbook)
were leaving school they were given the task of maintaining the steaming
pile written by those before them rather than applying their skills
to the new projects.  And over time, these people become so accustomed
to writing poor code their habits change.
 
Writing "assembler style" code has its place -- in assembler.  When in
procedural languages...write cleanly.  It's said to see people
who were or are heavy & good assembler writers write code in a procedural
language.
 
There is a single test applying to most code in the industry:
 
If ProgramWorks
Then Great!
 
(fix the problem and move on...don't worry how it'll impact the future)
 
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: Mon, 31 Aug 1992 15:22:35 GMT

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>*ALL* compilers used to be smart, but the tendency today is to write "cheap"
>compilers.

You are out of your mind.  The tendency today is to write smarter
compilers than were possible given the restricted machine resources of
even a few years ago.  Don't you even look at the compilers you
criticize?

jim frost
jimf@centerline.com
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)
Keywords: Pascal
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Mon, 31 Aug 1992 06:07:58 GMT

In article <id.9EQS.FG5@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Aug26.080142.15930@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> If someone will go back and check, they will find that this whole thing
>> started because some people wanted to have us believe that hll-exclusivity
>> was the only way to go.  I challenged that, and never said that all projects
>> should be done all-assembler, [...]
>
>You sure *seem* to be saying that. You sure *seem* to be advocating coding
>in assembly as a first choice. If you're not, you need to tone things down
>a little.

What you just said is different from what I said.  When you consider an
application, there is no such thing as a first choice.  *All* languages
available are considered, then a decision is made as to what is the
*best* choice to implement it in, possibly followed by runner-ups, etc.

Perhaps with experience, we tend to rule out some choices, but don't twist
what I said: the point I am making is that assembler is underutilized meaning
should have been used in some places but wasn't for reasons outside of the
technical merits.  Too much of this kind of thinking makes it get used even
less for (technically speaking) all the wrong reasons.  Further, there is
apparently so much bias on this issue, that there are people with an
attitude that hll is a "panacea" which is ultimately ludicrous as various
posters (including you) indicate projects done in assembler at various times.
When you have to deal with bigots, you may appear to be one yourself.  Perhaps
some of this is what you are referring to.  (Not to imply that the entire
readership of a.f.c are all bigots. :-))

cjl
Newsgroups: alt.folklore.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: Renumbering BASIC programs (was Re: Branching in HLL vs. Assembler)
Organization: CenterLine Software, Inc.
Date: Thu, 3 Sep 1992 13:33:10 GMT

ttak@troi.cc.rochester.edu (Tim Takahashi) writes:
>>The second BASIC I used did not store the program in
>>ASCII, but rather in an undocumented tokenized form.  I think they provided
>>a RENUM command (but I don't remember).
>>
>>	Bonus:  guess the BASIC's.

>(2) Microsoft Basic (or a derivative thereof) - Altair 8k Basic, Radio Shack
>      Level II Basic, Applesoft Basic, etc. all used the tokenized form.

So did most other versions, such as the Atari and Commodore BASICs.
Even the IBM Datamaster BASIC was tokenized.  MS's BASIC derivatives
were certainly pervasive but they weren't the only ones who used
tokenization by any means.

I could see his BASIC being from the TRS 80 I or II (both of which had
RENUM if I remember right) but it certainly wasn't Applesoft; you
needed to load a special program to get renumbering under Applesoft
(and the renumbering program had some nasty bugs that would
occasionally trash your BASIC program).  I can't remember for sure but
I'm almost certain the CP/M MBASIC didn't have RENUM either.

Happy hacking,

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
Subject: Re: Indentation
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 1 Sep 92 10:35:16 GMT
Distribution: world
Organization: The Wolery

phillips@swanee.ee.uwa.oz.au (Christopher Phillips) writes:
> 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!

Sod the call overhead.  How about making the thing readable?

My favourite counterexample to the "procedurise everything" crowd had code
along the lines of:


	gosub clear_first_time_flag
	gosub set_first_part_flag
		.
		.
		.
clear_first_time_flag:
	first_time_flag = FALSE
	return
		.
		.
		.
set_first_part_flag:
	first_part_flag = TRUE
	return


... several pages apart, of course.  Made trying to follow what the blazes 
was going on a real bear.

Personally, I find that chunks of related code should stay together, not
be distributed throughout the program.  I much prefer to be able to follow
through the details when debugging.

Actually, I often find an assembly dump of a misbehaving program useful
(assuming I know the assembly language of the machine I'm debugging on); it
can reveal errors in assumptions about things that have been hidden by all
the unnecessary abstraction in modern languages.... 

--
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,alt.folklore.urban
From: ceb@dbrus.Unify.Com (Caroline E. Bryan)
Subject: Re: flash pictures of the sunset
Organization: /usr/lib/news/organization
Date: Tue, 25 Aug 92 19:44:30 GMT

In article <l9iertINNsfv@exodus.Eng.Sun.COM> landauer@morocco.Eng.Sun.COM (Doug Landauer) writes:
>>>>> It was kind of funny seeing people try to take flash pictures of the
>>>>> planetarium screen...
>>>>Will those tourists _EVER_ learn?
>>> 
>>> I once visited ... the biggest church in Christianity ... tourists
>>> standing there, trying to lighten the really huge dome with the flash
>>> of their pocket cameras.
>> 
>> Aw, come on. I can beat that easily. I've seen people take flash pictures
>> of the sunset.
>
>I believe I kinda understand what (if anything) is going on in some of
>those tourists' minds that causes that behavior.  I know nothing about
>cameras (likewise many of these tourists), but:  many cameras are set
>up to have nearly all of their functions be as automatic as possible,
>with as few buttons as possible....

[folklore part deleted]

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

"whose camera only flashes while burning"
Carrie		ceb@rechenau.unify.com	x6244   ------------------------------+
|   "When the power of love overcomes the love of power, then there will be   |
|   peace."					-- Anon.		      |
+-----------------------------------------------------------------------------+