HDTenEightyP/NetNews huggingface dataset:
From: tzs@stein.u.washington.edu (Tim Smith)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 9 Oct 92 10:09:51 GMT
Article-I.D.: u.1992Oct9.100951.28008
Organization: University of Washington, Seattle

Don't forget the story of Samuel's checker program (I think that's the one
I want).  It was one of the first learning game programs.  He developed it
on a 32 bit machine.  While doing that, he noticed a near trick that would
speed up move generation, but required a 36 bit word.  Soon after, he was
put in charge of design on a new machine at IBM, and for some reason, he
decided on 36 bits.

So, is this a true story?

--Tim Smith
Newsgroups: comp.arch
From: thacher@renbourn.unx.sas.com (Clarke Thacher)
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: Thu, 8 Oct 1992 21:27:14 GMT
Organization: SAS Institute Inc.

In article <1992Oct7.184955.481@hal.com> bobp@hal.com (Bob Pendelton) writes:
>From article <MOSS.92Oct5095425@CRAFTY.cs.umass.edu>, by moss@cs.umass.edu (Eliot Moss):
>
>> I suspect there was a feeling that 18 bits of address space was large enough,
>> and the 36 bit machines were built partly so that one word could hold one Lisp
>> cons cell (car and cdr both an address in size, hence 2 x 18 = 36 bits).
>
>You're putting the cart before the horse. 36 bit computers were there
>long before there was a LISP. 

I'm not certain what machines you're thinking about, LISP was around in
1959,  well before the DEC 20/10/6 machines.

>
>I'm aware of 2 good reasons for 36 bit computers, and one bad one for
>keeping them around.
>
>1) The "standard" character codes of the day were 6 bits. So words
>sizes that are multiples of 6 were a good thing.
>
>2) Floating point precision. 36 bits is a great size for a single
>precision floating point format, and 72 bits is wonderful for a double.
>
>Many tasks that require a double precision number on a 32 bit machine
>can be run using single precision on a 36 bit machine. And some tasks
>that work just fine with 72 bit format don't work at all with only 64
>bits.
>
>The other reason was compatibility with IBM and FORTRAN. The original
>FORTRAN had six character identifiers and ran on machines that stored
>6 characters in a word (makes symbol table look ups pretty straight
>forward... :-) On the old 1108 that I learned FORTRAN on, the comiler
>still stored identifiers in one word.
>
>
>				Bob P.
>
>-- 
>Bob Pendleton             | As an engineer I hate to hear:
>bobp@hal.com              |   1) You've earned an "I told you so."
>Speaking only for myself. |   2) Our customers don't do that.
>                   <<< Odin, after the well of Mimir. >>>

I went back to _Computer Engineering, A DEC View of Hardware Systems Design_,
Bell, Mudge, McNamara, and found the following discussion about some of their
design decisions for the DEC10 family:

"  Earlier DEC designs and the then-current six-bit character set standard
 forced a word length that was a multiple of 6, 12, and 18 bits.  Thus, a
 36 bit word was selected.
...
 The floating point format was chosen to be the same as the 7090, but with
 a format that permitted comparisons to be made on the number as an integer
 in order to speed up comparisons, and require only a single set of compare
 instructions.
...
 Our desire to execute LISP directly resulted in good address arithmetic.
 As a result,  both LISP and FORTRAN on DECsystem-10 are encoded efficiently."


-- 
Clarke Thacher        OSRD/HIP Software Developer          SAS Institute, Inc.
thacher@unx.sas.com         (919) 677-8000    SAS Campus Drive, Cary, NC 27513
                         No Pain, No Pain.
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 8 Oct 92 05:48:31 GMT
Organization: Pacific Software Group, Riverside, CA

In an article, dafuller@sequent.com (David Fuller) writes:
>All existing UNIX backup and restore facilities are highly 
>dysfunctional compared to similar facilities under the aforementioned 
>operating systems.  They can make only the grossest assumptions about 
>file contents (back it up or not, bud?) and thus cause vast redundancy 
>in backups; if you change a single byte in the file, you back up the 
>whole thing instead of changed records.

This is all well and good, but you are apparently making the statement
that "redundancy in backups" is a bad thing ... I disagree. This redundancy
has saved the day for several customers that I'm aware of.

>[...] If society ran the same way UNIX does, everyone who owned a car would
>be forced to refine their own gasoline from barrels of crude...  

