24-битный цвет. Есть ли другие решения?, Ну очень неудобный формат. Опции

[DpInRock]

Начал программировать графическую подсистему. Цвет - 24 бита, упакованный. (at91sam9261). Т.е. в одном 32-разярядном слове находятся части двух точек (24 бита от одной, и кусок в 8 бит от другой. Может такде 16 бит от одной, 16 бит от другой, а недостающие 8 бит вообще в других словах).

И вот приходится цвет разбивать на RGB составляющие и записывать побайтно.

Вопрос в чем: это так и должно быть или есть какие-то хитрые решения? А то за быстродействие такого подхода боязно маленько.

[DpInRock]

Чудес не бывает. Кэш поможет, если внутреннее ОЗУ используется каким-нибудь прямым доступом. Тогда, программа исполняется в кэше и разгружает шину. И от соотношения размеров программы, размеров кэша... Вот посмотрю на конечный свой размер. Будет 32 к, к примеру, так я кэшем все остальное сделаю. Вообще из кэша вылезать не будет. Короче, вопросы оптимизации - на потом.

У меня, к сожалению, нет рабочего образца платы. А лезть совсем в глубину без железки крайне скучно.
Посему заострил пока (пока) на данном этапе вопросы чисто алгоритмические, не привязанные к харду.

[aaarrr]

Чудес не бывает. Кэш поможет, если внутреннее ОЗУ используется каким-нибудь прямым доступом. Тогда, программа исполняется в кэше и разгружает шину. И от соотношения размеров программы, размеров кэша... Вот посмотрю на конечный свой размер. Будет 32 к, к примеру, так я кэшем все остальное сделаю. Вообще из кэша вылезать не будет. Короче, вопросы оптимизации - на потом.

Программа всегда исполняется из кэша, если он включен для данной области. Кроме того, данные будут лежать в своем кэше на отдельной шине процессора - разница чувствуется?

У меня, к сожалению, нет рабочего образца платы. А лезть совсем в глубину без железки крайне скучно.

Работу кэша, MMU, TCM и т.п. как раз и стоит изучить без железки. Очень полезное знание.