HDTenEightyP/NetNews huggingface dataset:
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: Other VMS features...
Organization: Curtin University of Technology
Date: Sun, 11 Oct 1992 19:52:37 GMT

In article <1992Oct9.120847.1@zodiac.rutgers.edu>, leichter@zodiac.rutgers.edu writes:
> In article <1992Oct9.032918.1@cc.curtin.edu.au>, zrepachol@cc.curtin.edu.au
> (Paul Repacholi) writes:
...
> File organization:  Sequential
		      ^^^^^^^^^^ Bzzzzt, sorry, no cigar.
> File attributes:    Allocation: 195, Extend: 0, Global buffer count: 0
>                     No version limit
> Record format:      Undefined	<---------------------------------------------
> Record attributes:  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.
> 

Actualy, as a previous poster said, where to from here? I would say that all
systems should allow a uninterpreted bit vector as a file type. Garenteed
un-improved by the OS or anything else. Your format, your problem. Garenteed
non-portable, unless block sizes and everything else is the same...
A larger record size is probably an idea whose time will come before we throw
out what we do now, so a 64 bit UNSIGNED record size would be a good thing IMHO.
The other thing that would be nice to get into place would be a *HUGE* ( 64,
128 bit ) TYPE and a means of generating uinique type numbers for different
formats. Kind of like the Ethernet address block or some such.

Moving to a 4K or bigger 'block-size' would probable not be a bad thing either.

~Paul
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: Whatever became of the DEC 10/20 systems...
Date: 14 Oct 1992 23:52:13 GMT
Organization: University of California; Santa Cruz
Distribution: world
NNTP-Posting-Host: hobbes.ucsc.edu


Sometimes when this quesion comes up somebody will point out that an
architecture with 18-bit addresses doesn't have much future anymore.
Maybe somebody will explain how Honeywell keeps its 36-bit family
alive after you run out of address space.

-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Ya can argue all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"

Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Memory reference sequences
Organization: Metaflow Technologies Inc.
Date: Wed, 7 Oct 1992 23:37:37 GMT

In article <BvrH9K.n1I@pix.com>, stripes@pix.com (Josh Osborne) writes:
|> I have written a (somewhat substandard) cache simulator.  I quickly
|> realised that it can't tell me much without real (or something approxamating
|> real) reference sequences.  Does anyone know where I could find either
|> a large file with a reference sequence, or a way to gennerate reasonable
|> approxamations (code, or algos would be great)?

The way I handled this situation was to instrument our simulator and
run it on a few different programs, to produce compressed, preprocessed
memory trace files.

My memory trace data wouldn't help you, since it was designed
specifically to challenge various TLB configurations.  Also, it's
rather large, and buried on an archive tape, somewhere...
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Memory reference sequences
Organization: Intel Corp., Hillsboro, Oregon
	<^*#@byu.edu>
Date: Tue, 13 Oct 1992 04:48:44 GMT

    ...Request for memory reference sequences
    ...Discussion of on-the-fly collection/simulation tecniques
    ...etc.

You want a *really* *good* public service project for the
computer architecture community?

Publish a CDROM or optical disk with a number of (reasonably)
compressed memory access traces, and their C decompression routines.


If somebody in academia would be willing to do the footwork for this,
you might be able to get some people in industry to contribute their
(old) traces.  (Not the latest traces, since that's what makes or
breaks a project.  But even 5 year old data would help academia.)


--

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)
From: jgd@csd4.csd.uwm.edu (John G Dobnick)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 8 Oct 1992 19:48:15 GMT
Organization: University of Wisconsin - Milwaukee
Reply-To: jgd@csd4.csd.uwm.edu
NNTP-Posting-Host: 129.89.7.4
Originator: jgd@csd4.csd.uwm.edu

From article <1b1sjbINN9jb@darkstar.UCSC.EDU>, by haynes@cats.ucsc.edu (Jim Haynes):
> 
> 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.

Univac/Sperry/Unisys 1100 series (and now, 2200 series) machines are also
36 bit word machines.  6 bit characters _used_ to be the norm, but all
current software is essentially ASCII, using 9-bit characters.  And, yes,
C compilers exist for these machines, as well as ports of Unix.  