Because the programmer is virtually free to do anything he wants, the task
at hand is not hindered by others' limitations. It inspires invention,
provokes change and growth -- and ultimately this benefits the end-user
because a better system has evolved. The process isn't perfect, but it
seems to me to be far superior to the "master design" concept whereby one
group is deemed to "know best" and everyone else has to live with the result.

(One moment please ... I'm putting on my flame-retardant pajamas ...)
-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (714) 681-2623
Pacific Software Group, Riverside, CA
Xref: sparky comp.arch:9989 comp.sys.hp:11785
From: pjd2@po.CWRU.Edu (Pedro J. Diaz)
Newsgroups: comp.arch,comp.sys.hp
Subject: HP 7100 Architecture Info
Date: 17 Oct 1992 01:45:07 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: pjd2@po.CWRU.Edu (Pedro J. Diaz)
NNTP-Posting-Host: thor.ins.cwru.edu


Can some one point me to available data/publications on the performance
and architecture of the HP 7100 series.

Thanks.


P. J. Diaz, Asst Professor
EBME

Newsgroups: comp.arch
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: eklektix - Boulder, Colorado
Date: Fri, 9 Oct 1992 16:12:32 GMT

tzs@stein.u.washington.edu (Tim Smith) writes:
>Don't forget the story of Samuel's checker program (I think that's the one
>I want).  It was one of the first learning game programs.  He developed it
>on a 32 bit machine.  While doing that, he noticed a near trick that would
>speed up move generation, but required a 36 bit word.  Soon after, he was
>put in charge of design on a new machine at IBM, and for some reason, he
>decided on 36 bits.
>
>So, is this a true story?

Seems doubtful.  From a footnote in the article "Some Studies in Machine
Learning Using the Game of Checkers", A.L. Samuel, originally in IBM JR&D
7/59, reprinted in _Computers_and_Thought_ (Feigenbaum and Feldman, eds):
	"The first operating checker program for the IBM 701 was written in
	1952.  This was recoded for the IBM 704 in 1954.  The first program
	with learning was completed in 1955 and demonstrated on television
	on February 24, 1956."
Of course, the wording doesn't explicitly say that the first program for
the 701 was also Samuel's first program.  But one could assume that a
predecessor would have been mentioned if it existed.  The 701 and 704 were
both 36-bit machines.  The article does, in fact, mention a coding trick
that requires 36 bits.  There are 32 positions on a checkerboard (all of
one color on an 8x8 grid), but it turned out to help to have one spare bit
after each 8.

OTOH, the 701 actually came out in '53 (per Bell&Newell), after Samuel's
first result, and Samuel must have been at IBM when he did the work (else
why publish in IBM JRD?), so he must have been involved with the machine
very early on.

this probably ought to move to alt.folklore.computers before much longer...
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
   ...Never offend with style when you can offend with substance.
From: borasky@ogicse.ogi.edu (M. Edward Borasky)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 13 Oct 92 18:22:23 GMT
Article-I.D.: ogicse.44007
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

In article <14930@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>Didn't the IBM 7030 ...
The IBM 7030, popularly known as Stretch, was a 64-bit machine.  The 
hardware was actually 72-bit; Hamming codes were used for error detect/
correct.  It was a supercomputer for its day; it had very fast floating
point arithmetic and a very complete character and decimal instruction
set as well.  Approximately six were sold; most ended up in places
where supercomputers thrive today (Livermore Labs, the US Weather
Bureau, various classified shops, etc.).  I believe IBM kept one inter-
nally for use when such power was needed.  System\360 was designed by
many of the same people who designed Stretch; the 32-bit/64-bit orien-
tation and 8-bit bytes clearly show the Stretch influence.  The techno-
logy was germanium transistors, diodes and magentic core memory, al-
though vacuum tubes and relays were still used in peripherals.  The
technolgy used in the 7030 was essentially the same as the 7090 and
other vendors' machines of that era; what made the Stretch a 
"supercomputer" was heavy use of architectural goodies like pipelining.
From: div@NAD.3Com.COM (Dinesh Venkatachalam x5498)
Newsgroups: comp.arch
Subject: TI8847 and Square Root Computation
Date: 14 Oct 92 13:39:49 GMT
Reply-To: div@NAD.3Com.COM
Organization: 3Com Corp


There were some postings earlier in the year regarding TI8847 and divison
on the same. Is there some reference to doing Square Root on the same. I
guess TI uses Newton's method or Goldschmit's method to do this. The book
by Hennessey and Patterson seems to confuse me on the method used. 

What is the TI reference maual for 8847 called ?


--- Dinesh
===============================================================================
Dinesh Venkatachalam					div@nad.3com.com
3COM Corporation
(408)-764-5498
===============================================================================

Xref: sparky comp.arch:9880 comp.lang.misc:3227
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 13 Oct 92 12:50:23 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Oct9.230020.3388@nas.nasa.gov>, eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:
| For those claiming the existence of a 6-bit byte, sorry I have never
| heard of such a thing on the three 36-bit machines I am familiar with.

The GE/Honeywell machines have hardware support for addressing 6, 9,
or36*N bits, where N 1..63. This includes both addressing and stacks of
that size, although stacks mush be written 6, 9, 36, 72, or 288 bits at
a time. The addressing uses an indirect descriptor word rather than an
address in bits, but there's no load-shift-and logic in the program.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: scott@ryptyde.cts.com (Scott McClure)
Newsgroups: comp.arch
Subject: Compu$erve hardware? WAS: What was the intended advantage of using 36bits CPU?
Date: 9 Oct 92 13:59:41 GMT
Organization: Ryptyde TimeSharing, San Diego, CA

burley@geech.gnu.ai.mit.edu (Craig Burley) writes:

>In article <869@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:

>   On the DEC Systems 10 and 20 subject, why did they fade away in those
>   days when nobody news what Open Systems were?

>They didn't fade away -- they're still running Compu$serve!

>Seriously, [...]

Now that's an interesting question.  What kind of hardware *does* Compu$serve
use?  What about the other service providers?

Scott

-- 
INTERNET:  scott@ryptyde.cts.com                     | "Nuke the homeless gay
ARPANET:   ryptyde!scott@nosc.mil                    |  baby whales for Jesus!"
UUCP:      {crash, nosc}!ryptyde!scott               |    - bumper sticker
From: mikeh@kralizec.zeta.org.au (Michael Hore)
Newsgroups: comp.arch
Subject: Re: Not using integers
Date: 11 Oct 92 02:24:39 GMT
Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32


ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>The A-series machines that I know anything about had
>	48 data bits
>	 3 tag bits
>	 + parity &c
>The tags that I can remember are
>	 0 single precision (47 bit; the top bit was unused so that the
>		B6500 would have the same SP format as the B5500)

   [rest deleted]

Yep, you're right, of course.  I've just unearthed my old B6500
manual and it agrees exactly.  The only difference is that
tag 4 was unassigned (this was 1967!) -- obviously they later
assigned it.

It was the B5500 which had only one tag bit for numeric -- words
were 48 bits, so numerics were restricted to 47 bits, as you pointed
out.

--  Mike.

--------------------------------------------------------
Mike Hore        Internet:    mikeh@kralizec.zeta.org.au
Xref: sparky comp.arch:9936 comp.lang.misc:3235
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 12 Oct 92 20:09:14 GMT
Article-I.D.: CS.1992Oct12.200914.22158
Organization: Oregon State University, Corvallis Oregon

In article <1992Oct5.074115.277@newsroom.bsc.no>
izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
>   Can you show me how Mathematical notation can be ambiguous and highly
>dependent on context?
>   As far as I know anybody with a good high school training knows what
>to do when she sees this:
>
>   n=10
>         n
>	----
>        \
>         \
>   A=    /    i*i
>        /
>        ---
>       i=1
>   What would you like to use? Flow diagrams? LISP? BASIC?

Any good high school student knows what to do with this.  The problem
is that a good college student will ask "which + operation?"  Since you
didn't specify, I can assume you meant integer addition modulo 17.  See
what I mean by ambiguity?

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
Xref: sparky comp.arch:9978 comp.lang.misc:3264 comp.software-eng:3813
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: compiled bitblt on 68040s
Organization: Intel Corp., Hillsboro, Oregon
Date: Tue, 13 Oct 1992 04:40:39 GMT

	I have a dynamically compiled bitblt routine that does bitblt in my Smalltalk
	virtual machine on mac IIs.  We've just got some Mac quadras with 68040s and
	the routine no longer works unless its run under adb and stepped through slowly.

	The problem appears to be the twin I & D caches on the 68040.


	The bitblt routine works by concatenating a set of machine code fragments
	by writing them into a buffer, and then calling the resultant code sequence.

	As I understand it the 68040 is a harvard architecture so I have to ensure
	both that the data written is flushed from the dcache, and that the icache is
	flushed so that the written data can be executed.

	We have no 68040 manual.  Can those that know email me either
		a) a description of the 68040 I&D caches
		b) a description of their solution to this very problem :-)

	Send email and I'll summarise for the net.


