Pipelined 6502/z80 with cache and 16x clock multiplier

upsidedown@downunder.com wrote:
> The only publicly known truly redundant software that I have heard of
> is the US space shuttle with more os less triple (voting) flight
> control computers and with a 4th independent computer programmed by a
> different team capable of (only) landing the space shuttle.

I think this is a requirement for all modern fly-by-wire (commercial) 
airplanes:

I.e. you can have two identical sets of flight control computers which 
should normally agree. These are running the full-blown software, 
capable of optimally running the plane during all phases of a flight.

On top of this you have a totally separate implementation which is 
intentially kept as simple as possible: Just the bare minimum to let the 
plane fly and land.

The idea is obviously that as long as the primary computers agree, they 
stay in control, but when/if they don't, you have a fallback option 
which still works.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

In article 
<e073c9bf-50f4-45e1-97e2-11a5354c980b@g25g2000yqn.googlegroups.com>, 
MitchAlsup@aol.com says...
>

>Similarly, one could build a 64-bit CDC 6600 (or 7600) and cycle it at
>4-5 GHz in Intel/AMD/IBM process technology. {Depending on what kind
>of dataflow one wants to maintain through the memory system.}
>
A 64 bit 7600 would be a Cray 1  :)

Seriously, tha max memory addressing of the 7600 was ~2 Megabytes (256K 60 bit 
words), small enough to put right on the chip, and without page table & tag 
lookups probably could be accessed in 10 cycles?  (which would be consistent 
with the 6600/7600).  Then you could treat DDR3 as ECS (ok, the interface 
would have to be changed, the old interface maxed at 4 Megawords IIRC (~32 
Megabytes)).

The biggest performance improvement would be to re-think the PPs, but then you 
have a lot of code to rewrite, since a great deal of the OS was located there. 
 Of course, the console code would have to be rewritten anyway, display 
technology has taken a different turn since then.


		- Tim

On Jan 4, 4:40=A0am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
[snip]
> The idea is obviously that as long as the primary computers agree, they
> stay in control, but when/if they don't, you have a fallback option
> which still works.

Of course, this will not properly handle a systematic error in
the primary (identical) computers.  (I suppose one might have an
additional system that detects misbehavior and hands control over
to the alternate control computer, but by the time such is detected
the problem might be beyond the ability of a simple system to
handle [perhaps the primary control computers would take over again
after a reset??].  ISTR that there was a failure mode in which
doing nothing for a brief time would return the system to a
controllable state.  [In an extreme circumstance--in which reasonable
actions do not help and disaster seems unavoidable--random or
counter-intuitive actions might be worth trying.])



Paul A. Clayton
just a technophile

On Jan 3, 6:05=A0pm, upsided...@downunder.com wrote:
> The only publicly known truly redundant software that I have heard of
> is the US space shuttle with more os less triple (voting) flight
> control computers and with a 4th independent computer programmed by a
> different team capable of (only) landing the space shuttle.

This is incorrect.

The shuttle has 5 computers. 4 are used as a 4-way voting system and
one is used as a safety net. First failure it degrades to a tripple
redundant system. If a second failure occurs before the first computer
has recovered, all control passes to the 5th computer running
different software. {All written in HAL}

Mitch

On Jan 4, 9:54=A0am, timcaff...@aol.com (Tim McCaffrey) wrote:
> In article
> <e073c9bf-50f4-45e1-97e2-11a5354c9...@g25g2000yqn.googlegroups.com>,
> MitchAl...@aol.com says...
>
>
>
> >Similarly, one could build a 64-bit CDC 6600 (or 7600) and cycle it at
> >4-5 GHz in Intel/AMD/IBM process technology. {Depending on what kind
> >of dataflow one wants to maintain through the memory system.}
>
> A 64 bit 7600 would be a Cray 1

Maybe, maybe not.

What I was thinking was a machine with 3 register sets of 8 registers
each. Each register being 64-bits wide. There would be a number of
computation units, and instructions would be orchestrated with a
CDC6600-like scoreboard mechanism, but the computation units pipelines
like the CDC7600, all done with modern RICS-like pipeline timing.

Addresses are 64-bits, and an MMU creates a paged virtual memory
environment of whatever size is appropriate for the intended
application (about 50 physical bits in 2010).

Accompaning this computation unit is a barrel programmed I/O processor
with a number of threads to run the perifferals, and do OS scheduling
chores.

