Conference noted::hackers_v1

re: RSX

I never  commented my  code clearly until  I started perusing  RSX-11M
source code.  Very well commented.  Even the places where tricks  were
used with the instruction set  and addressing modes were clear  thanks
to the comments.  Can't say that for most programmer's code.

Also,  OS  source  code  is  a  good  place to  look for  optimization
techniques.   The only  problem is  trying to  figure out whether  the
author was programming  for speed or  memory efficiency.  Someone  had
told me about the difference between the following two sequences  (VAX
Macro):

Sequence 1:
	PUSHR	#^M<R0,R1,R2>

Sequence 2:
	PUSHL	R0
	PUSHL	R1
	PUSHL	R2

Both serve the same purpose (saving registers R0 thru R2) but each has
a situation where it is the more appropriate.  The first occupies  two
bytes of  memory (PUSHR  = ^XBB, ^M<R0,R1,R2>  = short literal  ^X07).
This would  be used  when memory  efficiency is  desired.  The  second
occupies six bytes but executes faster  (or so I am told).  Would  any
novice hack have figured this out on his own?

There  are  other places  to look  for optimization  techniques.   Try
looking  at  the  code  produced  by  an  optimizing  compiler.     An
instruction like 'MOVAB  6(R0)[R4],R1' is not  trying to calculate  an
address!   It is  adding three  values together  with one  instruction
(R1=6+R0+R4) and storing the result in another location.  Changing the
MOVAB to a MOVAL  will result in R4  being multiplied by 4 before  the
addition resulting in R1=6+40+(4*R4).  I have actually seen  compilers
generate this type of code.

tom_p

It's fine for a compiler to GENERATE obscure code, as long as the compiler
itself isn't obscure.

And, of course, as long as the code it generates is correct.

---Pete

re:0

I'm not sure what your gripe is.  Please take my multiple choice exam.

DEC ought to distribute {absolutely all, nearly all, most} sources to
prooducts at { very high cost, reproduction costs, no cost} in
{microfiche, mackine-readable media}.

re:1,2

We're in business to make money.  Maybe we can collect those programming
tricks and publish them in a book.  Call it: "Best Hacks from DEC's Corporate
Consultants"

Pat Sweeney

Gee, Pat, I still have that copy of 2/3rds of V7B SCAN.MAC you gave away
when I was in 11th grade.  I learned a lot from it.  What ever happenned
to "It's my job to promote Digital Computers, and if giving away marked
up listings to High School students can possibly promote Digital Computers,
I can do it."?
				/AHM/THX

Re:	.-2

Pat, I don't know how policy is moving, but I do like it the way it was,
e.g. automatic sources on most distributions of M/M+ fiche on VMS. I don't
think we should give sources of layered products away, but they should be
available at extra cost, subject to licence as previous. (if nothing else, at 
least it proves that we have sources and the capability of maintaining code,
and I can't say anything about sources that have been 'lost').

My basic thesis is that OS/RTL sources are vital for understanding what we
are doing and how to use it, especially because our manuals are getting 
better, but are still not quite there yet. If we are in the business of
selling computers, we should at least make an effort of helping people to
use them.

I don't think that Ed services have the answer either. Sure, they can teach
you a few techniques, but never enough. The courses are too short to cover
everything, and if they were longer, many people wouldn't attend.

Hugh.

Not making sources generally available hurts DEC's profits in the long run.
In the good old days, college students with access to TOPS-10 sources would
study, emulate, and learn from the sources we provided.  These kids gravitated
to the center of the universe (MRO1-2) and Digital now had experienced hackers
that they didn't have to train for a couple years working for college-hire
wages.

College students using VMS only get to see the manuals and graduate with far
less training.  Some come to work for DEC and DEC pays for the rest of their
education.  In general the VMS hacker's expertise is less than the TOPS-10
hacker's expertise; they arn't inferior, they just don't have access to the
same learning materials.

Not all those college hackers come work for DEC, most become enthusistic DEC
customers, and doesn't that help the bottom line?

Mark

 If you switch from software to hardware for a minute, there's a 
lesson to be learned in the problems faced with marketing the PRO350.  
DEC didn't release the bus structure.  APPLE and IBM did.  Ergo, APPLE 
and IBM had a huge market of secondary vendors waiting for their 
product when it came out.

 Perhaps the analogy isn't quite solid, but I think that in the long 
run, releasing sources only helps DEC.  DEC's a conservative company: 
it's not as though there's anything in the source code that's going to 
be so revolutionary (as an algorithm) that releasing the sources 
comprimises the whole product and gives the competition an edge.  
Releasing sources encourages more careful programming by DEC users (as 
was mentioned about RSX in previous replies to this note), and, I 
think, fosters a sense that DEC computers are reliable.  We've done a 
lousy job of marketing, and need all the public boosts we can get!

Re:	.-1

I think you have made a good point from the facts that you quote, but
the wrong one! If we carry on the hardware analogy, we see companies
like IBM and Apple making a fortune because other people
built compatible products.

If I was to choose a computer, one of the factors that would heavily 
influence my choice would be the availability of good expansion options.
I regret to say that a) DEC is not providing and b) it is showing no
real signs of providing.

