HDTenEightyP/NetNews huggingface dataset:
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 11 Oct 92 18:56:37 GMT
Followup-To: alt.folklore.computers
Organization: Auspex Systems, Santa Clara

(Followups to "alt.folklore.computers".)

>The PDP-6 was designed and built before the days of 8 bit character codes -

But was it designed and built before the days of 7-bit character codes?
The PDP-10's OS from DEC used ASCII as the character set for text (it
may have used SIXBIT, or whatever it was called, for symbols in
programming languages and object files, but it used ASCII for text); did
the PDP-6's OS do so as well?

>The first (8-bit) byte-oriented machine was the IBM 360,

Didn't the IBM 7030 - a machine with, as I remember, 32-bit words, and
bit addressibility - antedate the 360?  (BTW, was the 7030 a tube or
transistor machine?  I thought it was a transistor machine, but somebody
else here thinks it was a tube machine.)

I don't think the 7030 was a huge seller, though; I think it was a
specialized supercomputer.  The 360 *may* have been the first
big-selling 8-bit-byte computer, but I could believe that it wasn't....
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 11 Oct 92 15:08:44 GMT
Organization: Taniwha Systems Design

In article <1992Oct6.133255.2382@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>In article <1272@taniwha.UUCP>, paul@taniwha.UUCP (Paul Campbell) writes:
>| process going in each way. These days 'threads' sort of solve the problem
>| by making 'processes' even cheaper. The VMS AST is of course almost the

>  But it doesn't really solve the problem that an i/o completion should
>be treated (or at least treatable) as an interrupt (aka signal).

Well you can by having an inactive thread just sitting there to handle the
completion, it runs as if it was an interrupt - on an MP system you might want
your completion routines to run at the same time as other code ...).

I think that threads are slightly more general than ASTs (this from someone
who ported Unix V6 to run in supervisor/user mode under VMS using threads 
for Unix's processes and ASTs for device driver interrupts ....).

AST's main advantage are in the kernel where they carry such a minimum context
(in particular they carry virtually no VM context) that they can be used
at interrupt time cleanly.

>| Well actually I think that leaving out ASTs and providing cheaper processes
>| probably made it EASIER to program Unix because most people were presented

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

But if you are a programmer new to the system and you get to the section on
how to read data from files and the manual gives you one routine with 3
parameters that do exactly what you want 99% of the time it's "easier to use"

		Paul


-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
	
       	So far the Republican's economic policy is best described
		     as "C'est la vie Capitalism"
Newsgroups: comp.arch,comp.sources.wanted
From: raj@cse.iitb.ernet.in (Gokhale Rajendra V )
Subject: Wanted - Cross compiler for Intel hardware
Followup-To: poster
Keywords: 8031, 8051
Organization: Department of Computer Science,IIT, Bombay
Date: Fri, 16 Oct 1992 04:41:33 GMT

Can someone tell me if there is any Public Domain cross-compiler for 
the Intel 8031 or 8051 available?  If yes, how do I get it?  If no,
is a similar piece of software for some other Intel hardware
available in the Public Domain?

Thanks in advance.
Rajendra Gokhale
raj@cse.iitb.ernet.in
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 14 Oct 92 01:08:49 GMT
Organization: Purdue University Statistics Department

In article <TMB.92Oct13204647@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <BvJsCy.Jnx@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:

>   someone writes:
>   >Getting caught up in details of performance [of random number
>   >generation] AT ALL is a mistake at this point.

>   THIS is totally wrong.  Except for the initial generation of uniform random
>   numbers, almost the entire literature on random number generation is concerned
>   with performance. [lots of random discussions on the difficulties
>   of generating "good random numbers" deleted]

>If the fast generation of random numbers with better properties than
>those that can be generated with current pseudo-random number
>generators were really an important practical problem, you can bet
>that every computer used for scientific computation would include a
>little gadget to generate random numbers based on some physical
>source; the hardware involved is well-known, quite simple, and would
>probably not cost more than a few dollars nowadays (it was more
>expensive when people stopped doing this for lack of interest).

I believe you have pulled things out of context.  There are problems
with getting good uniform random or pseudo-random numbers.  The 
hardware problems for generating good physical random numbers with
a very high degree of uniformity are more difficult than you seem
to realize.

But this was not what was discussed.  The problem is that of getting
non-uniform random numbers.  It was the time performance of the 
procedures for getting non-uniform from uniform which was being
discussed in my passage; this problem is exascerbated by the fact
that totally different procedures, yielding totally different 
answers, are all equally good.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: Too much monkey business. (Was: SunWorld, October 1992, p103)
Organization: Adobe Systems Incorporated
Date: Tue, 13 Oct 1992 18:42:34 GMT

In article <1992Oct12.214726.18831@odin.corp.sgi.com> mash@mash.wpd.sgi.com  
(John R. Mashey) writes:
[Explanation of David Ditzel's comments that the R4000 uses a segmented  
address sapce.]
> 	3) Hence, the published comments should be ignored: they are
> 	explicit mis-representations of the facts...
> 
John is being polite... Such comments should not be ignored, they should be  
used to calibrate people's professional credibility. Both Roger Ross and  
David Ditzel are in positions where they *should* know better than to make  
stupid statements such as have been quoted here recently. Either they are  
incompetent or they are lying. It would be tempting to sue for slander,  
though highly unproductive. I certainly hope someone from MTI writes letters  
of correction to these publications.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Re: Other VMS features...
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group
Date: Fri, 9 Oct 1992 00:27:50 GMT