> Seriously, tha max memory addressing of the 7600 was ~2 Megabytes (256K 6=
0 bit
> words), small enough to put right on the chip, and without page table & t=
ag
> lookups probably could be accessed in 10 cycles? =A0(which would be consi=
stent
> with the 6600/7600). =A0Then you could treat DDR3 as ECS (ok, the interfa=
ce
> would have to be changed, the old interface maxed at 4 Megawords IIRC (~3=
2
> Megabytes)).

Yes, you could, but this would be a fatal disaster.

The reason Seymore stuck with 20-odd bits of physical address was that
was as big as he could package to have fully pipelined short memory
access latencies and full vector bandwidth. Memorie hierarchies no
longer have those constraints.

Placing the main memory on die would seriously limit the kinds of
problems that could be run.

> The biggest performance improvement would be to re-think the PPs, but the=
n you
> have a lot of code to rewrite, since a great deal of the OS was located t=
here.
> =A0Of course, the console code would have to be rewritten anyway, display
> technology has taken a different turn since then.

I still happen to think the PPs were a brilliant idea. Leave the
computations to the computation unit, an leave the mucky queueing and
I/O polling to slow processors with minimal processing capabilities.
Hide the entire OS in the PPs, so the CU just compute--getting
interrupted when the OS has decided to compute something else. Then
the CUs jump from full speed on one computation to full speed on
another computation in one main memory cycle time (16 clocks).

In my conjectured 'processor' the PPs are also 64-bits with a barrel
elngth of 16-ish steps.

Mitch

In article 
<962bb166-0b14-439d-a3c4-ef74ff0a4065@l32g2000yqc.googlegroups.com>, 
MitchAlsup@aol.com says...
>
>On Jan 4, 9:54=A0am, timcaff...@aol.com (Tim McCaffrey) wrote:
>> In article
>> <e073c9bf-50f4-45e1-97e2-11a5354c9...@g25g2000yqn.googlegroups.com>,
>> MitchAl...@aol.com says...
>>
>>
>>
>> >Similarly, one could build a 64-bit CDC 6600 (or 7600) and cycle it at
>> >4-5 GHz in Intel/AMD/IBM process technology. {Depending on what kind
>> >of dataflow one wants to maintain through the memory system.}
>>
>> A 64 bit 7600 would be a Cray 1
>
>Maybe, maybe not.
>
>What I was thinking was a machine with 3 register sets of 8 registers
>each. Each register being 64-bits wide. There would be a number of
>computation units, and instructions would be orchestrated with a
>CDC6600-like scoreboard mechanism, but the computation units pipelines
>like the CDC7600, all done with modern RICS-like pipeline timing.
>
>Addresses are 64-bits, and an MMU creates a paged virtual memory
>environment of whatever size is appropriate for the intended
>application (about 50 physical bits in 2010).
>
>Accompaning this computation unit is a barrel programmed I/O processor
>with a number of threads to run the perifferals, and do OS scheduling
>chores.
>
>> Seriously, tha max memory addressing of the 7600 was ~2 Megabytes (256K 6=
>0 bit
>> words), small enough to put right on the chip, and without page table & t=
>ag
>> lookups probably could be accessed in 10 cycles? =A0(which would be consi=
>stent
>> with the 6600/7600). =A0Then you could treat DDR3 as ECS (ok, the interfa=
>ce
>> would have to be changed, the old interface maxed at 4 Megawords IIRC (~3=
>2
>> Megabytes)).
>
>Yes, you could, but this would be a fatal disaster.

Well, it was mostly for for fun, not that I would try to sell this as the next 
great thing.


>
>The reason Seymore stuck with 20-odd bits of physical address was that
>was as big as he could package to have fully pipelined short memory
>access latencies and full vector bandwidth. Memorie hierarchies no
>longer have those constraints.
>
>Placing the main memory on die would seriously limit the kinds of
>problems that could be run.
>
>> The biggest performance improvement would be to re-think the PPs, but the=
>n you
>> have a lot of code to rewrite, since a great deal of the OS was located t=
>here.
>> =A0Of course, the console code would have to be rewritten anyway, display
>> technology has taken a different turn since then.
>
>I still happen to think the PPs were a brilliant idea. Leave the
>computations to the computation unit, an leave the mucky queueing and
>I/O polling to slow processors with minimal processing capabilities.
>Hide the entire OS in the PPs, so the CU just compute--getting
>interrupted when the OS has decided to compute something else. Then
>the CUs jump from full speed on one computation to full speed on
>another computation in one main memory cycle time (16 clocks).
>
>In my conjectured 'processor' the PPs are also 64-bits with a barrel
>elngth of 16-ish steps.