Tromping through character strings really isn't all that bad.  Some
models have hardware support for character fiddling, but even without
that, a fairly simple software based scheme (using remote execute
instructions and a couple of index registers) allows character
addressability without excessive pain.

I agree that having a "power of 2" number of "bytes" per word is _very_
convenient.

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

Yes, a bit (arg! :-)) of a problem.  There are two approaches. 

     One is to write 8-bit bytes to the 9track tapes, using only the
     lower 8 bits of each character (quarter-word).  This only transfers
     32 of the 36 bits in a word, which is fine for EBCDIC (IBM)
     compatibility and strictly character data.

     The other approach is to write all 36 bits as a "packed" entity;
     as a "bit stream" to the tape.  Now, you will notice that if you
     write an odd number of words, you have 4 bits "left over".  On
     writes, pad this with 4 zero bits.  On input, you can drop them.
     If you do a _backward_ read on such a tape record, you're in deep
     doo-doo (:-)) -- characters won't line up properly on word boundaries.
     Thus, it was recommended that one _always_ write an even number of
     words per block when using the "packed" mode.

-- 
John G Dobnick (Exec-8 Guru, ret.)      ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: Typed files. (Was: Multi uP P5 systems)
Organization: Adobe Systems Incorporated
Date: Wed, 7 Oct 1992 17:13:21 GMT

In article <1992Oct7.033637.17700@sequent.com> dafuller@sequent.com (David  
Fuller) writes:
> Just because you CAN do something in user programs does not mean it's 
> a terribly good idea to enforce it as policy.  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...  

Or ride a bicycle. Nowget this shit out of comp.arch. Long term readers of  
this group (which includes most of the posters in this thread) should damn  
well know that OS flames are unproductive and better discussed in other  
newsgroups.
--
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
Newsgroups: comp.arch
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: SNake Island Research Inc, Toronto
Date: Thu, 15 Oct 92 00:35:51 GMT

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]

This ^^^ is totally wrong. We START by getting a specification for
the numbers you (Herman) want to produce. THEN, you worry about HOW
to produce them efficiently. WE (your audience) are still trying to 
understand the problem. Once we understand it, AND NOT UNTIL THEN,
we can propose solutions. Therefore, we STILL are seeking the specification,
as a SIMPLE program in some common language such as Fortran or C.

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

This is not exactly correct. ANY uses which I have for random numbers
REQUIRE that they be reproducible. Otherwise, comparing algorithms, 
ensuring that your last bug is fixed, etc., is IMPOSSIBLE.
So, if the "little gadget" gave reproducible results, that would be fine.
If not, it's useless for many purposes.

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

I suggested to Herman some time ago that an ASIC (Application-specific
IC) or PGA (Programmable Gate Array) on a prototyping board stuck into
his machine might be a cheap, simple, and effective solution.


Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.arch
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: Single instruction machines
Date: Thu, 8 Oct 1992 14:40:34 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <718475999.25403@minster.york.ac.uk>, by gary@minster.york.ac.uk:
> 
> 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).

One reference, for those who want to explore move machines, is my paper:

``The Ultimate RISC,''
Computer Architecture News, 16, 3 (June 1988) 48-55.

This paper covers a basic single-instruction move machine, then discusses
how to add to this foundation with additional memory mapped functionality
to make it competitive with PDP-11 class architectures (or 68000 -- 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!)

The paper ends with a section describing how to pipeline such a machine,
using a 3 stage pipe and a 4 port memory to get all the problems of a
non-blocking RISC -- two branch delay slots and one move delay slot
are needed.

I had a student who did a project on how to do interrupts on this machine,
but I haven't fully digested his work.  Interrupts in pipelined machines
are a mess, particularly when the pipeline has no interlocks and you don't
want interrupts to introduce anything other than single-cycle execution.

					Doug Jones
					jones@cs.uiowa.edu
From: jtien@venice.eng.uci.edu (Joe Tien)
Subject: DRAM cycle time
Newsgroups: comp.arch
Reply-To: jtien@venice.eng.uci.edu (Joe Tien)
Organization: University of California, Irvine
Date: 10 Oct 92 03:42:22 GMT

I'm lost!

Could someone tell me how people use DRAMS in a computer system. The data sheets
only give the minimum cycle time (approx. 140 to 260 nSec.) Unless I misread, the
maximum cycle time (read or write) is not listed anywhere.