--
In article <1992Oct9.032918.1@cc.curtin.edu.au>, zrepachol@cc.curtin.edu.au
(Paul Repacholi) writes:

>No, the *HUGE* brain death VMS perpetrated on the world ( well, one of them
>anyway... ) was dropping the " underfined " file type.

File types are there as a convenience for those who want to use them (which,
admittedly, most users do).  But RMS is only a veneer on the real file system,
and the real file system permits you to use those bytes any old arbitrary
way you want.

Or did you really mean "underfined" -- i.e., not fine enough? :-)

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97 (DTN 828-6297)
Newsgroups: comp.arch
From: choy@skorpio.usask.ca (I am a terminator.)
Subject: Wanted: Truth tables for Standard functions
Organization: University of Saskatchewan, Saskatoon, Canada
Date: Thu, 15 Oct 1992 15:52:46 GMT

I'm looking for some truth tables for comparing PLAs. Does
anyone know the functions (or an archive site) named with
these obscure monickers:

adr4
alu1
col4
dc1
dk27
f51m
gary  <- Now there's a good one
in0
in1
in5
misg
radd  (as in raddical :-) )

These functions are supposed to be big (takes a lot of CPU
time according to some people):

cps
mish  (mash)
ti
x2dn
x7dn


Advance Thanks

Henry Choy
choy@cs.usask.ca
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Typed files (was Re: Multi uP P5 systems)
Date: 10 Oct 92 18:40:28 GMT
Organization: Auspex Systems, Santa Clara

(NOTE:

If somebody believes that this thread now belongs in a group other than
"comp.arch" - for example, because they consider the "arch" in
"comp.arch" to refer only to hardware architecture and software
architecture issues dictated by hardware architecture - they should feel
free to move it, but they should do so by posting the followup both to
"comp.arch" and to the new group, and by setting the "Followup-To:" line
to the new group, and should put a note saying they're doing that at the
beginning of the article, so that people who wish to continue following
the thread can do so in the new group, even if their netnews reader
doesn't automatically follow a thread into a new group, or even if they
don't read the new group.)

>As a result:
>
>* Each RDBMS has its own backup and restore facility of varying 
>  functionality, quality, and effectiveness, complicating support for
>  sites adopting more than one RDBMS.

Are you saying that this was not the case on systems that:

	1) had file types

and

	2) had multiple RDBMSes?

And are you then saying that the RDBMSes in question used the OS's file
types (indexed sequential, or whatever)?

Or are you saying that systems with file types end up having only one
RDBMS?

