HDTenEightyP/NetNews huggingface dataset:
From: borasky@ogicse.ogi.edu (M. Edward Borasky)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 9 Oct 92 21:27:59 GMT
Article-I.D.: ogicse.43895
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

As another fond user of 36-bit machines past (IBM 7094) I can add a few
more points to this discussion:

1. Floating point word size: for applications, bigger is ALWAYS better.
There is always some problem that won't run in single precision using
any word size.  The standard FP format for 36-bit machines was a 9-bit
exponent and a 27-bit mantissa, and there was a paper written back in
those days (ACM Journal or Communications, I think) titled "Is 36 bits
enough?"  I also used a few 48-bit machines (CDC 1604 mostly) and
preferred them to 36-bit machines.

2. In those days, IBM so dominated the industry that they invented 36-
bit machines, and the other vendors (GE, UNIVAC, etc.) followed suit.
The IBM 701 was essentially a 36-bit IAS machine (the IAS machines were
40-bit).  36 bits was cheaper than 40; the arguments about characters
packing into a word don't really mean much.

3. In those days, there were a lot of DECIMAL and CHARACTER machines:
IBM 650/7070, 702/705/7080, 1401/1410/7010 to name a few.  To simplify
the engineering process, they often shared subsystem designs.  For 
example, the 7080 (character) and 7090 (36-bit word) used the same
core memory box.  A 72-bit memory word could either be two 36-bit
7090 words or 8 9-bit 7080 characters (8 bits plus parity).

4. When IBM went to System\360, it was recognized that the 32-bit float-
ing format had limitations.  Those machines intended for scientific
markets had 64-bit hardware floating point, those intended for
commercial markets had more limited FP capability.  Some also had
7090 emulation!
From: weaver@jetsun.weitek.COM (Michael Gordon Weaver)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 9 Oct 92 02:07:08 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <869@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>Recently I came hold of and old paper that described the TENEX Operating
>System for old DEC Systems 10 and 20; I never used or saw such beasts but
>I was wondering what was the advantage of having 36 bits instead of 32
>or other 8*n (n>4) architecture.
>Was is just a hardware problem because 48 bits was to difficult to 
>manufacture at that time.
>
>On the DEC Systems 10 and 20 subject, why did they fade away in those
>days when nobody news what Open Systems were?
>
I think that computer architecture is very conservative. 

The reason the DEC-10 was 36 bits was most likely because the 701 and
its descendants were 36 bits. The 10 was DEC's attempt to 'scientific'
computers, a field at that time dominated by these machines.

The reason the IBM machines were exactly 36 bits is probably due to the
fact that they were using six bit characters. Six bit characters were
required for 26 English letters, 10 digits, space and period, the
minimum requirement for general purpose computing.  Having word sizes
about 36 bits for 'scientific' computers was already an established
trend.

First generation computers (the one-of-a-kind ones) were mostly thirty
to forty bits wide. They were mostly intended to replacing human
computers working mechanical calculators which were ten decimal digits,
fixed point.  This translates to thirty bits plus one for sign, or
thirty one digits. Of course, if you believe this, then when the IBM
machines came out with a machine emphasising floating point, they
should have had a word size of: 1 (sign) + 6 to 12 (exponent) + 30
(fraction) -> 37 to 43, round to multiple of 6 -> 42 or 48. But instead
they went for double word floating point (72 bits). I suspect that
double word floating point was invented for the first generation
machines, where floating point was done by integer hardware, and
no special consideration for floating point was made in the design
of the hardware.

As for why the DEC 10 faded away, ultimately that was a marketing
decision at DEC. But I think the limited address space (18 bits of 36
bit words addressed) was probably the biggest technical reason. DEC had
gone through the experience of trying to make 16-bit address PDP-11
work with more memory than could be directly addressed, and I think
they realized that not very satisfactory to the customers when they
could not directly address all the memory they could afford. DEC had
already made the VAX for different reasons such as large virtual
address, byte address, keep up with IBM on features.  But they had also
given it an has an architectural limit of 2**30 x 8 bits  directly
addressable physical memory, a big improvement over 2**18 x 36.  They
decided to put the effort that would have gone into continuing the 10
line into continuing the VAX line.


Michael Weaver.
From: tomv@s23.msi.umn.edu (Tom Varghese)
Subject: Cost and speed of Masked ROMs
Organization: University of Minnesota
Date: Wed, 14 Oct 1992 20:38:58 GMT

This may not be the right group to ask this but .....

