Микроконтроллеры

поправляю еще раз прямую адресацию для DATA в 51м семействе можно использовать только для младших 128 байт, как вы знаете. Из этих 128 минимум 3 банка по 8 байт (регистровые банки) нужно вычесть. Еще 16 байт могут использоваться как битовая прямоадресуемая память, что тоже бывает очень полезно, по крайней мере расходовать на булевые переменные 1 бит, а не 1 байт -- это весьма пользительно. Я редко пользую все 16 байт на эти нужды, но положим 8 байт. Плюс еще 8 байт на некоторые плюс-минус. Итого, сколько получается? 128 - 32 = 96 байт прямо адресуемой свободно доступной памяти. Это много или мало? Скорее всего мало, если сравнивать только цифры. Свою стратегию размещения переменных, которые не умещаются в xdata, я уже описал. Если вы ее не увидели или не захотели увидеть - ваше дело. Я делалл определенные замеры производительности, и даже простой здравый смысл подсказывает, что операции с float выполняются много-много тактов, гораздо дольше, чем операции чтения/записи xdata. Операции умножения/деления long выполняются гораздо дольше, чем операции чтения/записи xdata. Продолжить считать для массивов, особенно сложной структуры? Итого, что мы имеем: реальные ограничения в архитектуре самого 51го процессора (а цыгналы - это они самые, потомки 51х). Потому никакой кейл, ни SDCC тут вам радикально не помогут. Тут в фундаменте проблема. Потому и разговоры про шасси. Что такое изделие в серии я прекрасно понимаю, поэтому если вы не собрались писать новый улучшенный компилятор с более оптимальной стратегией использования памяти, то делать нечего. Придется смириться с тем, что вы бодро и весело нашли узкое бутылочное горло в работе с памятью. Либо переписывать критические участки на ассемблере. Если у вас есть реальные тесты для сравнения оптимальности Кейла и SDCC -- все здесь присутствующие будут просто рады их увидеть. Я даже готов вывесить их на своем сайте, как заинтересованное лицо, потому как с недавнего времени я заинтересовался этим компилятором. С кейлом я работаю много, и должен сказать, что к нему нужно некоторое время привыкнуть и найти стратегии оптимального написания кода -- путем многократного просматривания ассемблерных листингов компилятора и итеративного переписывания кода, чтобы достигнть макисмальной эффективности. Я уже давно не замерял эффективности своего кода, но порой оверхед настолько незначителен, что с ним легко смириться или переписать что-то действительно критическое на ассемблере. И доступ к памяти у меня обычно вызывает меньшую часть раздражения. Кстати, насчет вашего выпада: "Кстати, для особо образованных крайне рекомендую посмотреть скорость обмена с data и xdata самолично и на осциле, прежде чем оспаривать очевидное. Я это сделал сразу-же...". Для того, чтобы это оценить и осцилла даже не нужно. Достаточно калькулятора и листочка бумаги.