Insane.."The downside to TMR, though, is that this approach leads to
.On Mon, 11 Nov 2019 15:52:11 GMT, Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote:
Nice. long article: where it goes
Space-grade CPUs: How do you send more computing power into space?
https://arstechnica.com/science/2019/11/space-grade-cpus-how-do-you-send-more-computing-power-into-space/
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 possible program counter registers.
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
On Mon, 11 Nov 2019 15:52:11 GMT, Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote:
Nice. long article: where it goes
Space-grade CPUs: How do you send more computing power into space?
https://arstechnica.com/science/2019/11/space-grade-cpus-how-do-you-send-more-computing-power-into-space/
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 possible program counter registers.
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 possible program counter registers.
Yes, there is a reason for that...
On Tuesday, November 12, 2019 at 10:52:39 PM UTC-8, Rick C wrote:
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 possible program counter registers.
On Tuesday, November 12, 2019 at 10:52:39 PM UTC-8, Rick C wrote:
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 possible program counter registers.
Yes, there is a reason for that...
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:
https://www.parallax.com/microcontrollers/propeller
which also has eight possible program counter registers...
On Wed, 13 Nov 2019 11:52:51 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:
On Tuesday, November 12, 2019 at 10:52:39 PM UTC-8, Rick C wrote:
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 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.
Yes, there is a reason for that...
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.
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.
On 14/11/19 05:29, upsidedown@downunder.com wrote:
On Wed, 13 Nov 2019 11:52:51 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:
On Tuesday, November 12, 2019 at 10:52:39 PM UTC-8, Rick C wrote:
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 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.
Yes, there is a reason for that...
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.
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.
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
On Thu, 14 Nov 2019 07:59:49 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:
On 14/11/19 05:29, upsidedown@downunder.com wrote:
On Wed, 13 Nov 2019 11:52:51 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:
On Tuesday, November 12, 2019 at 10:52:39 PM UTC-8, Rick C wrote:
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 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.
Yes, there is a reason for that...
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.
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.
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
Not any worse than 8008/8080.
Made general purpose "unlimited" depth subroutine calls
a real pain.
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.
On Thursday, 14 November 2019 20:49:36 UTC, upsid...@downunder.com wrote:
On Thu, 14 Nov 2019 07:59:49 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:
On 14/11/19 05:29, upsidedown@downunder.com wrote:
On Wed, 13 Nov 2019 11:52:51 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:
On Tuesday, November 12, 2019 at 10:52:39 PM UTC-8, Rick C wrote:
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 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.
Yes, there is a reason for that...
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.
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.
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
Not any worse than 8008/8080.
Made general purpose "unlimited" depth subroutine calls
a real pain.
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
On Thu, 14 Nov 2019 07:59:49 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:
On 14/11/19 05:29, upsidedown@downunder.com wrote:
On Wed, 13 Nov 2019 11:52:51 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:
On Tuesday, November 12, 2019 at 10:52:39 PM UTC-8, Rick C wrote:
On Wednesday, November 13, 2019 at 1:21:59 AM UTC-5, marty wrote:
On 12/11/19 6:41 pm, upsidedown@downunder.com wrote:
There has been a lot of development since the 1802 CMOS processor that
was once popular in space applications
I have yet to see another with 8 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.
Yes, there is a reason for that...
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.
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.
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
Not any worse than 8008/8080.