Средства и методы разработки

Обобщенное программирование: краткая сводка идей. Здача любого кода - получить из входного представления информации выходное. Преобразование происходит на основе правил. Правила делятся на две категории: инвариантные - зависят только от сути задачи, и зависимые от внешних условий. Второе - это целевая архитектура, особенности компилера и пр. Инвариантые конструкции пишутся на целевом языке программирования и не меняются при смене внешних условий. Модуль - это кусок кода, написанный на языке программирования, имеющий следующеи сущности: * export -- точки входа - куда может быть сделан переход из других модулей. Точки входа бывают типа функция (с возвратом назад после завершения работы в модуле) и типа переход (сюда пришли, а выйти из модуля можем в произвольное место, от адреса, откуда пришли, независим). Также бывают реентерабельные и нереентерабельные точки входа. -- переменные, к которым другие модули могут иметь достпу RO или RW * import -- внешние переменные - модуль имеет к ним доступ RO или RW -- связи с внешними модулями - для работы модуль может использовать другие модули * OS - связи с ОС. ОС это тоже модуль, но в силу значения ОС он выделен отдельно * config Параметры конфигурации, которые что-то меняют внутри модуля. Модуль пишутся на выбранном языке программирования и описываются специальным макроязыком в коментах, типа /* module DCT import call import jump import read import modify os export call export jump export read export modify configure */ тута код модуля /* end module DCT */ У модуля есть понятие класс и член класса. В файлах проекта может быть много модулей с одинаковым названием и одинаковыми свойствами, но разной реализацией при разных параметрах конфигурации. Есть тулза как макрос для редактора, которая проверят модуль на соотвествие своему описанию. И подразновидность тулзы, которая готовит заготовку для описания на основе анализа куска кода. Тулза также умеет фолдить модуль подобно функции. Проект - это совокупность файлов. В зависимости от параметров конфигурации набор файлов меняется. Т.е. есть два варианта - все файлы проекта вообще и набор для конкретных параметров. Есть тулза. Ей задают набор файлов, она парсит их и вылавливает описания модулей. Также отмечает связи между модулями. Строится некий файл описания для набора файла. Есть понятие иерархии. Группа модулей может рассматриваться как одно целое, образуя супер модуль. Есть визуализатор, который рисует граф связей между модулями. Визуализатору задают уровни иерархии, до которых надо раскрывать граф. Также визуализатор отмечает множественость реализации модулей, если она есть в наборе. Есть тулза для задания уровней иерархии - пишем описание модуля как обычно, а затем отмечаем, что вот такие модули находятся внутри. Такая система сильно напоминает С++ (верятно, она отражает мое текущее понимание этого языка), но при этом: * полностью совместима с проектами, написанными в С идеологии (конечно, в ++ можно втащить С код, но он не впишется в ООП структуру С++, ради которой все и затевалось) * упрощает понимание структуры проекта. * сочетает эффективность асмовых вставок с преимуществами высокоуровневых языков * эффективно управлять своим мышлением. С пониманием структуры ситуация следующая. Простой граф всех функций и их взаимосвязей для более-менее сложного проекта - это полный пипец, он бесполезен для практики. Заставлять машину понимать, какая группа функций составялет некую сущность - полный бред. Такие вещи должен делать человек. В рамках описаной структуры легко управлять уровнем детализации. Нужно стремиться к тому, чтобы любой рисунок структуры был не более А4 (при разумном шрифте :)Т.е. посмотрели на струтуру проекта - вот тут ОСь, вот тут JPEG кодер, вот тут FS, вот ту IP, тута USB примостился. Далее, JPEG кодер - это вот эта портянка: DCT, квантователь, форматтер выходного потока. DCT - это: ... Также такой подход возволяет увидеть "лишние" далекие связи между модулями и понять - а они реально нужные или это глюк. "Далеких" связей надо избегать. При проектировании системы с 0 такой подход позволит очень хорошо продумать систаму. При этом полученный текст описаний модулей будет готовым ТЗ для программистов (или для самого себя на другом уровне мышления). При использовании такой технологии можно смело пользоваться асмовыми вставками и прочими аппапартно зависимыми вещами. Т.е. у нас есть класс - накладываем маску шрифта на память (типа кусок GUI). Ок. Есть C экземпляр класса, есть для AVR, для ARM, для CF. Код пойдет на любом проце и в синтетической системе. Просто подключаем разные файлы и задаем параметры конфигурации. Для этой технологии хорошо бы сделать некий адаптер кода. Типа вот кусок на асме. Мы его можем откомпилировать в С файл для GCC, для IAR, для RV и т.д. с их индивидульными "фичами". Всякое обрамление прерываний тоже хорошо при помощи такого "адаптера" делать. Вероятно, такой адаптер стоит на COG или templarian сделать. При анализе и импорте чужого кода будет тоже очень удобно. Смотрим код глазками. Видим - вот вроде кусок осмысленный. Ага, описали его как модуль. Построили схему. Сразу станет понятно, как код устроен. Полагаю также, что систему можно поднять по частям. Написать вначале парсер наших комментов и визуализатор, потом чекер того, что между началом и концом модуля и т.д. Заодно потихоньку синтаксис устаканить. Типа VMDL и получится http://caxapa.ru/92871.html Вот какой прогресс в понимании за месяц. Код, описанный по стандарту VMDL, являеся идеальным объектом для его шаринга и продажи. Предлагаю объеднить усилия по созданию синтаксиса описания, парсера и простейшей рисовалки на graphviz. Потом чекером займемся.