Возможность программирования на более низком, чем ОЛ схемы уровне

[Владимир Ситников]

Так в чем проблема обозвать макрос как "написанный на С" и откомпилировать его отдельно, а редактор связей свяжет его по именам переменных (входов/выходов)?

Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.

Приведу пример: сложно будет поддержать этот "написанный на C" в режиме "симуляции".
Допустим, с помощью лома получилось из C текста получить бинарный код. Внимание, вопрос: как тестировать этот макрос? Как тестировать программу, использующую этот макрос?
Не забываем, что online режима у ПР нет, т.е. возможности "залить в ПР" для теста тоже нет.


Но и сама задача "скомпилировать" непростая. Разрабатывать свой C-компилятор это неблагодарное дело, а прикручивать сторонние непросто.

[starmos]

Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.
Внимание, вопрос: как тестировать этот макрос? Как тестировать программу, использующую этот макрос?
Но и сама задача "скомпилировать" непростая. Разрабатывать свой C-компилятор это неблагодарное дело, а прикручивать сторонние непросто.

Вы никогда не сталкивались с системами схемотехнического моделирования, Proteus то же? Нарисованная схема моделируется в "реальном" времени, при этом модели могут быть макро (содержать в себе тоже схему) или выполненными в текстовом виде, а микроконтроллер на схеме может моделироваться с учетом его программы, написанной на С. Как они это делают - для меня тоже загадка, но сам факт несомненен. Но такого даже и не надо вовсе.
"Прикрутить" к среде разработки тот или иной компилятор - обычное дело, например софт для микроконтроллеров Atmel можно разрабатывать на С с помощью нескольких компиляторов, это вообще обычно для микроконтроллеров, а что и как компилировать - задается в командных файлах. Сперва видится проход компилятора из схемы в C, макросы на С - пропускаются, а затем проход компилятора С уже полностью. Как вариант.