This bears repeating: 

pardo@cs.washington.edu <pardo@cs.washington.edu> has created a
reasonably portable system for on the fly code generation such as you
describe above.

It is described in a technical report titled "A Portable Interface for
On-The-Fly Instruction Space Modification", available from the Dept.
of CS at University of Washington.

Published as
    David Keppel
    "A Portable Interface for On-The-Fly Instruction Space Modification",
    pp. 86-95
    ASPLOS IV proceedings
    Fourth International Conference
    on Architectural Support for Programming Languages and Operating Systems
    ISBN 0-89791-380-9
    ACM Order Number 556910
    Santa Clara CA April 8-11, 1991

He describes implementations on the following systems:
    SPARC based SUN workstations
    Sequent Symmetry (i386)
    DEC VAX 2000, 3500, 8550
    MIPS R2000 DECstation 3100
    	R3000 DECstation 5000/200

Dave may already have an implementation on a 68K system, or know of
one.  Even if he does not, anyone creating a dynamically compiled
bitblt routine would be wise to (1) obtain or implement the fly_*
interface on your target system, and (2) write code using the fly_*
interface.

Even in such a machine dependent domain, some degree of portability
can be obtained.




In the interest of completeness, you can find it in your local library,
order it from UW, or:

    Copies may be ordered prepaid from
	ACM Order Depratment
	POBox 64145
	Baltimore Maryland MD21264
	Price: Members 19$, others 25$
