HDTenEightyP/NetNews huggingface dataset:
From: lus@ucs.orst.edu (Shih-Lien Lu)
Subject: question about DRAM ...
Keywords: DRAM, mode of operation
Organization: University Computing Services - OSU
Distribution: us
Date: Thu, 15 Oct 1992 01:15:50 GMT

Could some kind soul explain to me the difference between PAGE MODE,
FAST PAGE MODE and STATIC COLUMN types of DRAMs? Thanks in advance.

Shih-Lien
Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Xenix Support, FICC
Date: Thu, 8 Oct 1992 20:32:11 GMT

I'd like to see modules at a higher level: you build the computer out of
a bunch of independent systems talking something like IP over the backplane
(or whatever connection mechanism you want). If you want a high res display,
put in a display server. It'll look like an Xterm to the rest of the system.
If you want another one, plug in another display server. You want more CPU
power, plug in a CPU server. The overall OS will be something like Plan 9
or Amoeba... departmental server on the desktop. Xterm not fast enough, get
a compute server with a display. Copy protection: Word Perfect would sell
you a "word perfect server" with its own CPU all sealed in phenolic...
-- 
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."
Xref: sparky comp.arch:9940 comp.lang.misc:3238
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 13 Oct 92 02:20:55 GMT
Followup-To: comp.arch
Organization: CWI, Amsterdam

In article <1992Oct12.200914.22158@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
 > 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?
 > 
Mostly that kind of stuff is assumed.  But just today it took me some time
to parse:
	ind d # ind b + ind c mod p  -  1
where # stands for the equivalence sign (three horizontal strokes); spacing
is about identical to the original.  I really needed backtracking.  No
ambiguity, but difficult for the reader.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.arch,comp.parallel
From: aranake@cse.uta.edu (Sandeep Suresh Aranake)
Subject:  Looking for Info on Graph Partitioning
Apparently-To: comp-parallel@uunet.uu.net
Organization: Computer Science Engineering at the University of Texas at Arlington
Distribution: usa
Date: Wed, 14 Oct 1992 22:18:39 GMT


I will greatly appreciate if any of you could send me 
references on graph partitioning techniques (both serial 
and parallel).

Please mail your reply on my e-mail address.
I will post the summary of references.

Thanks in anticipation.

Sandeep

aranake@cse.uta.edu
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 10 Oct 1992 02:27:58 GMT
Organization: University of Michigan, CITI
NNTP-Posting-Host: sinshan.citi.umich.edu

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 discussion is really about fitting 6 or 9 bit characters into a
word so that they pack neatly and you can do full word comparisons on
text without worrying about the extra bits, etc.

On the other hand, the GE-6x5 (and presumably their Honeywell and Bull
successors) really did have both instructions and funny indirect
addressing modes which would unpack words.  In either 6 or 9 bit
chunks.




(Sarr Blumson)
Newsgroups: comp.arch
Subject: Re: Single instruction machines
From: Bruce.Hoult@bbs.actrix.gen.nz
Date: Fri, 9 Oct 1992 05:53:43 GMT
Organization: Actrix Information Exchange

In article <1992Oct8.144034.6432@news.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
>
> I've
> recently been told by one person who should know better that the 68000
> was a PDP-11; he'd programmed both at the assembly language level and
> never noticed the differences!)


That's a very interesting claim, and may *almost* be possible, for
someone who makes very conservative use of both machines -- especially
in his 68000 code.

It would be possible, I suppose to not notice that the 68000 registers
are 32 bits and only use the .b and .w forms of instructions.  The
slightly different instruction mnemonics (e.g. MOV vs MOVE) could be
glossed over as just a difference in assemblers rather than in
underlying hardware.

You'd have to religiously use PC and SP on both machines instead of
explicit register numbers, but the addressing modes are almost totally
compatable -- it's just that the PDP-11 lacks indexed addressing (base
register plus index register plus offset) and the 68K lacks absolute
indirect (from hazy memory of the PDP-11.  Is that right?).

You'd have to avoid the LINK, UNLK and MOVEM (move multiple registers)
instructions that almost every non-trivial 68K subroutine uses for
stack frame management, but then you don't really *need* them.

All this points to a remote possibility that a casual PDP-11 assembly
programmer might be able to move to a 68K and not notice the
difference, but the thing that makes me really dubious is this:  how
did he not notice that the 68K has twice as many registers, split into
two banks?