How would a designer choose the DRAMs. More importantly, how does the processor
know when the instruction is fetched from memory (assuming no cache.) I can see
how interrupts may work, but wouldn't that be too time consuming?

Getting more specific toward my problem ...

I'm trying to evaluate the performance speedup of a RISC with and without cache.
What should I use as the read cycle time? If I use only the best case (minimum),
then my results wouldn't be very meaningful, would it? If the cycle time is
implementation dependent, what parameters should I look at? DMA? DRAM controllers?

Post or email, I'd appreciate any help on this.

Thanks much,

Joe Tien
jtien@balboa.eng.uci.edu
From: nickh@CS.CMU.EDU (Nick Haines)
Newsgroups: comp.arch
Subject: Re: Dynamic ANDF
Date: 16 Oct 92 15:43:11 GMT
Article-I.D.: VOILA.NICKH.92Oct16104311
	<1992Oct12.184334.15703@osf.org> <1992Oct16.051950@eklektix.com>
Organization: School of Computer Science, Carnegie Mellon University
Originator: nickh@VOILA.VENARI.CS.CMU.EDU

You should ask about on comp.compilers for this. Good keywords are
TDF and ANDF. The moderator should be able to dig out the recent post
from Nic Peeling at DRAE.

Last year I was working on a similar project (which is still ongoing),
and built up a bibliography of UNCOL and descendant projects.
Unfortunately it's out on a tape somewhere. The whole problem is
related to that of compiler-generation (in fact the project I worked
on considered (as one solution) describing source language and target
architecture in some meta-level representation and then generating a
suitable intermediate representation from that).

The key problem with UNCOL and later projects is that an intermediate
representation capable of describing all source language semantic
idiosyncrasies and all target machine quirks (which such an IR
supposedly must do in order to compete with custom compilers) will be
so enormous and gnarly that writing a new back-end or a new front-end
will take longer than writing a whole new compiler, and the resultant
UNCOL compiler will be slow and clunky.

It _seems_ that the TDF project gets around this problem.

Finally, I don't think it's fair (to either side) to compare Backus'
FORTRAN compiler with the compilers of today. FORTRAN (as it was then)
would not even qualify as a `high-level language' these days (FORTRAN
as it is now only does by momentum). Many of the structures of modern
languages were not provided for (or dreamed of), and many aspects of
modern target architectures did not have to be contended with.
Certainly it was an excellent piece of software, but so are many
modern compilers.

Nick Haines nickh@cmu.edu
Newsgroups: comp.arch,comp.lang.misc,comp.specification
From: dhd@exnet.co.uk (Damon)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Wed, 14 Oct 1992 19:44:37 GMT

In article <1992Oct14.040754.14470@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>
>Overloading is _not_ ambiguity.  Overloading in one manner in which a
>context-free language becomes a context-sensitive language.  My point
>is that in a (good) programming language, constructs have a clearly
>defined meaning, and are unambiguous.  Programming languages can handle
>overloading unambiguously because they have formal rules for
>interpreting context.  Mathematical notation has no formal rules for
>resolving ambiguity.  Formal languages are a necessity in programming,
>but are not in mathematics.
>
>Please note, I am _not_ saying mathematical notation is flawed for the
>purposes of math.  Mathematical notation has been serving the needs of
>mathematitions for decades.  I am saying that mathematical notation, as
>it is defined now, is too informal to serve as a programming language.

Which is why (I may be starting a new thread here, or have missed
something earlier), Z is not much good as a *specification* language
since it just uses any mathematical construct you care to employ.  SML,
on the other hand, even though it is not completely characterised, is
much nearer the mark and can actually execute too.  Quite quickly in
fact, since what optimisations are permissible can be worked out...

CCS is a great spec language for concurrency.  Might make a good
parallel asm language.

In fact I've done CCS -> SML -> C, but actually demoed the SML in
real-time for a network router.

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.28|| Cheap Sun eqpt available.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || Mail/news feeds available.
--------------------------+----------------------++---------------------------
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
Newsgroups: comp.arch
From: rsnider@xrtll.uucp (Richard Snider)
Subject: Whatever became of the DEC 10/20 systems...
Organization: WCOM Public Access Unix - Toronto
Date: Tue, 13 Oct 1992 17:58:03 GMT
Summary: What happened to the Jupiter Project ??

I am curious as to what happened with DEC's Jupiter project to
replace the Decsystem-10 or 20's with something faster...  I belive
it was called the Jupiter Project and I heard that it died..  

Does anyone know why ??

Various sources here comment on the fact that the KL CPU took too
much power for what it did, to word-size, etc...

                                           ....Rich
                                       rsnider@xrtll
From: rw@dcs.ed.ac.uk (Robert Walker)
Newsgroups: comp.arch
Subject: HELP: Processor implementation
Date: 16 Oct 92 20:20:53 GMT
Organization: Department of Computer Science, University of Edinburgh


Hi,
   I am (hoping!) to implement the DLX architecture (from `H&P') as my 4th