Anybody out there have an idea what it costs to have a 4kx(8or9) masked ROM,
the faster the better ....  Any suggestions for places to look would be fine.

Thanks in advance.

Tom Varghese
tomv@s1.msi.umn.edu
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Multi uP P5 systems
Organization: Xenix Support, FICC
Date: Wed, 7 Oct 1992 14:01:12 GMT

In article <1992Oct6.133255.2382@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
> | Well actually I think that leaving out ASTs and providing cheaper processes
> | probably made it EASIER to program Unix because most people were presented
> | with a LCD system interface - let's face it read() is way easier to program
> | than $QIO - omitting system support for internal file structures was a
> | great idea - although they should have provided record locking from the
> | start. 

>   True, but you can build a blocking read over an ansync read easily, so
> I don't see any joy to the "easier to use" point, true though it is.

I think what he's getting at is that when asynchronous I/O is easy and
encouraged it tends to get used and eventually required in interfaces
where it's not really necessary. I can certainly appreciate this, from
my experience with RSX-11 (unsolicited input ASTs, for example). I do think
that careful design in the early stages would have allowed the best of both
worlds.

>   If I were doing it again (and I would dearly love to) I would initiate
> the i/o and have a control block with a major status, perhaps a byte to
> show good/bad, minir status to show either failure reason or transfer
> length, a void* pointer to user defined data (such as id info if using
> the same procedure to process many i/o requests), and i/o buffer address and
> length to allow retry on volume change, etc.

I don't like *this* model, where the operating system is continually updating
data segments in user space, at all. If you want to check on the status of a
pending request, by all means call iostat() (or whatever you want to call it)
on the file or I/O descriptor and fill in a buffer. But the business of having
an opaque file or transaction descriptor that you can ask questions about is
much cleaner than having to coordinate a block of sacred system data in user
space.
-- 
Peter da Silva                                         `-_-'
Ferranti Intl. Ctls. Corp.                              'U` 
Sugar Land, TX  77487-5012           "Heeft u vandaag al uw wolf geknuffeld?"
+1 713 274 5180                       "Tjener, denne ret er stadig levende."
Newsgroups: comp.arch,sci.electronics
From: markz@ssc.com (Mark Zenier)
Subject: Re: GALs and their programming-help request
Organization: SSC, Inc.,  Seattle, WA
Date: Wed, 07 Oct 1992 18:11:17 GMT
X-Newsreader: Tin 1.1 PL3

marco@gea.dei.unipd.it (Marco Pontil 259243) writes:
: 
: I'm looking for informations about the programming of the GAL chips.
: Where can I find them? May you help me? What is the difference between
: GAL, GAL type A and GAL type S?

1. Get the project from Elektor magazine.  (I don't know when 
it was published in a european edition, it was April and May 1992
in the US edition.)

2. The A versions rearrainged some of the circuitry inside, 
specifically the order of bits in the architechture control row.
This isn't documented in the articles in Elektor, I found it
by taking the software apart.

3. If you want to build your own programmer, Cypress and Samsung
publish their programming algorithms.   See the February 1989
Electronics + Wireless World for a project article for these chips.


Mark Zenier  markz@ssc.wa.com
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 8 Oct 92 17:53:47 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <1992Oct8.143254.15371@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>  I would hate to have to prove that having the # bits a power of two
>really saves anything, but that's the way the market has gone and it

I don't believe having the # bits a power of two saves anything, but having
the word size be a power of two multiple of the byte size is worth a lot
in a byte-addressed machines.  The 36 bit machines were all word
addressed; getting to bytes/characters within a word required special
tools.  I guess there is a C language for the GE/Honeywell machines (?);
if so the implementation of char arrays and char pointers must be
rather intricate.

I suspect the 9-bit bytes in the GE architecture was largely a matter of
making things fit; any utility to the 9th bit would have been discovered
later.  DEC used a different scheme to allow arbitrary-size characters
packed into 36 bit words with, in general, some bits left over per word.
One trouble with 9-bit bytes is that we don'thave 10-track magnetic
tape; so in writing data to type you have to know whether they are really
8 bit bytes that can be written byte-by-byte, or whether they are really
9 bit bytes that require word-for-word writing to preserve the 9th bits.

Not that we don't have enough trouble with tape in power-of-2 byte addressed
machines when the the matter of endian-ness arises.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
From: Beckman@Fwva.Saic.Com (Donna Beckman)
Newsgroups: comp.arch
Subject: RAID SYSTEMS AND ON-LINE BACKUP
Date: Thu, 15 Oct 1992 22:56:35 GMT
Organization: Science Applications Int'l, Corp. - Computer systems operation