If I go out and buy an advanced disk controller from one vendor and a 
specialized comms package from another vendor - as long as I buy a DEC
processor and DEC OS, DEC can still make money. If I go out and buy UNIX
and one of the many 68000 based machines currently out - DEC loose.

To my original point, you make money by helping other people use your 
systems in the way that they want. You don't make money by forcing
Marketing's idea of a solution down their throat! The average user is
too sophisticated in this days of the Mass Media Micro!

Hugh.

	I think releasing sources is a good idea.  I, as a customer
and student, benefitted from reading VMS sources off the microfiche.
I've read sources many times.  An example:

	I was optimizing a nasty FORTRAN program that was spending
hours of CPU time munging some data.  PC samples told me that a
majority of time was spent at 7FFE12C or some such address.  Now,
by reading the source, I was able to determine what was found
at that address.  I did not expect the company to publish
that information because it was so detailed, but it was nice
to be able to find it 

	KC

re: 4 

My note was to advocate a policy for DEC.  In general, we would strive to sell
what the customer actually wants and not inflate it with stuff he doesn't want
or need.  Sources in any form such be purchasable at some cost. I don't know if
they should be prohibitively high. 

As for my personal behavior, I given away my share of materials through the
years and I hope that it's helped.  But I'm in place to use discretion, a
blanket policy wouldn't do the same. 

Sources shouldn't be the crutch for poor documentation, as it was on the
DEC-10. 

I haven't lost my touch.  See page 387 of September's BYTE. 

Pat Sweeney

re: .9

You could have found the routine name by looking in SYS$SYSTEM:SYS.MAP
for the address and the nearest symbol with that or a lower value.

tom_p

Re: .11

	Sorry, but the routine is at the end of the system service
vector.   The address you would find would be SYS$foo+offset, but
SYS$foo has nothing to do with the routine.   The routine does not
have a global address.

	KC

I would vote for distribution of source OS and RTL listings at a minimum
cost.  The reason that TOPS-10 sources were distributed is because 
nobody ran an "out of the box" TOPS-10 monitor.  It was expected that the
site would change feature test switches to drop/add code that wasn't 
needed or was needed (TOPS-10 was/is all resident, and core was $1/word).
Also many TOPS-10 sites had their own requirements in special hardware
or software that caused monitor hacks.  Compare this to TOPS-20, wher
the sources cost big bucks, but most sites run TOPS-20 out of the box.
The bigger sites (usually) need monitor hacks (security and accounting
come to mind as things lacking in TOPS-20) and those types of things 
cannot be patched into a EXE file easily.  If you needed to know how 
something worked in the TOPS-20 montior or EXEC, your SWS would (should)
let you look at his fiche or you could buy the sources.  If the sources
are not available at all (much TOPS-20/10 layered software is this way)
I suspect either (1) the code is quite propriatry and valuable or (2) the
code is quite ugly and embarassing.

-GAS