year (undergraduate) project (using a VLSI silicon compiler package).
However, I am running into some major stumbling blocks. The 2 major ones being
VM support (TLB lookup hardware support/cache update on miss/etc) and
trap/exception handling (especially internal traps which must be
restartable). I hope to simulate the processor initially, so I need to define
an RTL implementation which supports trap-handling and VM at some (as yet
undefined) level.
   Basically I would gratefully receive any tips/hints on for example -
     * how traps are/might be prioritize
     * how many must be held at once (for the trap handler)
     * how the state of the pipeline might be maintained/recorded
     * etc.
   Emailed references to technical papers/books or direct hints/technical
experience shared would be gratefully received!! Sorry to waste net bandwidth,
but all the references I have chased up, so far, simply do not provide enough
IMPLEMENTATION DETAILS (and I do _not_ refer here to gate-level)!

           Thanks (in advance)
              Rob


-------------------------

Email at: rw@uk.ac.ed.dcs
From: ALAN@VM1.McGill.CA (Alan Greenberg)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 13 Oct 92 13:56:35 GMT
Article-I.D.: VM1.1687F8BDA.ALAN
Organization: McGill University

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.
>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.
 
 The IBM 7040/7044 was a 36 bit machine which did have character
 operations.  Specifically, it had a Compare Character with Storage,
 Place Character from Storage and Store Accumulator Character.
 All three used the last 6 bits of the accumulator and a specified
 character of a word in storage.  In the Store, the remaining 5
 characters of the word we re unchanged.
 
 This certainly did not make them character-oriented machines,
 but the architecture did acknowledge and support such use.
 
 Alan
Newsgroups: comp.arch
From: windy@kaa.informatik.rwth-aachen.de (Andrew J. S. Miller)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: RWTH-Aachen, Deutschland
Date: Thu, 8 Oct 92 13:28:08 GMT

Once upon a time characters were 6 bits long not 7 or 8.
since 6 * 6 = 36 one can store an exact number of characters in a 
machine word. 32 bits would have left 2 bits unused.

CDC built 60 bit machines for this reason...
-- 
--------------------------------------------------------------------------------
email: windy@strange.informatik.rwth-aachen.de
snail: Ruetscherstr 165  D-5100 Aachen
voice: 0049 (0)241 159 484 or 8021122
Newsgroups: comp.arch
From: Bruce.Hoult@bbs.actrix.gen.nz
Subject: Re: Single instruction machines
Organization: Actrix Information Exchange
Date: Sat, 10 Oct 1992 10:24:16 GMT

In article <JINX.92Oct9201329@chamarti.ai.mit.edu> jinx@zurich.ai.mit.edu writes:
>
> 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.

:-)

Sure, you can do a lot with the address registers if you restrict yourself
to indirection and adding constants to registers and don't care about
subtraction or the other operations and you don't care about setting
condition flags and branching on the results.  You can even add two
address registers *and* an 8 bit constant in one hit using LEA nn(An, An).


When I first moved from the VAX (with 16 general purpose registers) to
the 68000 (with 8 data and 8 address registers) I was quite worried
that I'd be forever moving things back and forth between the two sets
of registers, but this just doesn't happen in practice.  OTOH, if you
couldn't use a data register as an index register you *would* have to
do a lot of shuffling about, I think.

Overall a pretty well designed processor, I think.  (and my Quadra
moves along quite nicely too :-)

-- 
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?"