We are looking into introducing RAID systems into VAX-based clusters
for hospital information systems.  We have done a lot of reading and
research and talking to vendors, but none of the RAID systems we know
about have the ability to back up the disks to tape while keeping the
array on-line.  Does anyone have experience doing this?  How are RAID
sites handling requirements for backups?  We have a hospital information
system and so are working with a 24 hour/7 day uptime requirement.  The
only scheme we can come up with is to shadow all or part of the RAID array.
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:11:19 GMT
Article-I.D.: ogicse.44006
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

The 7090 had CONVERT instructions which treated registers and memory
locations as groups of six six-bit characters.
From: bobp@hal.com (Bob Pendelton)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 7 Oct 92 18:49:55 GMT
Organization: HaL Computer Systems, Inc.

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 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. >>>
Xref: sparky comp.arch:9969 comp.lang.misc:3257 comp.software-eng:3788 comp.specification:465
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch,comp.lang.misc,comp.software-eng,comp.specification
Subject: Re: Specification v. design languages (was Re: Goals, Cost, and Flexibility)
Date: 15 Oct 92 10:47:02 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1992Oct15.090326.11643@topaz.comlab.ox.ac.uk> Jonathan.Bowen@prg.oxford.ac.uk (Jonathan Bowen) writes:
>In article <Bw4MuE.8GL@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>
>>In fact I've done CCS -> SML -> C, but actually demoed the SML in
>>real-time for a network router.
>
>Great! I'd be interested to hear about the mapping from CCS to SML.
>Can this (was this) undertaken in a rigorous and systematic manner?

Yes, in fact,

<AD MODE ON>

ExNet Systems is, and has been for a while, developing a compiler from
CCS to SML and/or C.

<ADD MODE OFF>

There are some tricky cases, especially if you want the result to be
truely distributed, eg for an MPP system, but it can be done.

We did a whole lot by hand, and it is systematic.

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.29|| Cheap Sun eqpt available.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || Mail/news feeds available.
--------------------------+ Will exchange uucped local articles free over V22b.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
Xref: sparky comp.arch:9937 comp.lang.misc:3236
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.arch,comp.lang.misc
Subject: Hardware Support for Numeric Algorithms
Date: 12 Oct 92 20:18:41 GMT
Article-I.D.: CS.1992Oct12.201841.22506
Organization: Oregon State University, Corvallis Oregon

I apologize for this disjointed message, but I had a work crunch and
missed some articles.  Herman Rubin and I were discussing the hardware
support needed to execute his numeric algorithms efficiently.  My last
message asked him to provide a complete, working subroutine for one of
his non-uniform random number generators.  In the last message I saw,
he said he might look at getting one of his graduate students to look
into it.  Have I missed anything since then?

At any rate, I don't find that answer satisfactory.  I'm not asking for
lots of code, only one page.  It doesn't have to be "efficient", it
just has to be correct.  Once we have working code, we can find ways to
make it efficient given current hardware, and estimate the cost and
benefit of new hardware.  So, Dr. Rubin, are you prepared to provide
the subroutine?

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
Newsgroups: comp.arch,sci.electronics
From: marco@gea.dei.unipd.it (Marco Pontil 259243)
Subject: GALs and their programming-help request
Organization: Universita' di Padova, Italia
Date: Wed, 7 Oct 1992 07:01:23 GMT


hi to everybody,
 
I'm looking for informations about the programming of the GAL chips.
Where can I find them? May you help me? What is the difference between
GAL, GAL type A and GAL type S?
 
Please replay directly to me because I don't receive news regularly.
 
     Thanks in advance.                 Livio Plos
 
---
livio@paola.dei.unipd.it                 Padua University (Italy)
From: usenet@motatl.UUCP (Usenet Files)
Newsgroups: comp.arch
Subject: Test
Date: 8 Oct 92 20:36:12 GMT
Organization: Motorola MCG, Atlanta, GA

this is a test
From: kevin@neuron.arc.nasa.gov (Kevin Montgomery)
Newsgroups: comp.sys.sgi
Subject: Re: IL: ilmemoryimg coord space reset -> 'img1 << img2' => 'img1 != img2'
Date: 15 Oct 92 00:00:12 GMT
Article-I.D.: news.1992Oct15.000012.7442
Organization: NASA-Ames Biocomputation Center