>* Transferring files from system to system under UNIX requires that
>  all layers of functionality be present on both sides to interpret
>  files of arbitrary form and content.  Embedded file systems 
>  ensure that file transfer is enhanced because the interpretation 
>  and manipulation facilities will be there even if the highest
>  layers aren't (ie: you can at least decompose the file).  Find 
>  me one person who guarantees they can decompose an Oracle or Ingres
>  file (ie: someone who has a product that will always do it and 
>  guarantees it'll work for all successive releases of these packages).

Err, are you saying then that the "interpretation and manipulation
facilities" for, say, a Word Perfect document will be present even on
systems that don't have Word Perfect installed?

Are you even saying that the "interpretation and manipulation
facilities" for Oracle or Ingres are present even on systems that don't
have Oracle or Ingres installed?  (That's the same question asked
before.)

I've no intrinsic problem with file types being present on files, as
long as I'm not restricted to the file types the OS designers thought
were Good Ideas.  Does anybody who's had experience with the Apollo
Domain system, which *did* provide an extensible file type system, have
anything to say about how well it really worked (as opposed to how well
somebody thinks it *would* work)?
Xref: sparky comp.arch:9966 comp.lang.misc:3254 comp.software-eng:3784 comp.specification:463
From: dcarr@gandalf.ca (Dave Carr)
Subject: Re: DRAM Controllers
Organization: Gandalf Data Ltd.
Distribution: na
Date: Fri, 16 Oct 1992 13:05:44 GMT

In <6*#@byu.edu> kelly@baloo.ee.byu.edu (J. Kelly Flanagan) writes:


>	Sorry if this is the wrong group, but does anyone have any
>	idea where I can get or who makes modern DRAM controllers?

There is a Canadian company called V^3 (v-cubed) which makes DRAM
controllers for at least the 29K and i960CA.  They can be reached 
at (416)285-9188.
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts.
From: israel@risky.Convergent.COM (Paul Israel)
Newsgroups: comp.arch
Subject: Re: DRAM Controllers
Date: 16 Oct 92 16:02:43 GMT
Organization: Unisys Unix Systems Group, San Jose, CA

From article <6*#@byu.edu>, by kelly@baloo.ee.byu.edu (J. Kelly Flanagan):
> 
> 	Sorry if this is the wrong group, but does anyone have any
> 	idea where I can get or who makes modern DRAM controllers?
> 
> 	I know LSI logic makes one for the SPARC chipset, but there
> 	must be others?
> 
> Kelly
> kelly@ee.byu.edu

   I seem to recall that Signetics made some interesting parts in their
F-line, including a dual-port DRAM interface. They had high-drive outputs,
and were also available with built-in series resistors for matching
impedence on the address lines. I think they could support up to 1 Mbit
DRAMs. Of course, this was a few years ago, and presumably they've
made a few improvements since then...
-- 
Paul Israel -----------------  israel@risky.convergent.com
Senior Smartypants ----------- Unisys Corporation, San Jose, California
Disclaimer: "Who, me? I wasn't even there!"
Newsgroups: comp.arch
From: dbg@slacvm.slac.stanford.edu (David Gustavson)
Subject: Re: DRAMs, etc.
Followup-To: comp.arch
Organization: SLAC
Date: Thu, 8 Oct 1992 01:00:51 GMT

In article <MJOHNSON.92Oct1072916@netcom.Netcom.COM>,
mjohnson@netcom.Netcom.COM (Mark Johnson) wrote:
> 
> Finally, there's a new move afoot to improve Page Mode
> to give incredibly high bandwidth into and out of the
> DRAMs.  Three approaches are being tried: Synchronous
> DRAM (delivering 100 Mbits/sec per pin), Rambus
> (delivering 500Mbits/sec per pin), and CDRAM (whose
> bandwidth I don't know but I suspect it is also
> 100Mbits/sec per pin).
> 
There's also IEEE project P1596.4, RamLink, that supports pipelining.
All communication with the RAM chips is by packets on point-to-point
links (initially at 500 Mbytes/s, faster in future, using differential
signaling). The chips are connected in small ringlets, and each chip
acts like one or more banks of interleaved memory.

For a brief introduction to RamLink and the Low-Voltage Differential
Signaling, see the October issue of IEEE Spectrum (part of a feature
on memory).

--------------------------------------------------------------
-- David B. Gustavson, Computation Research Group, SLAC, POB 4349 MS 88,
    Stanford, CA 94309   tel (415)926-2863  fax (415)961-3530
-- What the world needs next is a Scalable Coherent Interface!
-- Any opinions expressed are mine and not necessarily those
   of the Stanford Linear Accelerator Center, the University, or the DOE.
From: pfister@austin.ibm.com (Gregory F. Pfister)
Newsgroups: comp.arch
Subject: File Types (was: Multi uP P5 systems)
Date: 7 Oct 92 22:54:02 GMT
Reply-To: pfister@vnet.ibm.com
Organization: IBM-Austin, AWD
Originator: pfister@pfister1.austin.ibm.com


In article <1992Oct7.033637.17700@sequent.com>, dafuller@sequent.com (David Fuller) writes:
> In article <1992Oct6.145437.792@infodev.cam.ac.uk> rf@cl.cam.ac.uk (Robin Fairbairns) writes:
> >
> >In article <1992Oct6.133255.2382@crd.ge.com>, davidsen@ariel.crd.GE.COM
> >(william E Davidsen) writes:
> >|> [of VMS]
> >|>   I sure hope so. Any o/s which puts file types in the o/s instead of
> >|> the program is really creating problems for the user, and I find that
> >|> more of a problem than the user interface. If programs really want a "$
> >|> delimited left handed nybble swapped hexadecimal" file type, let it be
> >|> done in the program or shared library, and not at a level when all
> >|> user-written file transfer and backup programs have to deal with it. As
> >|> my youngest says "yucky-poo!"
> 
> Huh?  Let's think about this.
> 
> Tighter integration of file types to the OS are not a problem.  In my
> experience, UNIX offers the weakest file maintenance offerings in the
> industry, save for MS-DOS.  In using Tandem Guardian and VMS I've found
> that ultimately, one could:
>
...
<lots of good words about how things could be better if the OS knew
what it was doing in the file system>
...

You make a fairly convincing argument. But... Well, many if not most
(translation: all I know of but 1) of the "open systems" data base
vendors out there aren't even interested in using the tiny
functionality of the Un*x file system.  They'd rather write direct to
the raw device.  For performance.  And they surely know they're eating
the overhead of doing their own B*Trees, backup, and all the other
utilities you mention.

Maybe it's just that the function offered in "byte stream" files isn't
enough to tip the scales.
-- 
--------------------------------------------------------------------
Greg Pfister                             Sic Biscutum Disintegrandun
Internet: pfister@vnet.ibm.com                 Phone: (512) 838-8338
    VNET: PFISTER AT AUSTIN                      FAX: (512) 838-8909
Newsgroups: comp.arch
From: paul@pphbau.atr.bso.nl (PPH Bauwens)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: Private Node
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 6 Oct 1992 22:28:37 GMT

Didn't you know that they intended to take advantage of future
developments in 9-bit SIMMs.....    :-) :-)

