Как создать граф потока данных (DFG/SDFG) для любого приложения из его исходного кода

Question

Я провел много исследований, чтобы выяснить, как DFG может быть создан для приложения из его исходного кода. Существуют DFG, доступные онлайн для определенных приложений, таких как MP3-декодер, сжатие JPEG и декодер H.263.

Мне не удалось выяснить, как я могу создать DFG для приложения, такого как HEVC, из его исходного кода? Существуют ли какие-либо инструменты, которые могут мгновенно генерировать графики потоков данных для таких сложных приложений или это нужно делать вручную?

Просьба сообщить мне об этом.

EDIT: Я использовал Doxygen для HEVC, и я мог видеть, как разные функции взаимодействуют друг с другом. Однако у каждой функции было много точек входа и выхода, а выход Doxygen стал слишком запутанным, чтобы последовать за ним.

Я также посмотрел на StreamIt: http://camlunity.ru/swap/Library/Conflux/Stream%20Programming/streamit-cc_stream_graph_programming_language.pdf

Казалось удобно, но графики он сгенерированные для еще более простых приложений (например, MP3-декодером) были слишком сложными. Чтобы сформировать когерентный DFG, мне придется переписать весь исходный код?

Answer 1

Вы хотите извлечь графики потоков данных с произвольных языков. Вы подразумеваете, что вам нужен единственный способ сделать это. Это не практично вручную ... вам нужен инструмент.

Такой инструмент особо сложно построить.

Чтобы сделать это, для каждого языка, вы должны быть в состоянии:

• Определить язык к инструменту, в форме вы найдете его на практике (а не только языка эталонной версии вручную). C++ в дикой природе изогнут во множестве забавных способов по сравнению со стандартом.
• Разбирайте программы на языке, найденном в поле, возможно, как один файл, возможно, как десятки тысяч; некоторые программы невелики.
• Строить структуры, представляющие языковые элементы и их отношения друг к другу (это часто делается как абстрактное синтаксическое дерево)
• Определите для каждого литерала, каково его фактическое значение; «a \ xbc» имеет очень разные значения в зависимости от того, считает ли язык ascii или unicode текстом с escape-последовательностями.
• Найдите все идентификаторы в коде и определите для каждого, с которым связана информация определения/типа правила определения языка
• Определите источники данных (литеральные значения, входы от внешнего мира, результаты выражений) и отслеживайте, где эти значения данных используются в других частях программы в различных конструкциях потока управления.
• Предположительно нарисовать некоторая картина результирующего потока данных.

Каждая из этих задач сама по себе сложна, потому что языки имеют тенденцию быть сложными. Большинство языковых инструментов, которые могут сделать это вообще (в основном компиляторы), делают это только для одного диалекта языка.

Чтобы сделать это для более чем одного языка/диалекта, вам нужен инструмент, который можно настроить для всех деталей для каждого языка, и вы должны настроить для всех интересующих языков.[Реально вы не можете «делать все»; сейчас есть тысячи компьютерных языков].

Даже ограничивая себя «повседневными» общедоступными языками программирования, это огромный объем работы; это может занять несколько лет, чтобы сделать все это хорошо для одного основного языка. Вам это не удастся сделать самостоятельно.

Наша компания строит единый унифицированный инструмент, который предназначен для этого: DMS Software Reengineering Toolkit. Простой «секрет» заключается в том, чтобы понять, что the machinery needed to accomplish the above tasks на самом деле очень сходен на разных языках и может быть сконфигурирован так, чтобы он был настроен для определенного языка с относительно скромным (что не означает «маленькое») усилие.

После 20 линейных лет инженерных с командой инженеров уровня PhD, мы имеем parsers (even this is hard) для surprising variety of languages с полным до data flow analyzers типа вы говорите для C++ (check this link for examples), C, COBOL и почти Java 8.

Я не знаю никаких других унифицированных инструментов, которые находятся далеко по пути к вашему идеалу. Проверьте мою биографию, прежде чем решите, что я об этом не знаю. (Rascal/MPL имеет некоторые амбиции, но является инструментом исследования на данный момент, они вообще не делают C или C++). Мы только частично участвуем в этом, со многими языками и масштабными сражениями, чтобы бороться с остальными.

[Цель DMS - не анализ потока данных; это всего лишь ступенька. Это должно быть автоматическое преобразование кода, которое требует, чтобы анализ потока данных делал безопасно и правильно].

Конечно, вы можете просто надеяться найти отдельный инструмент для каждого языка. Вы не получите согласованного качества или согласованного стиля/гранулярности графиков потока данных от отдельных инструментов от разных авторов, если вы действительно можете получить полный набор таких инструментов вообще.