Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Bumped by Community user
Bumped by Community user
Bumped by Community user
5 added 285 characters in body; edited title

# Question

tl;dr In looking through some papers on Transport Triggered Architectures (TTA), I've noticed they are calling it an OISC (One-Instruction Set Computer), even though the Function Units (FU) might implement complex logic outside of the TTA. This means to me it's not really a OISC. It's like saying that x86 is a OISC if you just think of all operations as being of the form APPLY name, arg1, arg2, arg3. So I'm wondering if there are any examples of creating the FU components using the TTA, so that it would really be a one instruction set architecture. Or if not, why not, I'd be wondering then what you can't model or implement just using the MOVE instruction. But this is just tangential..

The main question is, given all logic gates can be assembled from NAND gates, if the Functional Units (FU) in a TTA can be built using the TTA itself, starting with implementing a NAND gate in the TTA directly somehow.

# If the MOVE instruction in a Transport Triggered Architecture can be used to create the Function Units (FU)

tl;dr In looking through some papers on Transport Triggered Architectures (TTA), I've noticed they are calling it an OISC (One-Instruction Set Computer), even though the Function Units (FU) might implement complex logic outside of the TTA. This means to me it's not really a OISC. It's like saying that x86 is a OISC if you just think of all operations as being of the form APPLY name, arg1, arg2, arg3. So I'm wondering if there are any examples of creating the FU components using the TTA, so that it would really be a one instruction set architecture. Or if not, why not, I'd be wondering then what you can't model or implement just using the MOVE instruction.

# Question

In looking through some papers on Transport Triggered Architectures (TTA), I've noticed they are calling it an OISC (One-Instruction Set Computer), even though the Function Units (FU) might implement complex logic outside of the TTA. This means to me it's not really a OISC. It's like saying that x86 is a OISC if you just think of all operations as being of the form APPLY name, arg1, arg2, arg3. So I'm wondering if there are any examples of creating the FU components using the TTA, so that it would really be a one instruction set architecture. Or if not, why not, I'd be wondering then what you can't model or implement just using the MOVE instruction. But this is just tangential..

The main question is, given all logic gates can be assembled from NAND gates, if the Functional Units (FU) in a TTA can be built using the TTA itself, starting with implementing a NAND gate in the TTA directly somehow.

4 added 446 characters in body; edited title

# Simplified explanation of If the MOVE instruction in a Transport Triggered Architecture can be used to create the Function Units (FU)

I'm wondering if one could explain a little more clearly how the move instruction works. How it is only 1 instruction, and how it can do something such as the "ADD" operation or something slightly more complex.

This looks like it could help, so will take a look here as well.

After looking through this, it sounds like a Function Unit (FU) implements all the "primary" logic, and so hides implementation detail. So you can have an "ADD" FU, and that is some complex circuit. Would like to know if I am understanding this part correctly. My question then would be if the single MOVE instruction could be used to create all the Function Units, or if not, why not.

tl;dr In looking through some papers on Transport Triggered Architectures (TTA), I've noticed they are calling it an OISC (One-Instruction Set Computer), even though the Function Units (FU) might implement complex logic outside of the TTA. This means to me it's not really a OISC. It's like saying that x86 is a OISC if you just think of all operations as being of the form APPLY name, arg1, arg2, arg3. So I'm wondering if there are any examples of creating the FU components using the TTA, so that it would really be a one instruction set architecture. Or if not, why not, I'd be wondering then what you can't model or implement just using the MOVE instruction.

# Simplified explanation of the MOVE instruction in a Transport Triggered Architecture

I'm wondering if one could explain a little more clearly how the move instruction works. How it is only 1 instruction, and how it can do something such as the "ADD" operation or something slightly more complex.

This looks like it could help, so will take a look here as well.

# If the MOVE instruction in a Transport Triggered Architecture can be used to create the Function Units (FU)

This looks like it could help, so will take a look here as well.

After looking through this, it sounds like a Function Unit (FU) implements all the "primary" logic, and so hides implementation detail. So you can have an "ADD" FU, and that is some complex circuit. Would like to know if I am understanding this part correctly. My question then would be if the single MOVE instruction could be used to create all the Function Units, or if not, why not.

tl;dr In looking through some papers on Transport Triggered Architectures (TTA), I've noticed they are calling it an OISC (One-Instruction Set Computer), even though the Function Units (FU) might implement complex logic outside of the TTA. This means to me it's not really a OISC. It's like saying that x86 is a OISC if you just think of all operations as being of the form APPLY name, arg1, arg2, arg3. So I'm wondering if there are any examples of creating the FU components using the TTA, so that it would really be a one instruction set architecture. Or if not, why not, I'd be wondering then what you can't model or implement just using the MOVE instruction.

3 added 561 characters in body

Seeing diagrams such as this make me wonder what the Function Units (FU) are implemented as, as it seems the MOVE instruction would then be delegating to either software or hardware defined "circuits" and thus not really be a true OISC, just hiding all the more-than-one instruction operations inside an FU.

Seeing diagrams such as this make me wonder what the Function Units (FU) are implemented as, as it seems the MOVE instruction would then be delegating to either software or hardware defined "circuits" and thus not really be a true OISC, just hiding all the more-than-one instruction operations inside an FU.

2 added 1204 characters in body
1