HDTenEightyP/NetNews huggingface dataset:
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: OS/MFT and Macintosh (was: ..History)
Date: 27 Aug 92 12:58:26 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 26 Aug 92 15:04:29 GMT, smith@sctc.com (Rick Smith) said:

smith> (Piercarlo Grandi) writes:

pcg> Hey, the Mac OS technology is middle sixties vintage (OS/MFT!),

Typo: I meant MVT...

smith> As a point of fact, OS/MFT's operating system technology bears
smith> almost resemblance to the Mac OS.

Ah yes, of course. That they both provide memory resident tasks, a
single address space, and other fairly primitive facilities does not
matter a lot. MVT had limited paging/swapping of task pages, just as the
newer System 7 has, even if an argument can be made then that System 7
is more like SVS.

smith> OS/MFT provided a "flat" file system.

Really? That's news.

smith> OS/MFT provided a _fixed_ number of concurrently active
smith> tasks, while the Mac OS is limited by the available memory (at
smith> least in my experience).

I meant MVT, sorry. But there is little difference between MFT and MVT
anyhow. 

smith> Most important, the Mac OS is nonpreemptive, which enforces a
smith> completely different scheduling regime on the OS and its
smith> executing software.

And so what? That means that it is even more primitive than OS/MVT. At
least OS/MVT had some rudiments of scheduling, job scheduling, and many
other things that are lacking in the Mac OS.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
From: vail@mamacass.etdesg.trw.com (Steve Vaillancourt)
Newsgroups: comp.arch
Subject: Re: Error Correcting Memory
Date: 4 Sep 92 18:24:03 GMT
Distribution: usa
Organization: TRW
X-Xxdate: Fri, 4 Sep 92 11:21:53 GMT
X-Useragent: Nuntius v1.1.1d7

Error Correcting Memory
to Spencer Shafer

from Steve Vaillancourt 
email vail@mamacass.etdesg.trw.com

Here's a short list of some of the better articles:

Reliability of Scrubbing Recovery Techniques for Memory System
by Saleh, Serrano & Patel, IEEE transactions on Reliability Vol.39
No.1, 1990 April

Reliability Modeling and Analysis of Fault-Tolerant Memories
Cox & Carroll, IEEE Transactions on Reliability, Vol R-27, No.1, April
1978

The Reliability of Single-Error Protected COmputer Memories
Balum, Goodman, Mceliece, IEEE Transactions on COmputers, Vol 37, No. 1,
Jan 1988

Reliability and Performance of Error-Correcting Memory and Register Arrays
Elkind & Siewiorek, IEEE Transactions on COmputers Vol C-29, No.10, Oct
1980

Fault-Tolerant Design Techniques for Semiconductor Memory Applications,
Aichelmann, IBM Journal of Research & Development, Vol 28, No.2, March
1984
Newsgroups: comp.arch
From: smith@sctc.com (Rick Smith)
Subject: No progress in parallelism? (was: History)
Organization: SCTC
Date: Wed, 26 Aug 1992 15:30:25 GMT

I wrote:

>smith> I think the future of computer architectures is in various forms
>smith> of parallelism not addressed by the von Neumann tradition.

And pcg@aber.ac.uk (Piercarlo Grandi) replied:

>Pious hope, I am afraid. Research in this field has been going on
>forever, and without much progress. Architectures here seem wedded to
>particular application shapes, and almost all variations have been tried
>out, and only a few have been found cost effective. But some particular
>application shapes are so important...

It should be clear from von Neumann's writings that multiprocessing
was never part of his model. However, I think it is fair to say that
the cost effectiveness of multiprocessor configurations has been well
established. I think it's also fair to say that many of the "big issues"
these days (cache management comes immediately to mind) are driven
by parallelism problems.

Most programming languages (and programmers) are oriented towards
program structures that fit the von Neumann mold. That may restrict
instruction set architectures, but it doesn't eliminate other forms
of parallelism at higher levels in the system.

Rick.
smith@sctc.com            arden hills, minnesota
From: yvent@theseas.ntua.gr (Yiannis Ventikos)
Subject: MARKET SURVEY FOR MASS. PARALLEL MACHINES
Apparently-To: comp-parallel@mcsun.EU.net
Summary: PARALLEL MACHINES
Keywords: MASS PARALLEL
Organization: National Technical University of Athens
Date: Tue, 1 Sep 1992 10:37:20 GMT



            MARKET SURVEY FOR MASS. PARALLEL MACHINES