No offense intended to this interesting thread.
-- 
--------------------------------------------------------------------------
Paul Bauwens				Email:	paul@pphbau.atr.bso.nl
Rietkerkweg 364					paul@pphbau.hobby.nl
3066VL Rotterdam  Nederland		Phone:	+31-10-4211858
Newsgroups: comp.arch
Subject: Re: Memory reference sequences
From: adiwan@quick.fox.cs.cmu.edu (Amer Diwan)
Date: Sat, 10 Oct 1992 21:44:32 GMT
Reply-To: adiwan@cs.cmu.edu
Organization: School of Computer Science, CMU

Jim Larus at Wisconsin has a written at tool "qpt" that generates very compact
profiling and memory tracing information.  Here are some references:
	Optimally Profiling and Tracing Programs
	Thomas Ball, James R. Larus
	POPL 1992

	Abstract Execution: A technique for efficiently tracing programs
	James R. Larus
	Software Practices and Experience, Dec. 1990
Hope this helps.
    Amer
--
---------------------------------------------------------------------------
Amer Diwan					School of Computer Science
Fox Project					Carnegie Mellon University
adiwan@cs.cmu.edu				Pittsburgh, PA 15213
(412) 268-3066
From: igb@fulcrum.co.uk (Ian G Batten)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 13 Oct 92 15:07:32 GMT
Organization: Fulcrum Communications

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.

