Talk:Transport triggered architecture

From Wikipedia, the free encyclopedia

[edit] Interrupt latency

How to solve the interrupt latency problem?

Reading a result too early results in reading the result of a previously triggered operation, or in case no operation was triggered previously, the read value is undefined. On the other hand result must be read early enough to make sure the next operation result does not overwrite the current result in the output port.

For performance reasons there should be several operations in flight at any given moment. But the requirement not to read to early or to late will require that interrupts are disabled while operations are performed.

One approach might be to not handle interrupt in TTA processor but in an IO processor optimized for interrupt handling. Much like the ND-500.

--RogerJL 23:46, 6 November 2006 (UTC)

Yes, this is the another of the worst drawbacks of the TTA approach. Interrupts are costly to implement. Potentially very wide instruction width is the another problematic spot, which has been overcome by use of instruction compression. I added some text about the interrupts to the wiki page.

PekkaJ 19:06, 9 June 2007 (UTC)

[edit] Copper?

Would a mention of the "Copper" display-synchronized coprocessor in Amiga computers be appropriate here? True, it's not a pure TTA, since it had two additional instructions for synchronizing to the display hardware, but it still had all the basic features (including write access to its own program counter) and was part of a widely sold desktop computer architecture. —Ilmari Karonen (talk) 23:10, 12 June 2008 (UTC)