We are checking the market for a massiv. parallel machine. We got no specs so
far, just price ranges:

Class a) Up to two  million US dollars ($2 000 000)
Class b) Up to four million US dollars ($4 000 000)
Class c) Up to six  million US dollars ($6 000 000)

Since this is an initial survey, we do not want to exclude anything, so the
definition "massiv. parallel machine" is to be taken in the broadest sence.
Any input is wellcomed, ranging from simple info like :
"XYZ  costs $2.3M"
to
"ABC with n processors, M Mbytes, G Gigaflops..."
up to 
"We have purchased a FGH and have been using it for... Our experience..."

Any and all answers will be appreciated. 
E-mail at the address at the end of this message is better, if too 
difficult just followup.
-------

******************************************************************************
* Yiannis Ventikos                              *        DISCLAIMER          *
* Viscous Flows Group,                          * Any and all opinions that  *
* Dept. of Naval Arch. & Marine Eng.,           * I have  expressed  so far  *
* National Technical University of Athens,      * reflect  thoughts of mine  *
* P.O. Box 64070, GR-15710, Zografos, GREECE    * and  mine alone and  have  *
* Voice: (301) 7700405                          * nothing  to do  with  the  *
* Fax:   (301) 7774478                          * policy of the  Department  *
* e-mail: yvent@areti.marinentua.ariadne-t.gr   * I currently belong to.     *
******************************************************************************
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: Indexing in microprocessors
Date: 3 Sep 92 02:18:32 GMT
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: ugurdag@ces.cwru.edu's message of 2 Sep 92 00:25:25 GMT

Computers that store the registers in memory can do the indexing, including
the PDP-10 (and 20, but *not* the PDP-11), some Honeywell machines
(predecessors to the Multics line), and the TI 9900. Some register window
mechanisms may let you do this (sort of), but most processors do not seem to
do it in the manner you have described. Some machines could get that effect by
building and executing an instruction, or having an "execute" instruction.
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
Newsgroups: comp.arch
From: feustel@netcom.com (David Feustel)
Subject: Re: Indexing in microprocessors
Date: Wed, 02 Sep 92 00:43:30 GMT
Organization: DAFCO: OS/2 Software Support & Consulting

ugurdag@ces.cwru.edu (Fatih Ugurdag) writes:


>Is there any microprocessor in which we can access registers in an
>indexed fashion such as

>"store source_register,register[index_register]"
>if index_register holds the value of 3 then this becomes
>"store source_register,register3"
>This way we can support array operations in the register file.

I think several pdp computers (including the pdp11) had this
capability as the registers could be addresses as memory locations.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
( New .sig under construction. Watch this space! )
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.arch
Subject: Re: A Little History
Date: 23 Aug 1992 17:34:55 -0400
Organization: Berkeley Software Design
NNTP-Posting-Host: rodan.uu.net

Learning history of science and engineering is valuable
not for the knowledge of random trivia like the name of
inventor but for the understanding WHY the modern technology
is as we behold it now. It's also a perfect lesson on
methods of making new inventions. We all have a lot to learn from
the people who left their names in the history of technology.
And, after all, the new solutions can often be inspired by
ideas which were impractical at the time and nearly forgotten.
Need i remind that high-tech buzzwords like "object oriented"
and "neural networks" are in fact modern wrappings for ideas
which can be found in books of Neumann and Shannon? That early
machines were surprisingly RISCy? As Russian proverb says: "All
new is well-forgotten old".

Therefore i consider history is quite relevant in comp.arch.

--vadim
Newsgroups: comp.arch
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops
Date: 27 Aug 1992 18:06:56 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

I'm a little bit mystified by the expensive approaches described here.

First, speculative division is probably not an interesting case.
There are vastly more loads and stores than divisions.

However, having a "division" operator that traps is equally
ridiculous.  On some machines (those that implement WORD/WORD -> WORD)
division, instead of DWORD/WORD -> WORD) the check for overflow (if
you care at all) is pretty simple -- division by zero for the unsigned
case, and (for signed) division by zero and division of MININT (i.e.,
0x8000000) by -1.  That's it.  There are some moderately entertaining
code sequences of the superoptimizer variety for detecting these
things, when you care, and you can overlap the detection with the
division if they are allowed to proceed asynchronously.

