In compiling software graphs come up all the time!
For our hypothetical string-centric hardware we may want to view parsing code at different levels of compilation! Or how about editing any parsing code visually (requires a bit more tooling...)?
Furthermore we may want to get a highlevel view of how all the components hook together! Or to debug the implied control flow in the Layout Coprocessor!
Maybe it'd even be useful for disassembling Arithmetic Core code...
The simplest code for viewing these graphs would rely on interactivity by rendering it to an entire website you can surf, taking advantage advantage of all the accessibility tooling we'd build!
But sighted folk would want to see the entire graph onscreen at once! Layout is the tricky bit here, using a physics-inspired sim. Which if computed & rendered live appears more interactive, interesting, & performant! It'll take a few workarounds to run on our Layout Coprocessor...
To have nodes repulse & bounce off each other we'd need a spatial index, which our Layout Coprocessor demands to be a binary tree. A quad tree maybe?
Except a tree can never put all data immediately available to the nodes which need it. So we'd need to propagate that data (or summaries thereof) along branches.
On the bright side: We'd strongly benefit from the Layout Coprocessor's concurrency!
P.S. Our other hypothetical processors aren't much better suited to this task.
We'd want to add central gravity so disconnected graphs don't get flung away.
We'd need edges to pull nodes together like springs. So we'd need to find a way for our tree-centric coprocessor to traverse graphs...
There'd be a couple KBs of random-access memory shared between all Compute Units (added primarily to aid parsing preprocessed text). If we can shove enough relevant layout data into this from the Layout Coprocessors computations... We can route it to the appropriate spring sims!
Once we've computed where all the nodes & edges are we can hand it off to the Compositor to render the circles & arrows. It can definitely render straight arrows, but I believe we could also get it to render curved ones which don't bend back on themselves.
The Layout Coprocessor would also want to position text in relation to the graph layout, handing that off to the Compositor as well.
We might want to design another DSL for this, the Layout Coprocessor's primary one wouldn't be suitable.
5/5
Add comment