Polling (not interrupts) on the path to super computers

ngeneer

@cgracey , were you channeling Seymour Cray in designing the Propeller?

"Cray replaced I/O interrupts with polled request issues by a peripheral processor, which made all the transfers to and from the CDC 6600's central memory. "

https://www.allaboutcircuits.com/news/seymour-cray-dawn-of-supercomputing/

evanh

Huh, I'd never asked where the origins of the Cray supercomputers had come from.
I'm guessing one vector display and one raster display on the console there.

The method of polling will presumably be like the propeller's various WAIT instructions. The Prop2's event mechanism in particular would lend itself to that sort of use. And it's notable how that mechanism can be used as either polled or via interrupts in the Prop2.

Beau Schwabe

Seems like the beginnings of RTOS (Real Time Operating System) .... With RTOS, you basically have a fixed or known interval (system heartbeat). Each process runs within the interval and might have undeterministic timing within itself and have the capacity to span multiple intervals. The process aligns at each interval resulting in a deterministic time base. The "polling" reference above sounds more like a dispatcher approach.

With reference to flow-charting, the flowchart needs to be designed with a "fall through" approach in mind. This means that any node within the flowchart must not run in a "blocking" mode. The flowchart uses an index variable to keep track of which node within the flowchart to process next. Any node has the ability to change the value of the index variable based on conditions within the node. On the completion of each node execution returns to a dispatcher. The dispatcher, based on the index variable, then executes the next corresponding node. Taking this further, instead of a series of IF/THEN's to determine the correct node for the dispatcher to jump to, a simple binary tree can be applied to greatly narrow down this process. Using the index variable and dispatcher approach allows for the interdigitation of multiple flowcharts into a single system. Each flowchart has its own dedicated index variable, thus allowing complete atomic operation from one flowchart to another.

Electrodude

@"Beau Schwabe" said:
Seems like the beginnings of RTOS (Real Time Operating System) .... With RTOS, you basically have a fixed or known interval (system heartbeat). Each process runs within the interval and might have undeterministic timing within itself and have the capacity to span multiple intervals. The process aligns at each interval resulting in a deterministic time base. The "polling" reference above sounds more like a dispatcher approach.

With reference to flow-charting, the flowchart needs to be designed with a "fall through" approach in mind. This means that any node within the flowchart must not run in a "blocking" mode. The flowchart uses an index variable to keep track of which node within the flowchart to process next. Any node has the ability to change the value of the index variable based on conditions within the node. On the completion of each node execution returns to a dispatcher. The dispatcher, based on the index variable, then executes the next corresponding node. Taking this further, instead of a series of IF/THEN's to determine the correct node for the dispatcher to jump to, a simple binary tree can be applied to greatly narrow down this process. Using the index variable and dispatcher approach allows for the interdigitation of multiple flowcharts into a single system. Each flowchart has its own dedicated index variable, thus allowing complete atomic operation from one flowchart to another.

You can eliminate the dispatcher entirely by just using the address of the first instruction of the next block as the index, e.g. by saving the program counter. If you take it one step even further and save all the registers and restore them for next time, you get cooperative multitasking. You'll get realtime behavior as long as each task always yields within a certain interval.

Beau Schwabe

@Electrodude said:
You can eliminate the dispatcher entirely by just using the address of the first instruction of the next block as the index, e.g. by saving the program counter. If you take it one step even further and save all the registers and restore them for next time, you get cooperative multitasking. You'll get realtime behavior as long as each task always yield within a certain interval.

Yes, I do that when implementing this in assembly, but some languages don't allow for address indexing. I has taken me years to develop and mature this way of coding and thinking, and there is definitely a time and place for it. It is by far one of my favorites, because when it works it just works and makes my 'coding brain' feel good.

Mickster

@"Beau Schwabe"

Isn't this just a sophisticated way of describing a state-machine?

evanh

Pretty much anything can be called a state-machine. If it has memory then it has states.