There were four six-bit bytes in a 24-bit word on an ICL 1900 series
machine.  

The small address space implicit in a 24-bit word machine was dealt with
by have most of the memory accessed by adding the contents of one of
four modification registers to the supplied address.  Memory available
without using modification was defined in #lower and there wasn't a lot
of it --- memory that required modification registers to access was in
#upper.

That should be #UPPER and #LOWER, of course: 6-bit bytes means no lower
case.

ian
From: mrc@defender.dcrl.nd.edu (Michael R. Casey)
Newsgroups: comp.arch
Subject: Dynamic ANDF
Keywords: ANDF Distributed
Date: 12 Oct 92 13:38:48 GMT
Organization: University of Notre Dame

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

Thanks for your help in advance.

Michael Casey
Dept. Of Computer Science and Eng.
University of Notre Dame

mrc@defender.dcrl.nd.edu
Newsgroups: comp.arch
From: davidb@dogmatix.inmos.co.uk ()
Subject: Pipelined DRAMs (followup to last week's article)
Reply-To: davidb@dogmatix.inmos.co.uk ()
Organization: INMOS IQ Systems Group, Bristol, UK
Date: Fri, 9 Oct 1992 09:02:57 GMT

Last week someone asked about pipelining on DRAMs.

I've been reading the datasheet for NEC syncronous DRAMs
(part number uPD42116820L). This is a 16Mbit part, clocked
at up to 100MHz (supposedly).

The part definitely allows new addresses to be put in
_before_ all the data from the previous cycle has been
read. The latency is actually a fixed number or ns and so
varies as the clock speed. For example, at 66MHz it is 
five cycles from row address to data.

It is possible to get ``gapless'' streams of data from the
part (the main objective of pipelining a RAM of course !)
and therefore take about 100Mbytes/s from the device.


-- 
David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb
Bristol,  England            |     (us): uunet!inmos.com!davidb
+44 454 616616 ex 547        | Internet: davidb@inmos.co.uk
Xref: sparky comp.arch:9951 comp.lang.misc:3243
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 14 Oct 92 00:46:47 GMT
	<1992Oct2.161500.25379@yrloc.ipsa.reuter.COM>
	<BvJsCy.Jnx@mentor.cc.purdue.edu>
Reply-To: tmb@idiap.ch
Followup-To: comp.arch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: hrubin@mentor.cc.purdue.edu's message of 3 Oct 92 13:34:09 GMT

In article <BvJsCy.Jnx@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:

   someone writes:
   >Getting caught up in details of performance [of random number
   >generation] AT ALL is a mistake at this point.

   THIS is totally wrong.  Except for the initial generation of uniform random
   numbers, almost the entire literature on random number generation is concerned
   with performance. [lots of random discussions on the difficulties
   of generating "good random numbers" deleted]

If the fast generation of random numbers with better properties than
those that can be generated with current pseudo-random number
generators were really an important practical problem, you can bet
that every computer used for scientific computation would include a
little gadget to generate random numbers based on some physical
source; the hardware involved is well-known, quite simple, and would
probably not cost more than a few dollars nowadays (it was more
expensive when people stopped doing this for lack of interest).

The fact that this is not the case makes me suspect that there is no
great practical need, and that Herman Rubin simply underestimates the
performance of current pseudo-random number generators.

But if he really has to solve a problem that requires physical random
numbers, he can build himself a little board and plug it into his PC
(or Cray, whatever the case may be). If he then convinces others that
his algorithms work better then theirs because of that little gadget,
then eventually, we might all get physical random number generators in
our machines (though I doubt it).  It's simple economics at work...

					Thomas.