fk0, легенда (13.05.2014 19:27 - 19:41, просмотров: 6652)[ZX]
-
- Вдогонку. Тот же самый код, что давал ~25кБайт для пика, ~23кБ для GCC (RL78) и 14кБайт для ARM-GCC дал аж 16кБайт при компиляции IAR (для RL78). Вот это прогресс! Из минусов: IAR весьма своеобразен и для нормального C-программирования подходит fk0(272 знак., 23.05.2014 17:30)
- Что-то не припомню у яра нестандартности. Компромат - в студию. - SciFi(23.05.2014 17:33)
- А какой у вас компилятор? У GCC оптимизатор мягко говоря плох. - amx(13.05.2014 22:08)
- Да, плох. ABI плохо. Всё в стек заталкивает. Регистров мало. Масса лишних MOV инструкций из-за того. 1-байтность многих инструкций сглаживает ситуацию, но по скорости явно сильно проигрывает pic24. Оптимизация -O1...-O3 и -Os практически (или fk0(25 знак., 14.05.2014 13:37)
- PS: хотел спросить сразу. Смотрю gcc rl78 для указателей на функции вызывает их по 16-битному адресу. Это что ж это такое делается! Прямо как pic18 -- вручную что ли следить, чтоб функции вызываемые по указателю ложились в первые 64к??? Как fk0(68 знак., 14.05.2014 13:39)
- Оптимизации отличаются :( Если на О3 страшно смотреть, то выхлоп О0 будет сниться в кошмарах. С указателями всё ровно наоборот: amx(350 знак., 14.05.2014 13:50 - 13:53, ссылка)
- Пусть страшно, пусть любители любительских контроллеров в ужасе прячутся... Но с указателями принципиальная проблема. Большая часть флеша, в т.ч. не отзеркаленная, содержит код. В коде может быть вызов qsort(), например, с указателем на функцию. fk0(467 знак., 14.05.2014 13:54)
- Вы серьезно это пишете? А то очень сложно стало различать ваши сообщения "по теме" и иронию. - Ralex(14.05.2014 13:51)
- Абсолютно серьёзно. Какая ирония, если получается, из-за невозможности использования указателей я не могу перенести готовое ПО объёмом больше 64к. Следовательно, нужно отказываться от RL78 в пользу dspic или ARM. Компилятор платный не смотрел. Но fk0(44 знак., 14.05.2014 14:00)
- Неужели нет опции компилятора - Large Code Memory Model? - MBedder(14.05.2014 14:37)
- Абсолютно серьёзно. Какая ирония, если получается, из-за невозможности использования указателей я не могу перенести готовое ПО объёмом больше 64к. Следовательно, нужно отказываться от RL78 в пользу dspic или ARM. Компилятор платный не смотрел. Но fk0(44 знак., 14.05.2014 14:00)
- Оптимизации отличаются :( Если на О3 страшно смотреть, то выхлоп О0 будет сниться в кошмарах. С указателями всё ровно наоборот: amx(350 знак., 14.05.2014 13:50 - 13:53, ссылка)
- PS: хотел спросить сразу. Смотрю gcc rl78 для указателей на функции вызывает их по 16-битному адресу. Это что ж это такое делается! Прямо как pic18 -- вручную что ли следить, чтоб функции вызываемые по указателю ложились в первые 64к??? Как fk0(68 знак., 14.05.2014 13:39)
- Да, плох. ABI плохо. Всё в стек заталкивает. Регистров мало. Масса лишних MOV инструкций из-за того. 1-байтность многих инструкций сглаживает ситуацию, но по скорости явно сильно проигрывает pic24. Оптимизация -O1...-O3 и -Os практически (или fk0(25 знак., 14.05.2014 13:37)
- А если thumb-2 (кортексы всякие) сравнить? - Evgeny_CD(13.05.2014 21:47)
- Имеет ли какой-то смысл использовать RL78, когда есть ARM? - fk0(13.05.2014 20:06)
- Вероятно, имеет смысл при четком соответствии аппаратных фич решаемым задачам. Что в + у RL78: Evgeny_CD(796 знак., 13.05.2014 21:46)
- Не вижу особого смысла в более чем одном банке. Компилятор же многобанковость использовать не может. Актуально, стало быть, для обработчика быстрых прерываний только и т.п. задач. Для многозадачности ни к чему (там много чего переключить нужно и 4 fk0(515 знак., 14.05.2014 13:04)
- Вероятно, имеет смысл при четком соответствии аппаратных фич решаемым задачам. Что в + у RL78: Evgeny_CD(796 знак., 13.05.2014 21:46)
- Вдогонку. Тот же самый код, что давал ~25кБайт для пика, ~23кБ для GCC (RL78) и 14кБайт для ARM-GCC дал аж 16кБайт при компиляции IAR (для RL78). Вот это прогресс! Из минусов: IAR весьма своеобразен и для нормального C-программирования подходит fk0(272 знак., 23.05.2014 17:30)