As far as loads and stores go, I am similarly mystified by the
insistence that each and every trap from the source program be
preserved in "very-optimized" code (not code compiled for debugging,
or at a "normal" level of optimization).  For instance, (as has been
noted by several people before me in more severely refereed forums),
if page zero is mapped readable, then you can transform

  if (px != 0) x = *px;

into

  x' = *px;
  /* insert other stuff here, perhaps, to cover the latency. */
  if (px != 0) x = x';

No hardware support is required, but some other traps might be lost.

If the OS could be convinced to just not report illegal loads
(emulating them as returning zero or NaN, for instance) then loads
could be hoisted much more frequently.  This doesn't work quite
perfectly -- if you store a tag in the last two bits to distinguish
integers from pointers, you can lose big, because all the loads will
trap to the OS -- however, it's also feasible to profile your
failures, and not speculate on those loads in the next compilation.
Or, your hardware (in the style of the IBM PC/RT) can silently
truncate away those bits and not trap anyway.

Note that the hardware support for what I described above is pretty
damn cheap.  Note that no changes are needed to the architecture.  The
only cost incurred is the slightly reduced locality of reference; all
those extra loads may result in extra paging.  (Someone should study
this, I think.  I'm a little worried about binary search trees.  If
someone is really interested, send me mail.)

Remember, we've got tools to help us debug our code.  There's Purify,
and Centerline (formerly Sabre C), and something that I saw mentioned
in one of the GNU lists that I wish I had made a better note of
(anyone able to send me a reference, I'd be quite grateful).  People
should use these tools anyway, because there's a whole world of bugs
*not* caught by the hardware and OS that slips by otherwise (no saint
like a converted sinner, if you know what I mean, and I think that you
do).

David Chase
Sun
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: Natural Word Size (was Re: 32 => 64 Transition
Date: 27 Aug 92 03:26:47 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mti.sgi.com

In article <1992Aug25.142208.18792@bcars64a.bnr.ca> schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
>In article <DOCONNOR.92Aug24135056@potato.sedona.intel.com> doconnor@sedona.intel.com (Dennis O'Connor) writes:
>>
>>] Clearly, for an archtecture family, there is *no* natural word size. At
>>] best, there is a "prefered" size that is defined by the architecture that

I agree with Stanley: I have some skepticism about the faith placed in the
meaning of "natural" word sizes, especially since:
	a) Compilers *usually* target an architecture family in a consistent
	way ... but optimality of choice depends on the specific
	implementation within a family.
	b) At least some of this derives from wording inherited from the
	past which may well have been purposefully fuzzy, i.e.:

	- In the C Reference Manual, 1974, there is no menion of "natural"
	sizes of anything.... in fact, ints are described as:
	"Integers (int) are represented in 16-bit 2's complement notation."
	(of course, to be fair, this was before longs existed ...)
	- In K&R (2nd edition) it says:
		"int   an integer, typically reflecting the natural size
		of integers in the host machine"
	and later:
	"int will normally be the natural size for a particular machine."

	- If you know K/R's normal parsimony of words, the inclusion of
	the qualifiers "typically" and "normally" may be significant.... :-)