Sure, they're only numbered 0 to 7, but the two banks have totally
different uses and you simply can't use the 68K data registers, for
instance, for everything you can use the PDP-11 registers for.  Unless
you limit yourself *totally* to immediate, absolute, PC-relative and
SP-relative addressing you can't avoid knowing about the seperate
address registers -- and it's hard to imagine a PDP-11 programmer who
doesn't use indirect, autoincrement, autodecrement and relative
addressing on other than just the PC and SP.

Hmm -- perhaps it might be possible if the guy was a FORTRAN or BASIC
programmer who learned a bit of assembler, and didn't ever learn about
pointer-based programming and structures.

It does boggle the mind, though, if the claim is intended to be taken
literally!  (Perhaps it's not)
-- 
Bruce.Hoult@bbs.actrix.gen.nz   Twisted pair: +64 4 477 2116
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 500 MIPS personal computer with 256MB RAM and 8 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatible?"
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 13 Oct 92 13:03:04 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <id.2DWT.GLB@ferranti.com>, peter@ferranti.com (peter da silva) writes:
| In article <1992Oct6.133255.2382@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:

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

  The idea is that when the i/o is complete the system calls a user
procedure and puts the status in the i/o data block. I see no benefit
from have the system notify me that the i/o is complete, and then having
to do another system call to find out if it worked. UNIX usually mixes
the data transfer count and status, trying to use a single return value
for several things. Needless to say, this results in lots of user code
to interpret the result, and minimal info as to the cause of any
failure.

  Did you really mean have a separate call to find out if i/o worked, or
is it just not clear.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.arch
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Fri, 9 Oct 92 23:00:20 GMT

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.
You certainly may have packed characters that way (and maybe even on 60-bit
CDC machines), but none of these architectures supported such a byte concept
in the architecture.  These are not byte-oriented machines.
Sure, I saw the 1 extra bit and five 7-bit characters on a 10/20,
I saw 6 and 9 bit characters on the 1108 and saw similar combinations
from IBM 36-bit codes.

I surprised Chuck Lawson at JPL (Numerical Linear Algebra [P-H] with C. Moler)
when I ported a code with REAL*4 FORTRAN declarations at a time when
the Univac did not support a 9-bit code.  It accepted it.  That raised
an eyebrow, and it also showed the power of IBM on the marketplace.
And REAL*8 and similar decs would go thru.

Passing thru again.

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Acting Associate Editor, Software and Publication Reviews
		(Seeking reviews for software and pubs for)
  Scientific Programming
  {uunet,mailrus,other gateways}!ames!eugene
Seeking Books to buy:	Bongard, Pattern Recognition
			Imhof, Cartographic Relief Presentation
			Books on or by Benjamin Whorf
Newsgroups: comp.arch
From: karger@osf.org (Paul A. Karger)
Subject: Re: Dynamic ANDF
Keywords: ANDF Distributed
Organization: Open Software Foundation
Date: Mon, 12 Oct 1992 18:43:34 GMT

In article <1992Oct12.133848.13898@news.nd.edu>, 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.  I 
|> would be happy to receive info on both the static conversion (ie.
|> conversion to an executable) as well as a dynamic conversion, (ie.
|> the conversion happens at run-time in order to allow some number of 
|> tasks/processes to cooperate).

You should look up the references to the UNCOL project of the late 1950s - early 1960s.  This was the first attempt to do something like ANDF - it wasn't a success at the time, because compiler technology was still very primitive.
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: Xenix Support, FICC
Date: Thu, 8 Oct 1992 20:44:00 GMT

In article <1992Oct7.184955.481@hal.com> bobp@hal.com (Bob Pendelton) writes:
> 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.

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
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.
-- 
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
From: davew@willow03.cray.com (Dave Wagner)
Subject: Re: What was the intended advantage of using 36bits CPU?
Originator: davew@willow03
Organization: Cray Research, Inc.
Date: 14 Oct 92 13:26:50 CDT


In article <1992Oct12.131847.11842@cae.prds.cdx.mot.com>, dan@cae.prds.cdx.mot.com (Dan Breslau) writes:
> 
> Yes, the Honeywell 6000 series (under GCOS, circa 1981) used 6 and 9
> bit bytes -- 6 in batch mode, 9 in timesharing.  This made it lots of
> fun trying to share programs and data between the two modes...  (I can't
> remember what size bytes Multics used; I'd bet on 9 bit, though.)
Of course, this silliness was due to the incredibly fantastic (NOT!) GCOS
(Gag and Shoke On Shit) operating system.  Real Honeywell users used CP-6.
-- 
Dave Wagner                                     Cray Research, Inc
davew@cray.com , uunet!cray!davew               655F Lone Oak Drive
(612) 683-5393                                  Eagan, MN  55121
Newsgroups: comp.arch
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 13 Oct 92 02:13:25 GMT
Organization: CWI, Amsterdam

In article <1678@idacrd.UUCP> desj@ccr-p.ida.org (David desJardins) writes:
 > Will Walker <wlw@hpfcso.FC.HP.COM> writes:
 > > For example without a transfer instruction you might do a store and a
 > > load from cache to do the transfer.  Suppose this takes 3 cycles.  If
 > > you add new register ports and a new bus you can almost certainly do
 > > the new transfer instruction in one cycle.  So your trade-off is 2
 > > cycles times "how common are register transfers" versus a rather
 > > significant hardware cost (as John pointed out, register read/write
 > > ports are precious).
 > 
 > Of course, if this were the real tradeoff, no one would ever propose
 > implementing transfers.  The problem is that a store and a load rates to
 > take much more than 3 cycles.

True.  There is a data-point.  I do not know how current SPARC compilers
do it, but in their first version double precision was faster than single
precision.  The reason was that the basic fp-operations were coded in an
inline library, where each operation had its operands in a (integer) register.
For double precision that was the memory address that held the operand, for
single precision it was the value.  The load and store from memory for double
precision operands was faster than the transfer through memory of single
precision operands.  So the total double precision operation was faster
even though the actual on-chip operation takes more cycles.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: gary@minster.york.ac.uk
Newsgroups: comp.arch
Subject: Single instruction machines
Date: 7 Oct 92 16:39:59 GMT
Organization: Department of Computer Science, University of York, England


I just picked up this thread. My student and I built one of these
a few years ago (another student is now working on Mk2). We used
TTL and not very fast logic. It ran at a comparable speed to a
(from memory) 12MHz 68000. Good fun!

We built a move machine. But just for fun I got my first year
students to do a paper design of a subtract machine (yes, one
instruction, and it's a subtract).

Happy days....

cheers...
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: Single instruction machines
Date: 10 Oct 92 01:13:29 GMT
	<1992Oct9.055343.11638@actrix.gen.nz>
Reply-To: jinx@zurich.ai.mit.edu
Organization: M.I.T. Artificial Intelligence Lab.

In article <1992Oct9.055343.11638@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes:

|   Sure, they're only numbered 0 to 7, but the two banks have totally
|   different uses and you simply can't use the 68K data registers, for
|   instance, for everything you can use the PDP-11 registers for.  Unless
|   you limit yourself *totally* to immediate, absolute, PC-relative and
|   SP-relative addressing you can't avoid knowing about the seperate
|   address registers -- and it's hard to imagine a PDP-11 programmer who
|   doesn't use indirect, autoincrement, autodecrement and relative
|   addressing on other than just the PC and SP.

No, you got it backwards.  It is the D registers that are useless. :-)

I know of one Lisp compiler that uses the D registers almost
exclusively as storage locations, and almost all computation (mostly
pointer chasing) is done in the A registers.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 8 Oct 92 14:32:54 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

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.

  The DEC10/20 and the whole GE (later Honeywell) computer line are 36
bits. There were several advantages: it allows support of both 6 bit
(BCD) and 9 bit (ASCII/EBCDIC) characters, and having and extra bit in
the byte allows all characters to be positive with signed bytes,
although this might be more useful in a RISC than CISC environment.

  The 36 bit int/float is also just the right size for real world
programs. When we migrated from GE to IBM we had a number of problems
which simply didn't fit, and a lot of numerical things had to be redone
in double rather than float to keep useful precision. And some things
had to go to the Cray, because the 32 bit int just wouldn't do the job,
and software assisted integer arithmetic is really slow. 

  Remember that the four extra bit of float are all mantissa, so they
really help preserve the significant fp data. And the intermediate on
the GE machines was a full 72 bit mantissa, which helped vastly. A
great deal more numerical analysis is needed to preserve precision when
you have less hardware to help do it.

  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
makes good sense for the vendors, since it doubles the memory needs of
each system.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.arch
From: tresidd@eecg.toronto.edu (Michael James Tresidder)
Subject: SuperSPARC instruction grouping
Organization: University of Toronto
Distribution: na
Date: 9 Oct 92 21:04:46 GMT

Let's try and tap the collective knowledge...

I am working on a project for a grad course that involves simulating a
SPARC 10.  The problem I have is that I cannot quickly obtain good
documentation on TI's SuperSPARC processor.

I did manage to get hold of a paper titled "The SuperSPARC Microprocessor"
(by Greg Blanck and Steve Krueger) from some IEEE proceedings which gives
some information -- but not enough.

The paper mentions seven rules used to determine instruction grouping for
simultaneous issue, and then taunts the readers by informing us that a 
total of 23 rules exist.

I am trying to get hold of all these rules.  Does anyone out there know
them and is willing to enlighten me.

My email address is:   tresidd@eecg.toronto.edu

Thanks in advance for your help.

	- Michael
Newsgroups: comp.arch
From: eesnyder@boulder.Colorado.EDU (Eric E. Snyder)
Subject: Re: Neural networks chips?
Organization: University of Colorado, Boulder
Date:  8 Oct 92 18:32:19 GMT

obiliset@duke.ecs.umass.edu (Sashi V Obilisetty) writes:

>>Are there any chips supporting the concept of neural networks?

Intel makes the 80170NX which is an electrically trainable analog neural network
(ETANN) chip.  It has a 64x64 synaptic array with an update rate around 
2 billion connections per second.  

---------------------------------------------------------------------------
TTGATTGCTAAACACTGGGCGGCGAATCAGGGTTGGGATCTGAACAAAGACGGTCAGATTCAGTTCGTACTGCTG
Eric E. Snyder                            
Department of MCD Biology              ...making feet for childrens' shoes.
University of Colorado, Boulder   
Boulder, Colorado 80309-0347
LeuIleAlaLysHisTrpAlaAlaAsnGlnGlyTrpAspLeuAsnLysAspGlyGlnIleGlnPheValLeuLeu
---------------------------------------------------------------------------
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch
Subject: Re: Other VMS features...
Date: 9 Oct 92 16:08:47 GMT
Organization: Rutgers University Department of Computer Science

In article <1992Oct9.032918.1@cc.curtin.edu.au>, zrepachol@cc.curtin.edu.au
(Paul Repacholi) writes:
| ... the *HUGE* brain death VMS perpetrated on the world ( well, one of them
| anyway... ) was dropping the " underfined " file type. The nearest it will
| let you get is " Fixed, 512 byte ", which soon becomes a nonscense if you
| copy it onto tape with a 4096 byte block size. ( Are these REALY 512 byte
| records, or are they an artifact of the disk block size... ) With the
| undefined file type, you could do as you please, keep RMS and friends
| stickey fingers out of your nibbles, and warn the world that this bitstream
| isn't perhaps quite what it seems.

Oh, then I didn't actually get the following output from the DIRECTORY program
on a VMS V5.5-1 (i.e., latest and greatest) system:

K.Z;1                         File ID:  (7063,23,257)
Size:          195/195        Owner:    [LEICHTER]
Created:  23-JAN-1992 23:40:25.92
Revised:  23-JAN-1992 23:40:39.85 (1)
Expires:   <None specified>
Backup:    9-OCT-1992 00:06:57.10
File organization:  Sequential
File attributes:    Allocation: 195, Extend: 0, Global buffer count: 0
                    No version limit
Record format:      Undefined	<---------------------------------------------
Record attributes:  None
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWED, Group:RE, World:RE
Access Cntrl List:  None

| Another HBD was turning the record size word ( 16 bits ) into a SIGNED int.
| ask anyone who has tryed to copy a backup save-set of >32K blocksize. :={

"The food's *terrible* - and the portions, they're so *small*".

(Yes, actually, I agree with you - record lengths should have been unsigned.
Then again, they should perhaps have been 4 bytes long, rather than 2 - though
why you'd really want to use individual records that long is another question.
Backwards compatibility - with RMS-11 on 16-bit PDP-11 machines, where no one
could imagine setting aside even a 32K buffer - strikes again.

Of course, part of the problem stems from a different source:  ANSI-labeled
tapes use a decimal representation for the length field, so it's impossible
for the maximum length to be the same for tape an disk files, unless you are
willing to arbitrarily limit the size of on-disk records.)

| 
| ~Paul
							-- Jerry
Xref: sparky comp.arch:9923 alt.folklore.computers:15005