Close

Auxiliary Input and Output space

A project log for POSEVEN

An architecture for OSes, languages and application processors, that emphasises speed, safety, security and modularity.

yann-guidon-ygdesYann Guidon / YGDES 02/19/2026 at 22:030 Comments

Input and output (IO) is another critical resource but it's not the central feature of POSEVEN. It still needs to be specified !

The Code, Data and Instruction spaces are essential but some modules may inherit access to a 4th space : IO registers.

Access to this space is exclusive : each module (why limit to thread?) can access a range (only one range ?) of IO registers, which are rather fast, but must usually enforce access protocols.

When a thread generates an input or output request, the IO target/peripheral compares the module ID or thread ID with a valid registered ID (configured by the core module). An ID mismatch will obviously trigger an exception.

The single-server approach might look like it increases complexity and latency, becoming a bottleneck, but overall, it ensures a coherent multiplexing of the requests as the system scales up, preventing complex semaphores, mutual locks and race conditions.

A particular IO module may receive simultaneous requests through IPC/IPE from several threads, but this leads to one single code, a single point of decision, simplifying arbitrage. There is no risk that one module mismanages a resource shared with another module using an outdated protocol, for example.

Furthermore, large data blocks may be transmitted through the "shuttles" and queued during the IPC, and the main thread of the module will handle and serialise all the requests.

Discussions