n
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
DDD:  	408-524-7015,  or 524-8253
USPS:	(soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
From: karim@cs.rice.edu (Karim Esseghir)
Newsgroups: comp.arch
Subject: RS/6000 TLB
Date: 26 Aug 92 13:52:47 GMT
Reply-To: karim@cs.rice.edu (Karim Esseghir)
Organization: Rice University, Texas
Originator: karim@athene.cs.rice.edu



Hello,

Can anybody email me the RS/6000s TLB specifications? I know they
are two-way set associative but I couldn't find their size in number
of entries.

Thanks.
-- 
_______________
Karim Esseghir					     Office: HB 02
Rice University, Dept. of Computer Science	     (W): (713) 527-8750 x2352
Houston, Texas.					     (H): (713) 520-0536
Newsgroups: comp.arch
From: pmontgom@math.orst.edu (Peter Montgomery)
Subject: Re: trapping speculative ops (LONG)
Organization: Oregon State University Math Department
Date: Tue, 1 Sep 1992 02:42:00 GMT

In article <1992Aug31.224611.5196@odin.diku.dk> thorinn@diku.dk 
(Lars Henrik Mathiesen) writes:
>To summarize: trap bits are proposed to enable a compiler to move a
>potentially trapping operation outside of a condition. As a special
>case, this would allow many, if not all, of the same optimizations
>that can be done if a load through a NULL pointer yields zeroes.

	On the early models in the CDC Cyber series, such
as the CDC 6400 and 6600, floating point errors
(e.g., overflow, division by zero) generated special
results (e.g., indefinite quantity).  They did not generate
a trap until those NaN-like results were used as operands
to other floating point instructions.

	Sometimes, as in A = B + C/D where D = 0,
the error would be detected a few instructions after
the NaN-like result was generated and used as another operand.  
Often, however, there would be a long gap.  
Certain operations like converting an indefinite quantity to integer 
generated no trap.  Since integer division used floating point 
instruction, the code I/J where J = 0 could proceed without a trap.

	The behavior changed on some later models, like the CDC 7600.
Those models gave a trap whenever the bad result was generated
(or a few instructions later).  It was often possible, when looking 
at core dumps, to see the bad operands still in the registers.
-- 
        Peter L. Montgomery              Internet: pmontgom@math.orst.edu
        Dept. of Mathematics, Oregon State Univ, Corvallis, OR 97331-4605 USA

Energy conservation principle:  It doesn't matter.
From: fritz@gems.vcu.edu (Fritz)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops
Date: 28 Aug 92 12:38:39 -0400
Organization: Medical College of Virginia

In article <CLIFFC.92Aug27082745@medea.rice.edu>, 
  cliffc@rice.edu (Cliff Click) writes:

[...]
> <Cliff Click>
> || Let every register have some extra "trap" bits.
> || A read of the register with it's trap bits set, causes the exception.
> || A write to the register sets the trap bits according to the success of
> || the operation.
> || 
> || With this design, exceptions are triggered at the START of some operation,
> || instead of in the middle of it.
> 
> <Stanley T.H. Chow>
> | Very nice model, but what to do about saving and restoring registers
> | across subroutine call, interupts, etc.?
> 
> <Cliff Click>
> Soft answer:
> The compiler knows that live and possibly dangerous results cannot be 
> carried across a subroutine call.  Therefore it uses every possibly 
> dangerous result before the subroutine call.  This means you cannot 
> lift that divide-by-zero across the subroutine call.
> 
> Hard answer:
> The hardware allows these bits to be read and written using a special 
> register.  The special register can be "slow" because it's assumed to be
> an infrequent operation.  The trap bits are saved and restored along with
> the registers.
> 
> Interrupts appear to require the "hard answer", but there is another way
> (albeit possible worse):
> 
> Harder Soft answer:
> Only 1 interruptable condition can exist at a time.  The compiler forces the
> issue by using the possible dangerous register before it allows another 
> operation which can cause a dangerous register.  External interrupts are
> disabled while a dangerous register exists.  The compiler ensures that no
> register is kept dangerous for longer than the desired interrupt latency.
> Since only 1 interrupt can occur at a time, no trap bits need to be saved
> or restored.
> Scheduling restrictions in this answer are probably worse than implementing 
> the hardware solution.  I have no idea what you can implement cheaply in
> hardware.
> 
[...]
> Stanley Chow            schow@BNR.CA
> Cliff Click             cliffc@cs.rice.edu
[...]

A hardware answer for interrupts only that might be easier to implement
would be to say that during interrupt service, the trap bits are not set
on writes, and are ignored on reads.  Any operation that would
ordinarily trap is undefined during interrupt service: it might put
garbage in the register, (possibly _after_ returning from the interrupt).
You'd have to be pretty confident that the interrupt routines didn't
divide by zero and so forth--but you have to be pretty confident in the
correctness of your interrupt routines with any architecture.

You'd use the software answer for subroutine calls.
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Newsgroups: comp.arch
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted
Date: 2 Sep 92 05:51:33 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

KGZXK@ASUACAD.BITNET (Zafer KADI) writes:

> About having global variables or not and if making calls slows the program
> and optimization:  Yes it does.  ....  Do you want the program to be faster
> or
> clearly written for your own standards.

Whether or not making lots of subroutine calls slows up a program depends on
the hardware.  It slows up CPUs designed for languages such as C or Fortran. It
does not slow up CPUs designed for Forth, in which a program might have fewer
than ten core words per call.  These processors have minimal overhead for
calls, taking one clock cycle to call, and zero cycles to return.  These CPUs
have a major effect on programming style: what constitute "good" and "bad"
techniques.

Read "Stack Computers, The New Wave", by Phillip Koopman Jr. for a good
explanation of these CPUs and a different (better!) approach to programming.

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.arch
From: smith@sctc.com (Rick Smith)
Subject: OS/MFT and Macintosh (was: ..History)
Organization: SCTC
Date: Wed, 26 Aug 1992 15:04:29 GMT

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>Hey, the Mac OS technology is middle sixties vintage
>(OS/MFT!),

As a point of fact, OS/MFT's operating system technology bears almost
resemblance to the Mac OS. OS/MFT provided a "flat" file system. OS/MFT
provided a _fixed_ number of concurrently active tasks, while the Mac
OS is limited by the available memory (at least in my experience).

Most important, the Mac OS is nonpreemptive, which enforces a
completely different scheduling regime on the OS and its executing
software.  I'm not going to argue the relative merits of preemptive
versus non, since I've seen several such threads in the past six
months.

Rick.
smith@sctc.com              arden hills, minnesota.
Xref: sparky comp.sys.apple:25 comp.dcom.modems:12928
From: ostroff@oswego.Oswego.edu (Boyd Ostroff)
Newsgroups: comp.sys.apple,comp.dcom.modems
Subject: Terminal Emulator for Apple //e
Date: 3 Sep 92 21:27:36 GMT
Reply-To: ostroff@oswego.Oswego.edu (Boyd Ostroff)
Organization: Instructional Computing Center, SUNY at Oswego, Oswego, NY
Originator: ostroff@cloy.oswego.edu

We have an 128K Apple //e (and also a 256K memory card if that matters)
with duo-disk and monochome monitor.  Since it is not seeing any productive
use I was hoping to use it as a terminal emulator.

Now I don't use Apple II's anymore, but I used to, and even bought one of
the very first.  Anyway, I have an old emulator called "Pro Term" and
when I tried using it with the //e at 9600 baud it was pretty worthless.
The first line or two of output was fine, then as it continued down the
screen more and more characters were missing until it degenerated into
complete gibberish.  Evidently the //e and Super Serial Card just can't
handle 9600 baud.

Next I tried it at 2400 baud.  The results here were a little better, but
there were still characters dropped.  Also, the emulator does not support
vt100 and the vt52 emulation didn't work quite right with my unix termcap.

So is there any hope for using the //e as a vt100 (or anything in /etc/termcap)
at 9600 baud?  Is this just asking too much from the good ol' 6502?  I
have an old (DOS 3.3 ?) version of Apple II Kermit, but I couldn't get
it to work at all.

I really hate seeing this machine gathering dust and we could use another
terminal, but it has to be 9600 baud capable to hook directly into the
campus data system.  I'd appreciate e-mail from anyone with experience in
this area.  If there are newer versions of Kermit for ftp, please explain
how to convert them to Apple II format once I download them, since I'm
not familiar with getting Apple II binaries off the net.  Thanks!

.............................................................................
....Boyd Ostroff / Technical Director / SUNY Oswego Department of Theatre....
...............Voice: (315) 341-2987 /  Fax: (315) 341-3394..................
..............ostroff@oswego.oswego.edu / ostroff@cboard.UUCP................
From: shk@gserv1.dl.ac.uk (Steve Kinder)
Newsgroups: comp.sys.sgi
Subject: Re: Looking to read old VMS backups on my Indi
Date: 28 Aug 92 08:07:26 GMT
Reply-To: shk@gserv1.dl.ac.uk
Organization: Daresbury Laboratory, UK

In article 9996@magnus.acs.ohio-state.edu, hshamans@magnus.acs.ohio-state.edu (Harry T Shamansky) writes:
> 
>   Hello...
> 
>   I am woefully looking to read some old VMS backups onto my Indigo.
>   Another user asks for the ability to take a 4mm DAT tape written on 
>   a vaxstation under vms backup, and hope to extract the files in that
>   saveset.
> 
>   I know that there are some commercial packages which can do all sorts
>   of vms-like stuff, but all I want to do is extract the pertinent data
>   in a backup saveset. Does anyone know of some c-code which would help?
> 
>   Any thoughts will be appreciated...
> 
>   thanks
>   Harry Shamansky
>   hts@hertz.eng.ohio-state.edu

There is a vmsbackup program, looking with archie I see it is available at several
sites first in the list being umigw.miami.edu. We have had this working on a Convex
and SUN. I didn't succeed on our 420 at 3.3.3L but suspect better luck would be had
at version 4. This site also has a Makefile.sgi I see.

Good luck

Steve.