Michigan State had a largish systems programming group, they basically rewrote 
most of the Scope 3.4 OS (they called the result Hustler).  One of the things 
they did was move alot of the OS back into the main CPU, it sped things up 
considerably.  Even on the 7600 Cray must have had second thoughts, because 
the CPU could talk to the channels directly without the PPs getting involved.

64 bit PPs help, giving them interrupts helps as well. The CDC PPs did not 
have interrupts, boy was that a pain to program.  

		- Tim

MitchAlsup wrote:
> The shuttle has 5 computers. 4 are used as a 4-way voting system and
> one is used as a safety net. First failure it degrades to a tripple
> redundant system. If a second failure occurs before the first computer
> has recovered, all control passes to the 5th computer running
> different software.

Hm, what's the point of that fifth computer?

Ok, I understand: The idea is the following: Alice, Dilbert, Wally, and 
Asok are four co-workers with lots of expierence in the field.  If one 
of them disagrees (usually Wally, who once was a super-programmer, but 
broken by futility), Alice punches him hard to shut him up.  If two 
people disagree, Alice's fist of death is already stuck in Wally, the 
fuzz doesn't die, and then the PhB decides (that's module five, running 
completely different software).  Fatal failure guaranteed.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

rpw3@rpw3.org (Rob Warnock) writes:
> <kym@kymhorsell.com> wrote:
> +---------------
> | MitchAlsup <MitchAlsup@aol.com> wrote:
> | > The PDP-10 had infinite indirect memory addressing--the addressed
> | > word from memory contained a bit to indicate if another level of
> | > indirection was to be performed.
> | 
> | Is my memory faulty or was it possible for the (buggy) TOPS-10 to hang
> | because of this little h/w feature?
> +---------------
> 
> Your memory is faulty. (Sorry.)  ;-}  ;-}

Neither the PDP-6 nor any of the PDP-10 models had this problem.  The
7094 did, however, and one could hang CTSS (the time sharing system)
by executing an infinite indirect loop.  Multics (645) could not
interrupt and restart, but had a timeout trap.  There were
instructions on the PDP-10 which would never finish, even though legal
and (on paper) terminating, since they could reference a pattern of
pages which could never be in memory simultaneously.  Since
instructions restarted each time from the beginning, they could never
complete execution.

WRT reliability, we ran a time shared KA-10 processor for periods of
over six months, and took the system down for an update, rather than
having it crash (this was with the ITS operating system).  I find it
remarkable that today's software is so chock a block full of fixable
bugs.  No one seems to actually look at what caused a crash any more.

In comp.arch Tom Knight <tk@shaggy.csail.mit.edu> wrote:
> Neither the PDP-6 nor any of the PDP-10 models had this problem.  The
> 7094 did, however, and one could hang CTSS (the time sharing system)
> by executing an infinite indirect loop.  Multics (645) could not
> interrupt and restart, but had a timeout trap.  There were
> instructions on the PDP-10 which would never finish, even though legal
> and (on paper) terminating, since they could reference a pattern of
> pages which could never be in memory simultaneously.  Since

Now, *that* rings a bell. :)

> instructions restarted each time from the beginning, they could never
> complete execution.
[...]

-- 
Ever seen film of the Polar bear bashing through the ice to get seal
cubs?  Less ice more food for the Polar Bear
  -- george <gblack@hnpl.net>, 27 Oct 2010 15:55:37 -0700

Tom Knight  <tk@shaggy.csail.mit.edu> wrote:
+---------------
| WRT reliability, we ran a time shared KA-10 processor for periods of
| over six months, and took the system down for an update, rather than
| having it crash (this was with the ITS operating system).
+---------------

TOPS-10 was often just as reliable. At the Emory Univ. Chem. Dept.,
we ran a time shared KA-10 processor running TOPS-10 for multiple
periods of over six months, and in one instance, over a year.
Note: We filed a complaint with DEC Field Circus over that one,
since we had a service contract and they were supposed to do
preventative service more often than that!!  ;-}

+---------------
| I find it remarkable that today's software is so chock a block
| full of fixable bugs.
+---------------

My personal experience with FreeBSD has been pretty good:

    $ uname -mrs ; uptime
    FreeBSD 6.2-RELEASE-p4 amd64
    12:09AM  up 401 days, 22:50, 19 users, load averages: 0.03, 0.02, 0.00
    $ 

That machine runs web, mail, SSH, and DNS servers,
and sits right on the 'Net with no hardware firewall.

'Course, the 2-hr UPS helps a lot...  ;-}  ;-}


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607