In article <1bhicaINNhbt@fido.asd.sgi.com>, walker@owl.asd.sgi.com (Christopher Walker) writes:
|> ilMemoryImg doesn't have an input it has to assume some default.  I've thought
|> about adding a constructor for ilMemoryImg that would take an ilImage* as a 
|> parameter and automatically inherit that image's attributes and (optionally)
|> copy the data from that image.  This would avoid most of this confusion and
|> be easier to use.. what do you think?

I was surprised the first time I read about ilMemoryImg that it didn't 
work like the other operators (take in an object and inherit).  How about 
overloading the constructor as "ilMemoryImg(ilImage *img)" so that you
could have it inherit attributes and do a copyTile as well?  It's nice for
quick prototyping of IP algorithms to just have everything in memory and 
deal with a small image until things work, then throw in the tiling stuff...

Also, under the current way of handling ilMemoryImg (setup->copyTile->
getDataPtr), you end up having to call copyTile and process the entire
backward chain for all tiles.  What might also be nice is to overload 
the '[]' operator for MemoryImg objects instead of using copyTile->getDataPtr,
then only process pages as they're accessed  (you'd have to malloc all
at the beginning, but you'd save the processing time for doing all the
pages).  That way, if I have a long chain and only access a little of 
the image, only what I'm accessing has been processed.  Cute idea, maybe 
a little less performant (added test per ref).

|> BTW, you can also avoid this problem by using an ilConfig to specify a fixed
|> coordinate space and get a 10x10 tile with a single call to getTile.. its quite
|> a bit more efficient as well.  Avoid using getPixel unless you really need 
|> random access to individual pixels.

yeah- this was a quickie (<1minute) hack just to print out what was there
(no perf req) and remembering the args to getPixel was easier than getTile
at the time.  (in the real code i grab tiles for processing- i should probably
have posted the more correct way, since people just starting the IL are 
reading- sorry...)


On a side note, what is the suggested way for handling global image operations?
I'm just finishing up writing a blob-coloring algorithm, but it requires me
to process the whole image to find what blobs may be connected to what blobs
elsewhere in the image.  A similar example is ilHistEqImg, where you have to
do a histogram before you can process any data.  I think the nice IL demand-
driven model starts to break down on global operations and the ilMemoryImg
is a nice way to hack out of it, but I don't really see any other way around
it.  

						  kevbop
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: problem with dvhtool and sash
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 15 Oct 92 00:41:20 GMT

In <2ADCA716.20325@news.service.uci.edu> fredv@abba.acs.uci.edu (Fred Velijanian) writes:

| Using: Indigo R4000, Irix 4.0.5F
| 
| Recently I duplicated a system disk using dump/restore and booted
| from this new disk. The only problem was that sash was not in the 
| volume header, so I used CDROM's sash for booting. Then using
| "dvhtool" I copied the /stand/sash to the header. (using the 
| "vd" command and the "c /stand sash".)
| 
| However booting from the sash on disk now gives me a "execute format
| error". What am I doing wrong?

Sounds like you have the wrong sash on the disk somehow.

The command:
	strings /stand/sash | grep Version
should come back with something like this.
	SGI Version 4.0.5E ARCS  Aug 27, 1992
The key part (for r4k indigos) is the word 'ARCS'.  If you see
something like:
	SGI Version 4.0.5D IP12  Aug 15, 1992
(for almost any number after "IP"), then you have the wrong sash.

If you have the wrong sash, I'd highly recommend re-installing
eoe1, as there would appear to be something wrong with your
disk copy procedure (whatever it was).
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: to preallocate, or not to preallocate (that is the question AGAIN?)
Date: 14 Oct 92 05:55:34 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <Bw2Iu9.K8t@helios.physics.utoronto.ca> sysmark@helios.physics.utoronto.ca (Mark Bartelt) writes:
| The standard SGI response to those people who don't like it is "Rebuild
| your kernel so that it will always preallocate swap space (and suffer the
| consequences ;-)", or something along those lines.
| 
| It occurs to me that this provides an all-or-nothing solution, with the
| possibility that there may be some installations where neither the "never
| preallocate" nor the "always preallocate" options may be satisfactory.
| 
| How hard would it be to make backing store preallocation selectable on a
| per-process basis?  Then one could configure one's kernel to use whichever
| default made more sense most of the time, but would also permit one to get
| the alternate behaviour if/when desired.

If you think about it, you will realize that it has to be system wide
to be effective, since when virtual memory becomes overcommitted, it
isn't completely determinate which processes will get blown away.

Locking your process into memory, as Jeff mentioned (with mpin or plock)
is drastic (and requires superuser privilege), but may be feasible/acceptable
in some cases.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi