These are some embarrassingly loose sketches made en route to a friend’s leaving do. I wanted to cement my ideas about the builder class and these led into the idea of how one defines a hardware device. I was getting painfully close to template magic with these ideas but wanted to get an idea for the most expressive DSL for a recipe.
I also sketched out some ideas for how to organise the project. And this also raised the question of whether I could statically compile the builders and take advantage of compiler optimisations so the DAG would have a very small footprint.
the ‘struct VolTRAX_0_0_1 is significant. Here I’m thinking of ways of declaring a device and how the state of that device is handled. Also if the device were a template class then you would have a very pluggable way of constructing recipes for multiple targets: you can reuse the core tasks but swap out different hardware. TBC
Other notes that came up:
- Should the DAG nodes be old school and use pointers or reference_wrappers to other nodes?
- Don’t get too carried away with std::array in first pass. Write in std::vector, get unit tests working, then try to get static array version building as future goal.
- How to implement current execution point ‘cursor’ and how is the running of each node handled. Should the computation trawl through the nodes or should there be an external ‘computer’ that maintains the cursors.
- How do tasks signal they are finished, just notify by updating a counter, or do something snazzy with boost::signals2?
- Quick todo list on setting up the GitHub repo!
After getting home I did a little late night exploration in terms of what one could do with static DAGs, e.g. std::array. This was off-piste but fun. Also I was using C++14 for some cases which, so I need to reign that in for the C++11 requirement spec for this challenge: