January 2020

January Update

Still re-assembling the parts, but meanwhile making progress on teq, the next-generation replacement for simpleadl.

Introduction to teq

The project is called teq.
Its goal is to provide a simple architecture design and experimentation toolkit.
In its initial version, it provides a tool, teq itself, which eats an architecture description and generates a
model and an assembler.
The model behaves like a processor with the provided architecture specification; the assembler can process programs written in the architecture’s assembly language into loadable binaries loadable and executable by the model
The toolkit is entirely written in standard C, and uses only the C standard library. It's also written fairly simply, and so can be understood (and improved) without understanding a vast panoply of external code. This does impose some limitations on the flexibility and power of the architectures specified - for example, currently instructions and data must be power-of-two sizes in bytes.


Currently, the toolkit functions correctly for at least a pair of simple architecture specifications: one, acc32 is akin to a grown-up 32 bit 6502; the other, r32, is akin to a generic RISC machine.
These architectures don’t bother with specifying MMU’s etc, though there’s no obvious reason why they couldn’t.

Model Types

We currently generate two sorts of models - uni-context and multi-context.
Context models don’t worry about cores, caches, performance or whatever. They just model the
A single-context model reads instructions from memory, executes them, and updates internal state and the memory.
A multicontext model runs multiple contexts one after the other in the hope of executing multiple instructions within a context before moving on to the next; this lets things run faster. But to get the interactions between programs in different contexts at least credible, whenever a context does something which could affect another context (eg access non-local memory (the current stackframe and registers are assumed local)) the current context is ripped untimely out of the queue and added to the back of the queue of contexts.
The architecture models allow you to compare architectures on the crude basics of code size and path lengths.
They also act a ‘golden models’ if you’re doing functional verification of a design
It’s conventional to add some instructions to the architecture to allow simple I/O - the arch language knows of a few standard ports which can read and write characters, integers, hex values and strings to/from
stdin and stdout.

Performance Models

A future version will be able to create a discrete-event model which maps contexts to cores and which models the tags of the caches (to avoid semantically unneeded data movements between memory and cache), which knows latencies and issue rates for the available function units and which knows what instructions use which units. A naive start at specifying this is already present. The microarchitecture of the cores will be abstracted away to get higher simulation performance.
Further away, there will be a finder-grain discrete event model which will use a microarchitecture description. We expect there’ll be an approximation version in which
some cores run with the full microarchitecture model but the majority just get given an ipc to use, which will be extracted from the running cores. (The assumption here is that the collection of cores is running “a program”; if it’s modelling a general purpose computer running a mix of workloads, you can’t do this).


In the nearer future, the toolkit will start generating (not very good) compilers. The language will be a superset of a subset of C, and the compilers will generate assembler code for the targets specified.
The added semantics provide explicit concurrency (using
par and friends) and inter-context message passing. The compiler is the same parser, and translator, as used for the instruction semantics specification.
We foresee the ability to specify a few
styles of code generation for the compiler, including an accumulator style (e.g. acc32) and a RISC style (e.g. r32). We expect to add stack styles (for machines like Inmos’ transputer) and VLIW styles (supporting VLIW models requires some more work in the architecture tool itself).
In addition, we foresee the ability to manipulate the IR triples to prepare for a specific style of code generation (eg, we may wish to pre-group triples for a VLIW machine) along withs specific triple-to-code sequence transformation rules.
We don’t currently foresee much in the way of complex peephole optimisations being provided.

Magic Engines

Real systems include not just processors and memory, but also engines like DMA machines and peripherals.
The toolkit will allow you to write models of engines in the full teq language, which understands time - and thus looking at interfaces at specific times - as well as internal concurrency. The toolkit will generate discrete even models of the engines in C, mixable-in with the processor models.