fk0, легенда (28.02.2020 00:09, просмотров: 675) ответил POV_ на АСМ - не торт, но 8 бит-то тут при чем? Если нет необходимости паралельно (прерывания-гиперлуп) менять многобайтные переменные, то нет проблем...
При наличии полноценного компилятора не при чём (не хуже чем 16 бит). Но как правило с этим проблемы. Для всех кроме AVR у многих до сих пор C89 не в полном объёме... Со стандартной библиотекой (не работающие printf, ага) тоже плохо. Дело конечно не в разрядности CPU, но есть корреляция, что на более высокоразрядном CPU компилятор и библиотека более качественные. Медленная работа наконец. Где на 16/32 битном одна инструкция, на 8-битном несколько. Да и оптимизация никакая (AVR vs PIC не говоря уж ARM/MIPS vs PIC). Странные ограничения (не более 256 байт локальных переменных на функцию у PIC18, из-за баночной организации памяти). Гарвардская архитектура с невозможностью хранения текстовых строк в flash или адресации их как "const char*" (единственное что у пиков сделано по-человечески), в итоге секция .rodata либо съезжает в ОЗУ (которого и так кто наплакал), либо код становится не переносимым. Отсутствие в процессоре специфических команд атомарного изменения переменных (актуально при наличии RTOS): bit set and test, fetch and add, compare and swap, не позволяющих эффективно реализовать примитивы синхронизации (мьютекс) и lockless алгоритмы. Отсутствие аппаратной защиты памяти, в итоге многие ошибки вместо исключения ведут к непонятным глюкам. Да много чего ещё... У всех ARM более-менее приличный отладчик например.
CF8051F120 тоже программировал (лет 15 тому назад): был ворованный KEIL и силабсовская среда. В итоге в кейле как бы можно всё, но на практике ничего: отладка через uVision тормозит адски и глючит (фирменный адаптер EC2). В силабсовской среде ничего делать вообще невозможно, но кое-как позволяет программировать и отлаживать, и подхватывает символы от Keil. В итоге собирал через Keil, потом научился через Makefile (потому, что в Keil нужные крыжики с опциями от компилятора не натыкать было), отлаживал если нужно было (чего пытался избежать) в силабсовской IDE (где показывалось дай бог половина переменных и было пошаговое исполнение и брейкпоинты, больше ничего), код писал в Vim. Для упрощения отладки был HAL для ПЦ с которым основная часть программы собиралась и имитировала работу -- большинство багов ловилось на ПЦ. Так же отлаживал printf'ом в компорт. Запомнилось, что несмотря на 100МГц работает всё чертовски медленно из-за протаскивания всех переменных программы через игольное ушко одного регистра DPTR. Второй DPTR Keil не умел использовать или его не было у процессора, не помню. Вообще это от модели памяти зависило -- тормозило в large. В small можно писать быстрые программки, но в смешном объёме памяти, что было чаще бесполезно и годилось только для обработчиков прерываний. Часть программы (управление ШД) потом переехала на атмегу, где на 8МГц работала в общем веселее... Ещё ручное раскладывание переменных по сегментам (data, xdata, стек и т.п.) помню, ручную расстановку static где можно для ускорения и т.п., фактически работу по оптимизации приходилось делать руками: смотришь ассемблер, понимаешь почему медленно, что-нибудь переписываешь и так в цикле. Программируя под ARM таким заниматься даже не вспомнишь, там компилятор выше тебя на две головы обычно.
[ZX]