architecture
Like almost all processors, Sprockell deploys a decoder to split its given instruction into its components. These components are guaranteed to complete in one cycle, and their results will be used to either write to local memory, shared memory and registers. The diagram below illustrates how these components are (roughly) tied together:
Unlike "real" processors, the program is not stored in main memory and is therefore not changeable during runtime. By default, dmem can hold 128 words, although this is configurable in Sprockell.hs. The local memory also stores the stack.
Because the stack is stored in the local memory of a Sprockell, it can (and will!) cause collisions with other data stored there if it grows too large. By convention, the stack starts at the highest address of the memory (default:127) and grows down until it reaches the smallest (0). Obviously, beyond this point no guarantees can be given about the behaviour of the Sprockell.
| Register | Description |
|---|---|
| Zero | Always zero (even after writing to it) |
| PC | Program counter |
| SP | Stack pointer. Points to the top of the stack. |
| SPID | Sprockell ID. Only meaningful when deploying multiple Sprockells. |
| RegA, RegB, ..., RegE | Registers available for user data |
Multiple Sprockells are deployed by tying them together using shared memory. A single Sprockell communicates with the shared memory by using a bus, which is shown as dotted box in the first image on this page. A request to the shared memory has to pass through the a queue, the shared memory scheduler and on its way back again through a queue. All in all, the diagram looks like (with one Sprockell explicitly drawn):
The extra layer in between (system), in addition to passing messages to the shared memory, implements power management and I/O to stdin / stdout. Instructions explains how to use these concepts from a user point of view.