ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
26 апреля
731374 Топик полностью
Evgeny_CD, Архитектор (26.01.2017 14:43, просмотров: 134) ответил LightElf на В развитие темы. Просто накидаю идеек, может кто что умного покритикует.
Некоторый набор мыслей. 1. Требования к компилеру. Вероятно, кроме описанного Вами, надо, чтобы у компилера был стартовый код под конкретный камень (всякие там PLL настраивать), а также, вероятно, setjump и longjump http://www.geeksfo …-setjump-and-longjump/ Вот чувак эксепшены в С уже много лет пытается сделать из setjump и longjump :) http://www.di.unip …mp_try_trow_catch.html Где гарантия, что setjump и longjump совершенно одинаково работают на всех платформах, включая Win и Linux? Также необходима поддержка прерываний. 2. Требования к квалификации писателя кода под NewOS. В целом, кооперативка требует более интенсивной работы содержимого черепной коробки - если хочется достичь вменяемого результата. Получим необходимость искать баланс - сложность понимания кода под кооперативку - диапазон достижимых возможностей. 3. Безопасность кода. С препроцессор - это граната в руках обезьяны. С ее помощщью можно сделать все, но взорвать себя самого - получается лучше всего. В примере про "ексепшены на setjump и longjump" это наглядно показано. 4. Стиль кооперативки. Их может быть очень много - машина состояний, сопрограммы, еще 100500 вариантов. Как минимум, нужен хороший учебник, поясняющий (себе самому в первую очередь) суть всех использованных концепций. В кооперативке семое неприятное - ручное управление передачей управления. Если опрашивать флаг "запрос на передачу управления" после каждого оператора - это сделает говнокодом любой суперкод. Если делать это после некоторого осмысленного блока - легко при редактировании кода упустить момент, что блок будет выполняться слишком долго, и пропустить момент передачи управления. 5. Генерация модифицированного кода. В качестве альтернативы суперпортируемому С коду (это такая мечта, которая живет от момента появления С, и до сих пор так и не стала явью) я бы предложил простой кодогенератор. Пишется некий обобщенный исходный код на "plain С с разметкой". Например, asm вставки и файлы пишутся в некой удобной автору стилистике. Атрибуты аналогично. Типа EEPROM. А дальше есть скрипт-модифиатор, который знает, как строку кода на "обобщенном С" трансформировать в строку С кода код конкретный компилер. Этот крипт и "компилит" обобщенный С код в код для компилера. Для отладочных синтетических портов под Win|Linux|MACOS такой настройщик просто бесценен, без него сделать такой порт весьма непросто, очень много ручной работы. 6. Без срипта-настройщика исходных кодов ни одна качественная ОСь не обходится. Проанализироать, что за сервисы ОСи захотели юзера и настроить код ОСи, всякие статические настройки - это должна быть работа срипта, а не ручное программирование. Python, TCL, Perl - идут на всех платформах, есть в удобном виде от той же ActiveState http://www.activestate.com 7. И тут мы подходим к главному - а зачем только кооперативная ОСька? Если при помощи "срипта-кодогенератора" обеспечить переносимость единожды написанного кода под все среды, генерящие код под конкретную плафторму - то почему бы не иметь аналог Contiki OS http://caxapa.ru/599497.html Она вытесняюшая, но в потоке можно запустить сопрограммы. Резюме. Прежде, чем начинать кодить, надо написать учебник по будущей ОСи и осознать ее. Хотя бы в виде кратих заметок. Без этого ни коммунити не собрать, ни самому себе ответить на вопрос - а что и зачем ты делаешь? Кстати, про 8 битники не стоит забывать - AVR еще в строю, у STM8 есть поклонники (я не из их числа, но минимум 1к ОЗУ - это интересно!)