/************************* libvmcu - plans for the future *************************/

These are a some of my ideas for the future of libvmcu

/********************************* Features ***************************************/

[1] McCabe's cyclomatic complexity
    [1.1] requires controlflow graph, see [0]

[2] function analysis (vmcu_function_t)
    [2.1] requires controlflow graph, see [0]

[3] cycle analysis
    [3.1] requires controlflow graph, see [0]
    [3.2] requires function analysis, see [2]

[4] enum to string mapping, for example mapping VMCU_VECT members to string

[5] loop analysis (vmcu_loop_t)
    [5.1] requires controlflow graph, see [0]

[6] analysis of lpm/spm loops
    [6.1] requires controlflow graph, see [0]
    [6.2] requires loop analysis, see [5]

[7] rework of vmcu_system_t

[8] symbolic execution (?) (as an alternative to concrete simulation)

[9] a small and very basic assembler (without macros, etc.) in order to allow code generation

[10] a python binding would be really great.
    [10.1] requires external contributors :( see CONTRIBUTING.txt

[11] make libvmcu thread safe

/********************************* Internal / Cleanup *****************************/

[12] remove usage of basic integers (int) in libvmcu (nearly done)

[13] adjust driver makefiles (debug recipe, add -g -o)

[14] speed up controlflow analysis by adding a lookup table for the cfg nodes

[15] fix inconsistency of xref-to

[16] a consistent way to return readable error codes (not just -1 and 0)

[17] separate frequently used functions (like print_instruction) from driver land