--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: Whatever became of the DEC 10/20 systems...
Organization: Curtin University of Technology
Date: Fri, 16 Oct 1992 13:12:04 GMT

In article <Bw2n8u.172@xrtll.uucp>, rsnider@xrtll.uucp (Richard Snider) writes:
...
> Various sources here comment on the fact that the KL CPU took too
> much power for what it did, to word-size, etc...
> 
You bet. I have an ex-Ahmdahl PS for the CPU of my KL. 2.2KW instead of ~20KW!
The original PS is a linear regulator. Hence, most of the input power help run
up the Air conditioning bill

~Paul

Newsgroups: comp.arch
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: Dynamic ANDF
Summary: once again...
Organization: eklektix - Boulder, Colorado
Date: Fri, 16 Oct 1992 05:19:50 GMT

karger@osf.org (Paul A. Karger) writes:
>mrc@defender.dcrl.nd.edu (Michael R. Casey) writes:
>|> I am currently trying to research the idea of using Architectural
>|> Neutral Distribution Formats (ANDF) as a basis for hetereogeneous
>|> computer interactions.  I am looking for any information that may
>|> have been previously published on converting from C or any other 
>|> language to an ANDF, and then theANDF to binary conversion...
...
>You should look up the references to the UNCOL project of the late 1950s
>- early 1960s...

UNCOL was the first label on the idea, and probably the most serious early
attempt.  However, people have tried the idea again and again over the
years.  It would probably be better to fast-forward to at least the mid-
70's to get a bibliography; that way you get some perspective on the
concept, in particular where it works and why it fails.

In retrospective, it's a bit funny and a bit sad.  Over the years, some of
the best minds in software have worked on the problem, but like Bullwinkle
doing magic, the rabbit never seems to come out of the hat.  It's always
promising in the beginning, and each attempt *seems* to have moved further,
yet eventually each has collapsed of its own weight.

>...This [UNCOL] was the first attempt to do something like ANDF - it
>wasn't a success at the time, because compiler technology was still very
>primitive.

Examples, please?  Pardon (if you will) my skepticism, but this too is a
claim we've seen before--that previous attempts failed only because they
lacked some magic level of technology which has now been reached, rather
than that the idea was fundamentally flawed.  It's like Bullwinkle telling
us "This time for sure, Rocky!!" and if we haven't seen the previous 37
episodes, we believe it for a moment.

As a matter of fact, compiler technology of the late '50's was at a level
to which only few compilers have aspired over the years.  Most of today's
compilers, for example, still don't reach the level of analysis and optimi-
zation described in "The FORTRAN Automatic Coding System" (Backus,
_et_al_, 1957).
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
   ...Never offend with style when you can offend with substance.
