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

[Ну что, заждались "настоящих" постов? Я не обманываю своих фанатов!!!] Полностью портабильная система разработки софта. Под любую ОСь | любое железо. И то, и другое не известно на этапе разработки. Есть объекты в памяти. Структуры в терминах С. Пусть даже состоящие из одного члена. Есть операторы. Они производят некие базовые действия над объектами. Есть "язык управления операторами" - С|C++ с функциями и макросами. Чуток расширенный, компилится в "нормальный" при помощи COG|Templarian. Есть виртуальный процессор, исполняющий P-code. Важно! Этот P-code не предназначен для реального исполнения со сколь-нибудь разумной скоростью. Он предназначен для того, чтобы из него быстро откомпилить в целевой код. Процессор предельно прост. Безрегистровый и безаккумуляторный. Brainfuck (http://ru.wikipedia.org/wiki/Brainfuck) является хорошими прототипом. Это нужно вот почему. Если компилировать в реальный или полуреальный проц (как сделано в http://www.gnu.org …ware/lightning/manual/ ), то будут раки, если целевая архитектура сильно отличатеся от виртуальной - другой набор регистров, сегмент:офсет и пр. Есть компилятор, который компилит наш С код в P-code. Это GCC, в котором переписан уровень bin utils. На выходе получаем P-code, подлежащий компиляции на целевой платформе. Есть финальный компилятор. Пишется самостоятельно. Из P-code делает целевой код. Библиотеки с ним идут довольно простые. На этом этапе компилятор избавлен он семантического анализа, и может максимизировать усилия по кодогенерации. Можно использовать адаптивные многопроходные стратегии. Заметим, при таком подходе стандарт вызова функций уже не важен. Финальный компилятор анализирует кусок кода, и оптимально раскладывает переменные по памяти и регистрам. В разных кусках кода стандарт вызова будет свой. :) Компилится будет долго, но на то 4-х ядерные 4Г RAM машины и нужны. Зато эффективность можно достичь выше, чем при ручном кодинге :) Есть micro OS. Простой набор примитивов. Все сервисы не являются частью ядра и вынесены в отдельные, динамически загружаемые модули. Сервисы поставляются в виде модулей на P-code. Микроядро может работать как угодно - поверх железа с полным контролем оного, с MMU, без него; как юзеровская задача на host OS - пофиг. Набор конечного юзера: * микроядро, портированное под целевую архитектуру * финальный компилятор, портированный под целевую архитектуру. Компилер трудится под управлением микроядра - чтобы портировать было проще. * либы ОСи в виде P-code. Компилятся в целевой бинарник финальным компилятором. * юзеровские приложения в виде P-code. Компилятся в целевой бинарник финальным компилятором. Набор девелопера * master GCC, портированный под host платформу * тулчейн для той же среды (редакторы, make, Scons и пр.) * симулятор виртуального процессора, исполняющий P-code в режими интерпретации * GDB, прохаченный под P-Code и умеющий работать с симулятором * end user комплект для хост платформы Кто дочитал до этого места, резонно спросит - а нафига оно нам? У нас нет лишних 100m$ и 100 человеко-лет программеров. Спокойствие!!! Центральное место!!! Для embedded варианта P-code=C lite. Упрощенная версия С, которая эффективно обрабатывается любым компилером под любую платформу. Выгода получается просто колоссальная. 1. Выжимаем все из кода. Статическое выделение, динамическое, асмовые вставки, inline на уровне препроцессора (чтобы не зависить от компилятора) - можно достичь предельной эффективности. Никаких ограничений. 2. C-lite безопасен с точки зрения интеллектуальной собственности. В 10 мбайтном файле стиля func_001(); var_002 без каментов и выделенных типов данных (все они приведены к целевым на этапе обработки COG|Templarian) разробраться так же не просто, как в бинарнике. Тут даже IDA не поможет :) 3. Тем не менее, в отличие от бинарной либы, такую шнягу юзер вполне может дебажить! И напишет потом: "Я на знаю, что такое func_00012(), но строка var001=var988977/var65323 там лишняя, ибо двумя строками выше var65323 приравнивается переменной, которую я передаю сервису ОСи OS_TASK_CREATE. А я передаю эту переменную =0. Докой не запрещено." 4. Не надо изобретать свои компиляторы. С компилеров полно, куча народу их постоянно совершенствует - так нафига повторять то, что они сотворили???? C-lite - это ключ к эффективности разработок. Его можно использовать и без описанных выше виртуальных понтов. Выводы 1. Есть машинный код. Можно писать на нем (лично писал для 8048, 8080), но шибко муторно. Есть ассеблер. Писать удобнее - но тоже муторно. Есть С. Который преобразуется в асм. Кто мешает нам писать на С 2.0, который будет компилится в С? Еще один уровень матрешки. 2. Unix идея рекомпиляции приложения на каждой платфоме гениальна и правильна. Но сейчас она доведена до маразма - горы несовместимых либ разных версий, 10м make файлы, исходники, не читаемые по причине множества if def, пр. Значит, надор все упростить. Чтобы на входе был один большой файл, и для его преобразования в исполняемый код нужен только С компилер и линкер. Ну может либа какая примитивная, но в иделае вообще без нее. 3. Компиляция одним файлом - долго, но эффективно. По многим источникам, GCC в варианте больших проектов дает экономию до 10% при неуменьшении скорости (компилятор анализирует большой фрейм кода, ему есть где развернуться). 4. Пытоном, похоже, надо все-таки заняться по взрослому. Понятно, что все эти тулзы надо на пытоне создавать. Без вариантов. Просьба Пиплы, раскритикуйте, плиз. Это один из мои центральных постов в 2007 году.