Perhaps the most vital dev tools for our hypothethetical string-centric hardware would be those for converting from a human-legible form (stick to text status-quo since this hardware is string-centric, caveat) to what each of our coprocessors can reasonable be expected to understand!
And back! Though I'd minimize the need for that by shipping updates as source code where I can.
Also tools to run these programs, providing an intuition over their behaviour.
The Graphics Compositor & SFX coprocessors would be primarily programmed by the Output Unit using compiletime constants. As would the Arithmetic Core, with the aid of a special "label" type.
To aid debugging that Arithmetic Core I'd probably end up creating a tool which has the Input Preprocessor emulate its RAM, triggered by user input or a periodic timer. So we can stepwise debug the program, and view its entire state! As well as a disassembler rendering arrows for control flow.
2/3?
To debug those output programs it could be useful to send them a signal ranging from low to high, to see/hear how the handle each input value.
Similarly I'd have a tool which runs an FPMA program output the results as scatterplots showing the output for each value of each input (holding other inputs to, by default, zero), verbalized as differently-pitched beeps. I've already described how its compiler would work.
And I've already described a stack of language for our "Layout Coprocessor".
3/4!
This Layout Coprocessor would have tool rendering its visual output for given input values, with an option to sweep an input from low to high to see how the output responds to every value.
The Output Unit (frequently combined with the Parsing Unit) would have tool that opens tabs/windows for all the outputs (including the Arithmetic Core's code) generated by running one of its programs.
And I'd give the Parsing Unit a tool which styles its input text to annotate which rules it matched.
Add comment