Lines: 21
Date: Mon, 12 Oct 92 10:58:32 MDT
From: kelly@baloo.ee.byu.edu (J. Kelly Flanagan)
Newsgroups: comp.arch
Subject: Re: Memory reference sequences


	The real problem with all of the trace gathering methods
discussed so far is a lack of true system behavior.  The inlining
techniques discussed fail to gather multiple program references,
interrupt routines, system calls, exceptions, and other operating
system generated references.  The inlining techniques also gather
virtual addresses whereas most simple cache models are meant to be
driven with physical addresses.

	ATUM is a good technique for gathering complete traces, but is
available only on VAX type architectures, (those with modifiable
microcode) and produces short traces 400,000 contiguous references.

	What size of errors are involved in using user only
virtual address traces to emulate multiprogramming complete traces?
Good question!!!

Kelly
kelly@ee.byu.edu
--
James Gritton - gritton@byu.edu - I disclaim
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: Curtin University of Technology
Date: Mon, 12 Oct 1992 11:12:48 GMT

In article <id.WPXT.TMD@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> In article <1992Oct7.184955.481@hal.com> bobp@hal.com (Bob Pendelton) writes:
...
> RSX-11 did this with 16-bit words. You used a 40 element character set for
> identifiers, then stored numbers by multiplying by 40:
> 
> 	word = c0 + 40 * (c1 + 40 * c2)
> 
> 40*40*40 = 64000, so you could store three characters in a 16 bit word. This
> was called RAD-50 (50(8) == 40(10)), or in a few cases RAD-40. You could even
No, MOD-40...
> include RAD-50 constants in Fortran:
> 
> 	INTEGER*4 MCR = 6RMCR...
> 
> On the old 11/44 I learned Fortran on, the compiler still stored identifiers
> in a word. And the operating system stored file names the same way.
> 
> And, you know what, RSX-11 is still being used, and it still does.

It was first used to pack 6 'chars' into 32 bits and have 4 bits left over for
flag bits in symbol tables etc. Not sure if in the DEC world it was the 6 or an
18 bit machine that originated it. The encoding is diferent for 11's and the 6/-
10/20 family.

~Paul

Newsgroups: comp.arch.storage
From: thot@desert.in-berlin.de (Marcus Klische)
Subject: Re: QUESTION: 1GByte <-> 2GByte DAT
Organization: Private Site
Date: Sat, 10 Oct 1992 13:47:30 GMT

admerlev@sundae.triumf.ca ( Arnd Merlevede ) writes:

>Hi, can anybody explain where the differences are in different
>capacity DAT drives ?
>I thought the DAT is a standard, so capacity should be function of
>the tape length. And every DAT should be able to read every others
>tape.

>Thanx for sharing your knowledge or experience
>Arnd

Hello Arnd
I have a HP-DAT drive called Modell 2000. I can use tapes with the length
60m and 90m. 60m have a cpacity of 1,2GB and 90m of 2GB.
But there is another drive called Modell 2000DC. With this drive it is 
possible to power up your capacity to 8GB. The DDS-format of the
2000DC has been extended to include data compression (DDS-DC)
bye
----
Marcus
thot@desert.in-berlin.de

Newsgroups: comp.arch.storage
From: infotech@access.digex.com (Dr Sanjay Ranade)
Subject: Re: SUMMARY: information about UNITREE?!?!
Keywords: mass storage, file servers, hierarchical storage
Organization: Infotech SA Inc, Silver Spring, MD
Date: Wed, 14 Oct 1992 20:19:12 GMT

The following paper :

"THE CURRENT STATE OF UNITREE ON MULTIPLE PLATFORMS AND POSSIBLE FUTURE
DIRECTIONS"

presented at the first UniTree User Group meeting in Baltimore, MD
on Sept 17th '92 is available to anyone interested. It includes
information about UniTree status on Amdahl, Convex, Cray S-MP, RS/6000,
SGI, Sun, CDC machines. 

Please fax or e-mail your request to : 

Infotech SA Inc
Fax : 301-989-2290
E-mail : infotech@digex.com



From: johnm@hpgrla.gr.hp.com (John McCarthy)
Date: Tue, 6 Oct 1992 15:04:23 GMT
Subject: Re: Tahiti-II CD-ROM drive info wanted
Organization: Hewlett-Packard, Greeley, CO