Evgeny_CD, Архитектор (05.04.2009 21:12, просмотров: 161) ответил =AlexD= на Ну раскрытие может делать препроцессор самого языка, если его правильно натравить. А вообще необходим контроль результата на всех уровнях вплоть до АСМа, для контроля корректности и сложности кода. Идеальным решением могло бы быть предкомпиляция в
Именно так! Создается глобальная база: * протокод
* все описания, каменты, дока
* код на С
* асмовый объектый код, сгенеренный компилером, с относительными ссылками
* абсолютные и относительные адреса всех сущностей программы - по результатам линковки
Далее ты жонглируешь всеми этми сущностями. Написал кусок кода в рамках файла. Довел до состояния компилируемости. Компильнул с дебаг информацией и асм листингом. Все это всосалось в БД. Навел курсор - тебе тут же показали, в какое асм-уе.. компилер превратил твой гениальный код :)
Довели до состояния сборки проекта. Собрали нечто. Загрузили в симулятор. Начинаем дрочить тестами. БД по адресами памяти у нас есть, пишем триггера (как в SQL) на обращения к памяти симулятора. Все полностью втоматическое!!! никакого IDE с расставления ручками параметров слежения дебугера. У тебя есть список всех переменных. Выбираешь, что тебе надо из иерархического списка, и пишеь простой код на Python что есть проверка данной переменной. Код, естественно, в базу. Он связан именно с этой переменной. А в дебугере ты тольо видишь - у тебя все наблюдаемые объекты зеленые, или кто-то красный. Щелк на него - и понимаешь, что не так.
Ага, тест (критерии непрвильности) ты задал неверно. Ну ок - переписал, запустил заново.
Полное протоколирование. Например, все изменения ячейки памяти пишуься в SQL базу с пивязкой к таймеру тиков ядра от начала симуляцмм. Задать к этой базае вопрос - а когда эта ячейка стала >0? - достаточно просто.
Да, пысюк для такой IDE нужен мощный. Но 4 ядра и 4Г памяти - это уже общее место сейчас.