Space-grade CPUs: How do you send more computing power into space?

Shouldn't we be concerned about sending computing intelligence into space lest it be merged with by alien intelligence to form an evil force to attack us?

Inquiring minds want to know!

--

  Rick C. 

  - Get 1,000 miles of free Supercharging 
  - Tesla referral code - https://ts.la/richard11209

Insane.."The downside to TMR, though, is that this approach leads to a lot of overhead. A processor has to go through every operation thrice, which means it can only reach one-third of its performance." Use THREE processors running in parallel; three decisions at the same time (ie: parallel NOT serial).

More components means more things to fail, and more power.

Trying to remember a university course from mumble years ago... A simple[1] (simplistic?) calculation indicates that, where faults cannot be repaired, TMR is more likely to be error-free in the short term, and less likely in the long term.

Assess the crossover point carefully :)

[1] probably based on an exponential failure rate

There has been a lot of development since the 1802 CMOS processor that was once popular in space applications :-).

Yes IIRC 'Voyager' was captured by some aliens and looking for it's 'creator' in one of those startrek series.

I am more worried about that alien in the white house though..

More weight and 3x more power.

I have yet to see another with 8 possible program counter registers.

Yes, there is a reason for that...

--

  Rick C. 

  + Get 1,000 miles of free Supercharging 
  + Tesla referral code - https://ts.la/richard11209

But, maybe not a good reason. For real-time controller applications, a rapid context switch does benefit from that kind of support. In a multiuser/multitasking environment, not so much.

The programming style that benefits from this architecture involves a kind of 'coroutine' instead of subroutines. It's a precursor to the many-core grid computer chips in current production. Like this:

which also has eight possible program counter registers...

Any of the sixteen registers could be used as program counter or index register. The R1 was used as the interrupt program counter, otherwise the register usage was quite liberal.

In a small applications, each coroutine (subroutine) could be assigned an own program counter. Calling a coroutine was just a single byte SEP (Set Program counter) instruction and the return from coroutine was just SEP back to the caller.

hat

rapid

ultitasking

d of

rid

There was nothing rapid about the 1802. People seem to do quite well with the fast interrupt on the ARMs and other, similar function on other devices .

Likewise, for most users, the propeller is a tool looking for a useful purp ose. It has some advantages, but mostly it's just an expensive MCU with ni che applications.

Now that there are FPGAs in smaller and smaller packages running with less and less power, they can take the place of MCUs in many apps and the propel ler is a poor substitute for an FPGA. I'm trying to figure out what has ha ppened to Gowind. They had some very nice parts in QFN packages.

--

  Rick C. 

  -- Get 1,000 miles of free Supercharging 
  -- Tesla referral code - https://ts.la/richard11209

Coroutine yes, subroutine no.

IIRC getting data between external memory and the 16 bit registers was a pain: everything had to go via the accumulator, one byte at a time

Made general purpose "unlimited" depth subroutine calls a real pain.

Not any worse than 8008/8080.

Many early computers did not have stacks.

On the 1802 you could have multiple stacks with separate stack pointers and then use SEX (Set X) instruction to select from which stack you want load or store.

The thing that was really special about the 1802 was that is was not only CMOS but silicon on sapphire which made it particularly suitable for high radiation environments. There was nothing else comparable at the time. John

And now you know the rest of the story...

I don't think anyone used the 1802 because they liked the architecture.

--

  Rick C. 

  -+ Get 1,000 miles of free Supercharging 
  -+ Tesla referral code - https://ts.la/richard11209

The 8080 had the CALL instruction which included the arbitrary

16-bit address as the argument. Total 3 bytes.

The 8080 had the LDHL instruction which loads the HL register with the 16-bit argument. Ditto SHLD stores. Total 3 bytes.

Yes, but IIRC there was no equivalent of the 8080 subroutine CALL instruction or the 6800 JSR instruction.

Hence "coroutine yes, subroutine no".

With R2 as the stack pointer and using the MARK instruction could produce similar results.

Take a look at the various program control options available starting at page 54 of

I didn't mean it was /impossible/ to execute a JSR foo, just that the 1802 instruction set isn't well suited to it.

*If* I understand it, the reference you quote indicates that the generic "JSR foo" using the "SCRT" technique requires 7 instructions and 9 bytes (cf 8080/6800 1 instruction and 3 bytes).

That's a significant difference in a small memory machine.

The corresponding RET is even worse, requiring 13 instructions and 13 bytes (cf 8080/6800 1 instruction and

1 byte). But 12 of those are shared between all subroutines, so the main penalty is in performance.

The 1802 makes general purpose "SCRT" subroutine calls painfully slow and memory intensive. Hence I still think "coroutine yes, subroutine no" is valid.

Perhaps don't send *more* hardware into space.

Instead send lasers up and down as processing commands.

Process the commands/instructions on earth.

Send back the results to space.

Bye, Skybuck.