Bопрос по АРМ9, Обработчики прерываний Опции

[axa09]

контроллер at91rm9200. частота ядра 180мгц, шина 60мгц. на шине статическая память с 16-битной шиной, с NWS=0(без дополнительных тактов). кеши оба включены-память закеширована write-back, в ней исполняется программа.
обработчики прерываний в этой памяти.

вопрос-
если обработчики разместить во внутренней sram контроллера,будет ли выигрыш в производительности?
или с кешами это не принципиально?
как обработчик прерывания в keil скопировать из одной памяти в другую с учётом коррекции счётчика адреса(РС?)

И ещё-пробовал стек делать во внутренней памяти - на глаз быстродействие не изменилось

[aaarrr]

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

Теоретически выигрыш может быть, так как внутренняя память все же быстрее. На практике все зависит от конкретного случая.

как обработчик прерывания в keil скопировать из одной памяти в другую с учётом коррекции счётчика адреса(РС?)

А зачем? Не проще его сразу по нужному адресу положить?

И ещё-пробовал стек делать во внутренней памяти - на глаз быстродействие не изменилось

Значит, в вашей программе не так уж часто нужен стек.

[sergeeff]

контроллер at91rm9200. частота ядра 180мгц, шина 60мгц. на шине статическая память с 16-битной шиной, с NWS=0(без дополнительных тактов). кеши оба включены-память закеширована write-back, в ней исполняется программа.
обработчики прерываний в этой памяти.

вопрос-
если обработчики разместить во внутренней sram контроллера,будет ли выигрыш в производительности?
или с кешами это не принципиально?
как обработчик прерывания в keil скопировать из одной памяти в другую с учётом коррекции счётчика адреса(РС?)

И ещё-пробовал стек делать во внутренней памяти - на глаз быстродействие не изменилось

Кеш работает с такой же частотой, что и внутренняя SRAM. Посему разница ничтожна. А стек в ARM'ах задействуется не столь часто, только когда не хватает внутренних регистров. К тому же современные компиляторы стараются оптимизировать скорость выполнения потока команд, учитывая pipeline.

[axa09]

За ответы спасибо!
с праздником!

можно повысить производительность системы путём манипуляций с кешами?
сейчас таблица трансляции адресов(по 1мб) находится в кешируемой области внешней памяти. вся память кроме регистров кешируема и буферизована(биты cachable и buferable равны 1). кеш асинхронный.
подскажите дальнейшие пути повышения производительности:
1)при выполнении кода
2)при блочном чтении из памяти
3)при блочной записи в память
слышал, что перед передачей данных надо втыкать prefetch. можно по-подробнее?
есть ещё invalidate,flush и др. как их пользовать?

извините за кашу в голове- просто хочется разобраться, помогите плиз.

[aaarrr]

можно повысить производительность системы путём манипуляций с кешами?

Можно, но не в разы. Судя по описанию, ваша система и так правильно настроена.
Заниматься тюнингом производительности следует только при наличии насущной необходимости. Она есть?

сейчас таблица трансляции адресов(по 1мб) находится в кешируемой области внешней памяти.

Напрасно.

кеш асинхронный

Режим тактирования имеется в виду?

[axa09]

Надо хотябы на 25% повысить.
почему напрасно?
как правильно и на что влияет?

ДА! режим тактирования имел ввиду.

[aaarrr]

Надо хотябы на 25% повысить.

Повысить для каких условий? Если у Вас есть некая функция, которую необходимо ускорить, то оптимизацию следует начинать с ее кода, а уж в последнюю очередь пытаться оптимизировать работу кэша.
Просто повысить производительность системы на 25% невозможно.

почему напрасно?

Потому что выборки из таблицы трансляции не идут через кэш. Расположение таблицы ни на что не влияет.

[sergeeff]

За ответы спасибо!
с праздником!

можно повысить производительность системы путём манипуляций с кешами?
сейчас таблица трансляции адресов(по 1мб) находится в кешируемой области внешней памяти. вся память кроме регистров кешируема и буферизована(биты cachable и buferable равны 1). кеш асинхронный.
подскажите дальнейшие пути повышения производительности:
1)при выполнении кода
2)при блочном чтении из памяти
3)при блочной записи в память
слышал, что перед передачей данных надо втыкать prefetch. можно по-подробнее?
есть ещё invalidate,flush и др. как их пользовать?

извините за кашу в голове- просто хочется разобраться, помогите плиз.

Да уж конечно надо смотреть в сторону собственно обработчика прерываний. Что за скорость то нужна, если 180 МГц rm9200 не хватает?

[axa09]

Нужно ускорить переброс видеобуфера в дисплейную память(шина 8 бит, на ebi, i80).
тоесть если таблица трансляции расположена в кешируемой внешней памяти, то память не будет кешироваться?
и доступ к таблице будет медленным?
нужно ли кешировать внутреннюю память-срам 16кб?
где правильнее расположить таблицу трансляции?

[aaarrr]

Нужно ускорить переброс видеобуфера в дисплейную память(шина 8 бит, на ebi, i80).

А каким образом он осуществляется сейчас? Не побайтово, надеюсь?

тоесть если таблица трансляции расположена в кешируемой внешней памяти, то память не будет кешироваться?
и доступ к таблице будет медленным?

Будет, не волнуйтесь. Просто располагать ее в кэшируемой памяти нет смысла.

нужно ли кешировать внутреннюю память-срам 16кб?

Нужно.

где правильнее расположить таблицу трансляции?

В наиболее скоростной памяти. Но гробить под нее всю внутреннюю SRAM не стоит.

[axa09]

Пришла в голову мысль расположить таблицу во внутренней sram.
затрутся только reset, undef и swint.
irq, fiq останутся!
таблица у меня сильно фрагментирована.
тоесть во внутренней срам будут вектора прерываний, стек и таблица трансляции адресов!
отпишусь когда сделаю!
я- великий извращенец!

[AndrewN]

таблица трансляции адресов (по 1мб)

Подскажите пожалуйста, что это такое; где про это можно почитать и где
можно посмотреть какой-нибудь примерчик.

За ответы спасибо.
С праздником.

[axa09]

В общем удалось ради эксперимента таблицу запихать во внутреннюю срам.
прироста в скорости не дало
по ходу больше никак не выжать.

вот собственно задача:
есть буфер MxN байт- индексов другого массива(палитра).
требуется находить средние интенсивности компонент цвета из 4-х смежных точек(2х2 пиксела). короче,некое подобие фильтра при уменьшении картинки в два раза.
как можно сделать быстрее?
буфера во внешней памяти

[sergeeff]

Подскажите пожалуйста, что это такое; где про это можно почитать и где
можно посмотреть какой-нибудь примерчик.

За ответы спасибо.
С праздником.

Удивительное нежелание хотя бы на местном форуме сначала поискать, а потом уже вопрос вываливать! По принципу - пусть другие мне готовое на тарелочке преподнесут.

Смотри http://electronix.ru/forum/index.php?showt...&hl=d-cache

[aaarrr]

прироста в скорости не дало

И не должно было. Таблица буферизируется через TLB, чего в нормальной жизни вполне достаточно.

вот собственно задача:

Можно поподробнее? Чему равны M и N, что из себя представляет палитра, какие требования к скорости?

[sergeeff]

В общем удалось ради эксперимента таблицу запихать во внутреннюю срам.
прироста в скорости не дало
по ходу больше никак не выжать.

вот собственно задача:
есть буфер MxN байт- индексов другого массива(палитра).
требуется находить средние интенсивности компонент цвета из 4-х смежных точек(2х2 пиксела). короче,некое подобие фильтра при уменьшении картинки в два раза.
как можно сделать быстрее?
буфера во внешней памяти

Даже любопытно, как удалось 16 KB'ую таблицу запихнуть в 16 KB'ую SRAM и сохранить в ней таблицу векторов прерываний?

[axa09]

Даже любопытно, как удалось 16 KB'ую таблицу запихнуть в 16 KB'ую SRAM и сохранить в ней таблицу векторов прерываний?

все просто. прикиньте сами:
0x00000000 - внутренняя SRAM после ReMap - отхавает RESET(вектор 0)
0x00100000 - внутренний ROM - отхавает Undef (вектор 1)
0x00200000 - внутренняя SRAM всегда - отхавает SWInt (вектор 2)

далее не затираем. Поэтому IRQ и FIQ целые. Остальные не пользуем

0x00200400 - первый мегабайт SRAM (NCS0)
0x00200404 - второй мегабайт SRAM
итд...
0x00200С00 - периферия(дисплей) не кешируется и не буферизуется
...
стек в конце


О задаче по -подробнее:


//Буфер 256x240 исходного изобржения. Элемент -байт - индекс массива палитры
extern uint8 *Buf;

//Палитра. Каждый элемент 00rrr00ggg00bb- нули для того чтобы при сложении 4-х цветов небыло переполнения.
u16 PALETTE[256];

/*
256

1212121212..
3434343434..
1212121212.. 240
3434343434..
............
*/

/*
Далее ниже находим "средний пиксел"(среднее арифметическое каждой интенсивности R,G,
Для этого складываем все компоненты смежных пикселов "1"+"2"+"3"+"4"
Потом сдвигами и битовыми "И" приводим к виду RRrGGgBB = R:G:B=>3:3:2
И отправляем байт в дисплей (шина EBI,8бит, автоинкремент адреса, 128x120 авто-скругление по кадру)
*/

#define Pixel \
c =PALETTE[*(u8*) Buf ]; \
c+=PALETTE[*(u8*)(Buf+ 1)]; \
c+=PALETTE[*(u8*)(Buf+256)]; \
c+=PALETTE[*(u8*)(Buf+257)]; \
Display_Data_Register=((c>>2)&0x03)|((c>>4)&0x1C)|((c>>6)&0xE0); \
Buf+=2;

void BlitScreen(u8 *Buf) //Отрисовка экрана
{
register u32 y,BufE,c;
for(y=0;y<120;y++)
{
BufE=(u32)Buf+256;
for(;(u32)Buf<BufE;)
{
Pixel
Pixel
Pixel
Pixel
}
Buf+=256;
}
}

//Таким образом изображение 256x240 ужимаем в 128x120 с применением палитры(конвертируем цвета)
// и "фильтра"(среднее значение компонент смежных пикселей 2x2)

Как можно оптимизировать быстрее??? На ассемблере?

[aaarrr]

Как можно оптимизировать быстрее??? На ассемблере?

Можно сначала попробовать соптимизировать чтение - читать данные 32-бит словами, сразу для двух блоков 2x2.
Ну, и листинг не грех посмотреть.

[axa09]

У меня память 16 бит шина данных. всёравно по 32 бита читать?
листинг смотрел-быстрее тот вариант, который с меньшим количеством обращений к памяти(операнды в квадратных скобках)
и всё-же, предложите свой вариант который,возможно, быстрее

[sergeeff]

0x00200400 - первый мегабайт SRAM (NCS0)

Значит 16 КБ таблица пишется с начальным смещением в 1 КБ в память объемом 16 КБ и там еще место под стек осталось? Так не бывает.

[aaarrr]

У меня память 16 бит шина данных. всёравно по 32 бита читать?

Вы все равно уже читаете кэш.

и всё-же, предложите свой вариант который,возможно, быстрее

Сколько занимает по времени этот вариант?

[axa09]

Вариант идёт с 45 преобразований/с. но это не чисто- ещё много другого в цикле делается(не путать с циклом отрисовки!)

по таблице. не надо все 16кб заполнять!
надо только память и периферию. остальное не имеет значение-всёравно обращений по этим адресам не будет!

[aaarrr]

Вариант идёт с 45 преобразований/с. но это не чисто- ещё много другого в цикле делается(не путать с циклом отрисовки!)

Т.е. не измеряли что ли?

CODE

#define Pixel \
a = Bufw[0]; \
b = Bufw[64]; \
c = PALETTE[a & 0xff]; \
c += PALETTE[(a >> 8) & 0xff]; \
c += PALETTE[b & 0xff]; \
c += PALETTE[(b >> 8) & 0xff]; \
Display_Data_Register=((c>>2)&0x03)|((c>>4)&0x1C)|((c>>6)&0xE0); \
c = PALETTE[(a >> 16) & 0xff]; \
c += PALETTE[(a >> 24) & 0xff]; \
c += PALETTE[(b >> 16) & 0xff]; \
c += PALETTE[(b >> 24) & 0xff]; \
Display_Data_Register=((c>>2)&0x03)|((c>>4)&0x1C)|((c>>6)&0xE0); \
Bufw++;


void BlitScreen(u8 *Buf)
{
u32 *Bufw = (u32*)Buf, a, b, c, y, x;
for(y = 0; y < 120; y++)
{
for(x = 0; x < 64 / 4; x++)
{
Pixel
Pixel
Pixel
Pixel
}
Bufw += 64;
}
}

25% не обещаю, но 15 точно должно быть. Buf должен быть выровнен по границе слова.
Только вот процедурка и в исходном виде достаточно короткая (меньше 5мс).

[sergeeff]

Совет. Длительность CS для вывода на дисплей соответствует тому, что минимально необходимо?

[axa09]

Спасибо! как проверю-напишу результаты и приведу асм-листинг обеих вариантов.

времянки дисплея выставлены максимально короткими.
любопытно,что повышение частоты шины не ведёт к увеличению итоговой производительности. а вот оверклочение ядра с 180 на 200 на глаз ощутимо повышением скорости выполнения программы!

[axa09]

Т.е. не измеряли что ли?

25% не обещаю, но 15 точно должно быть. Buf должен быть выровнен по границе слова.
Только вот процедурка и в исходном виде достаточно короткая (меньше 5мс).

В общем сегодня замерил свой и ваш варианты. Мой 206 FPS, ваш 203 FPS. Я даже расстроился
Листинги вложил сюда.

На всякий случай сообщаю настройки компилятора:
Keil Real View v3.3
Code generation: ARM-Mode
Use cross-module optimization

C compiler:
enable arm/thumb intervorking
optimization level 2 (-02)
optimize for time

ASM:
enable ARM/thumb interworking

Дополнительные ключи C компилятора:
--pointer_alignment=8
--min_array_alignment=8
--no_vfe

замерял производительность с двумя вариантами стеков: во внутренней срам и во внешней - тоже самое все.
пробовал PALETTE[] расположить во внутренней срам- тоже ничего не поменялось.

листинги решил вложить, так как вымахали большими.

есть подозрение что фиговый асм-код генерится.

в общем посмотрите плиз.
может что-то лишнее и вредное в настройках включено?
или надо что-то добавить?

если нетрудно, приведите плиз асм-код .

Прикрепленные файлы

 ______________________.txt ( 5.83 килобайт ) Кол-во скачиваний: 69
 ______________.txt ( 10.2 килобайт ) Кол-во скачиваний: 46

 

[aaarrr]

Запись во внешний медленный порт сильно портит все дело. Вот что получилось у меня (RVDS 2.2, полная оптимизация по скорости):

1. Без записи в порт, вместо регистра пишем кэшируемую память.
Ваш вариант 334 FPS, мой - 397 FPS. Разница заметна.

2. С записью в порт.
Ваш вариант - 215 FPS, мой - 221 FPS. Практически одинаково.

CODE

BlitScreen
$a
.text
0x00000000: e92d07f0 ..-. PUSH {r4-r10}
0x00000004: e1a03000 .0.. MOV r3,r0
0x00000008: e59f03f4 .... LDR r0,[pc,#1012] ; [.bss$5 = 0x404] = 0
0x0000000c: e3a0a000 .... MOV r10,#0
0x00000010: e3a06202 .b.. MOV r6,#0x20000000
0x00000014: e3a050e0 .P.. MOV r5,#0xe0
0x00000018: e3a0401c .@.. MOV r4,#0x1c
0x0000001c: e3a07000 .p.. MOV r7,#0
0x00000020: e5931000 .... LDR r1,[r3,#0]
0x00000024: e5932100 .!.. LDR r2,[r3,#0x100]
0x00000028: e201c0ff .... AND r12,r1,#0xff
0x0000002c: e2018cff .... AND r8,r1,#0xff00
0x00000030: e08083a8 .... ADD r8,r0,r8,LSR #7
0x00000034: e080c08c .... ADD r12,r0,r12,LSL #1
0x00000038: e1dcc0b0 .... LDRH r12,[r12,#0]
0x0000003c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000040: e088c00c .... ADD r12,r8,r12
0x00000044: e20280ff .... AND r8,r2,#0xff
0x00000048: e0808088 .... ADD r8,r0,r8,LSL #1
0x0000004c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000050: e088c00c .... ADD r12,r8,r12
0x00000054: e2028cff .... AND r8,r2,#0xff00
0x00000058: e08083a8 .... ADD r8,r0,r8,LSR #7
0x0000005c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000060: e088c00c .... ADD r12,r8,r12
0x00000064: e004822c ,... AND r8,r4,r12,LSR #4
0x00000068: e1a09e0c .... LSL r9,r12,#28
0x0000006c: e1888f29 )... ORR r8,r8,r9,LSR #30
0x00000070: e005c32c ,... AND r12,r5,r12,LSR #6
0x00000074: e188c00c .... ORR r12,r8,r12
0x00000078: e5c6c007 .... STRB r12,[r6,#7]
0x0000007c: e201c8ff .... AND r12,r1,#0xff0000
0x00000080: e1a01c21 !... LSR r1,r1,#24
0x00000084: e0801081 .... ADD r1,r0,r1,LSL #1
0x00000088: e080c7ac .... ADD r12,r0,r12,LSR #15
0x0000008c: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000090: e1d110b0 .... LDRH r1,[r1,#0]
0x00000094: e081100c .... ADD r1,r1,r12
0x00000098: e202c8ff .... AND r12,r2,#0xff0000
0x0000009c: e080c7ac .... ADD r12,r0,r12,LSR #15
0x000000a0: e1a02c22 ",.. LSR r2,r2,#24
0x000000a4: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000000a8: e0802082 . .. ADD r2,r0,r2,LSL #1
0x000000ac: e1d220b0 . .. LDRH r2,[r2,#0]
0x000000b0: e08c1001 .... ADD r1,r12,r1
0x000000b4: e0821001 .... ADD r1,r2,r1
0x000000b8: e0042221 !".. AND r2,r4,r1,LSR #4
0x000000bc: e1a0ce01 .... LSL r12,r1,#28
0x000000c0: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x000000c4: e0051321 !... AND r1,r5,r1,LSR #6
0x000000c8: e1821001 .... ORR r1,r2,r1
0x000000cc: e5c61007 .... STRB r1,[r6,#7]
0x000000d0: e5b31004 .... LDR r1,[r3,#4]!
0x000000d4: e5932100 .!.. LDR r2,[r3,#0x100]
0x000000d8: e201c0ff .... AND r12,r1,#0xff
0x000000dc: e2018cff .... AND r8,r1,#0xff00
0x000000e0: e08083a8 .... ADD r8,r0,r8,LSR #7
0x000000e4: e080c08c .... ADD r12,r0,r12,LSL #1
0x000000e8: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000000ec: e1d880b0 .... LDRH r8,[r8,#0]
0x000000f0: e088c00c .... ADD r12,r8,r12
0x000000f4: e20280ff .... AND r8,r2,#0xff
0x000000f8: e0808088 .... ADD r8,r0,r8,LSL #1
0x000000fc: e1d880b0 .... LDRH r8,[r8,#0]
0x00000100: e088c00c .... ADD r12,r8,r12
0x00000104: e2028cff .... AND r8,r2,#0xff00
0x00000108: e08083a8 .... ADD r8,r0,r8,LSR #7
0x0000010c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000110: e088c00c .... ADD r12,r8,r12
0x00000114: e004822c ,... AND r8,r4,r12,LSR #4
0x00000118: e1a09e0c .... LSL r9,r12,#28
0x0000011c: e1888f29 )... ORR r8,r8,r9,LSR #30
0x00000120: e005c32c ,... AND r12,r5,r12,LSR #6
0x00000124: e188c00c .... ORR r12,r8,r12
0x00000128: e5c6c007 .... STRB r12,[r6,#7]
0x0000012c: e201c8ff .... AND r12,r1,#0xff0000
0x00000130: e1a01c21 !... LSR r1,r1,#24
0x00000134: e0801081 .... ADD r1,r0,r1,LSL #1
0x00000138: e080c7ac .... ADD r12,r0,r12,LSR #15
0x0000013c: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000140: e1d110b0 .... LDRH r1,[r1,#0]
0x00000144: e081100c .... ADD r1,r1,r12
0x00000148: e202c8ff .... AND r12,r2,#0xff0000
0x0000014c: e080c7ac .... ADD r12,r0,r12,LSR #15
0x00000150: e1a02c22 ",.. LSR r2,r2,#24
0x00000154: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000158: e0802082 . .. ADD r2,r0,r2,LSL #1
0x0000015c: e1d220b0 . .. LDRH r2,[r2,#0]
0x00000160: e08c1001 .... ADD r1,r12,r1
0x00000164: e0821001 .... ADD r1,r2,r1
0x00000168: e0042221 !".. AND r2,r4,r1,LSR #4
0x0000016c: e1a0ce01 .... LSL r12,r1,#28
0x00000170: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x00000174: e0051321 !... AND r1,r5,r1,LSR #6
0x00000178: e1821001 .... ORR r1,r2,r1
0x0000017c: e5c61007 .... STRB r1,[r6,#7]
0x00000180: e5b31004 .... LDR r1,[r3,#4]!
0x00000184: e5932100 .!.. LDR r2,[r3,#0x100]
0x00000188: e201c0ff .... AND r12,r1,#0xff
0x0000018c: e2018cff .... AND r8,r1,#0xff00
0x00000190: e08083a8 .... ADD r8,r0,r8,LSR #7
0x00000194: e080c08c .... ADD r12,r0,r12,LSL #1
0x00000198: e1dcc0b0 .... LDRH r12,[r12,#0]
0x0000019c: e1d880b0 .... LDRH r8,[r8,#0]
0x000001a0: e088c00c .... ADD r12,r8,r12
0x000001a4: e20280ff .... AND r8,r2,#0xff
0x000001a8: e0808088 .... ADD r8,r0,r8,LSL #1
0x000001ac: e1d880b0 .... LDRH r8,[r8,#0]
0x000001b0: e088c00c .... ADD r12,r8,r12
0x000001b4: e2028cff .... AND r8,r2,#0xff00
0x000001b8: e08083a8 .... ADD r8,r0,r8,LSR #7
0x000001bc: e1d880b0 .... LDRH r8,[r8,#0]
0x000001c0: e088c00c .... ADD r12,r8,r12
0x000001c4: e004822c ,... AND r8,r4,r12,LSR #4
0x000001c8: e1a09e0c .... LSL r9,r12,#28
0x000001cc: e1888f29 )... ORR r8,r8,r9,LSR #30
0x000001d0: e005c32c ,... AND r12,r5,r12,LSR #6
0x000001d4: e188c00c .... ORR r12,r8,r12
0x000001d8: e5c6c007 .... STRB r12,[r6,#7]
0x000001dc: e201c8ff .... AND r12,r1,#0xff0000
0x000001e0: e1a01c21 !... LSR r1,r1,#24
0x000001e4: e0801081 .... ADD r1,r0,r1,LSL #1
0x000001e8: e080c7ac .... ADD r12,r0,r12,LSR #15
0x000001ec: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000001f0: e1d110b0 .... LDRH r1,[r1,#0]
0x000001f4: e081100c .... ADD r1,r1,r12
0x000001f8: e202c8ff .... AND r12,r2,#0xff0000
0x000001fc: e080c7ac .... ADD r12,r0,r12,LSR #15
0x00000200: e1a02c22 ",.. LSR r2,r2,#24
0x00000204: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000208: e0802082 . .. ADD r2,r0,r2,LSL #1
0x0000020c: e1d220b0 . .. LDRH r2,[r2,#0]
0x00000210: e08c1001 .... ADD r1,r12,r1
0x00000214: e0821001 .... ADD r1,r2,r1
0x00000218: e0042221 !".. AND r2,r4,r1,LSR #4
0x0000021c: e1a0ce01 .... LSL r12,r1,#28
0x00000220: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x00000224: e0051321 !... AND r1,r5,r1,LSR #6
0x00000228: e1821001 .... ORR r1,r2,r1
0x0000022c: e5c61007 .... STRB r1,[r6,#7]
0x00000230: e5b31004 .... LDR r1,[r3,#4]!
0x00000234: e5932100 .!.. LDR r2,[r3,#0x100]
0x00000238: e201c0ff .... AND r12,r1,#0xff
0x0000023c: e2018cff .... AND r8,r1,#0xff00
0x00000240: e08083a8 .... ADD r8,r0,r8,LSR #7
0x00000244: e080c08c .... ADD r12,r0,r12,LSL #1
0x00000248: e1dcc0b0 .... LDRH r12,[r12,#0]
0x0000024c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000250: e088c00c .... ADD r12,r8,r12
0x00000254: e20280ff .... AND r8,r2,#0xff
0x00000258: e0808088 .... ADD r8,r0,r8,LSL #1
0x0000025c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000260: e088c00c .... ADD r12,r8,r12
0x00000264: e2028cff .... AND r8,r2,#0xff00
0x00000268: e08083a8 .... ADD r8,r0,r8,LSR #7
0x0000026c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000270: e088c00c .... ADD r12,r8,r12
0x00000274: e004822c ,... AND r8,r4,r12,LSR #4
0x00000278: e1a09e0c .... LSL r9,r12,#28
0x0000027c: e1888f29 )... ORR r8,r8,r9,LSR #30
0x00000280: e005c32c ,... AND r12,r5,r12,LSR #6
0x00000284: e188c00c .... ORR r12,r8,r12
0x00000288: e5c6c007 .... STRB r12,[r6,#7]
0x0000028c: e201c8ff .... AND r12,r1,#0xff0000
0x00000290: e1a01c21 !... LSR r1,r1,#24
0x00000294: e0801081 .... ADD r1,r0,r1,LSL #1
0x00000298: e080c7ac .... ADD r12,r0,r12,LSR #15
0x0000029c: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000002a0: e1d110b0 .... LDRH r1,[r1,#0]
0x000002a4: e081100c .... ADD r1,r1,r12
0x000002a8: e202c8ff .... AND r12,r2,#0xff0000
0x000002ac: e080c7ac .... ADD r12,r0,r12,LSR #15
0x000002b0: e1a02c22 ",.. LSR r2,r2,#24
0x000002b4: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000002b8: e0802082 . .. ADD r2,r0,r2,LSL #1
0x000002bc: e1d220b0 . .. LDRH r2,[r2,#0]
0x000002c0: e08c1001 .... ADD r1,r12,r1
0x000002c4: e0821001 .... ADD r1,r2,r1
0x000002c8: e0042221 !".. AND r2,r4,r1,LSR #4
0x000002cc: e1a0ce01 .... LSL r12,r1,#28
0x000002d0: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x000002d4: e0051321 !... AND r1,r5,r1,LSR #6
0x000002d8: e1821001 .... ORR r1,r2,r1
0x000002dc: e5c61007 .... STRB r1,[r6,#7]
0x000002e0: e2877001 .p.. ADD r7,r7,#1
0x000002e4: e3570010 ..W. CMP r7,#0x10
0x000002e8: e2833004 .0.. ADD r3,r3,#4
0x000002ec: 3affff4b K..: BCC {pc} - 0x2cc ; 0x20
0x000002f0: e28aa001 .... ADD r10,r10,#1
0x000002f4: e35a0078 x.Z. CMP r10,#0x78
0x000002f8: e2833c01 .<.. ADD r3,r3,#0x100
0x000002fc: 3affff46 F..: BCC {pc} - 0x2e0 ; 0x1c
0x00000300: e8bd07f0 .... POP {r4-r10}
0x00000304: e12fff1e ../. BX r14

замерял производительность с двумя вариантами стеков: во внутренней срам и во внешней - тоже самое все.
пробовал PALETTE[] расположить во внутренней срам- тоже ничего не поменялось.

Стек не используется, а PALETTE полностью ложится в кэш, так что разницы и не должно быть.

[axa09]

тоесть в моём случае уже ничего не придумать?

[aaarrr]

Ну, можно Write Buffer включить - сразу прибавится производительности.

[axa09]

Он включен(бит buferable-1)
или в другом месте еще надо?

[aaarrr]

Вы же писали:

0x00200С00 - периферия(дисплей) не кешируется и не буферизуется

[axa09]

А разве можно буферизовать дисплей(его регистры)?
ведь кадр искривится и будет мусор!
или я чего-то ещё не сделал?

[aaarrr]

ведь кадр искривится и будет мусор!

Почему искривится и откуда возьмется мусор?

[axa09]

Разобрался!
Мусор возникал из-за неверной времянки дисплея-пришлось подправить-увеличил RWSETUP=6, раньше было 0.
для дисплея удалось поставить биты buferable и cachable! регистры внутренней периферии(spi, pio) тоже забуферизовал, а вот закешировать не удалось-повисает.
может я сделал что-то лишнее? или вредное?

это подняло производительность всей программы на 11 %

дополнительно разогнал до 206мгц, шина 103,память с nws=0 !!!
гонял час- стабильно!(требуется работа устройства при комнатной температуре )

итого производительность всей программы возросла на 18%

[aaarrr]

для дисплея удалось поставить биты buferable и cachable! регистры внутренней периферии(spi, pio) тоже забуферизовал, а вот закешировать не удалось-повисает.
может я сделал что-то лишнее? или вредное?

Да, пожалуй, Вы немного перестарались. Стоило ограничиться буферизацией записи дисплея (без кэширования, так как толку от него все равно ноль), а вот внутреннюю периферию трогать не нужно.

[axa09]

тоесть оставить только buferable для регистров внешней периферии( на EBI)
и убрать оба (cachable, buferable) у регистров внутреней периферии(spi, pio), так?

кстати,заметил, что один cachable для регистров дисплея тоже ведёт к повышению скорости обмена с индикатором- почему?

[aaarrr]

тоесть оставить только buferable для регистров внешней периферии( на EBI)
и убрать оба (cachable, buferable) у регистров внутреней периферии(spi, pio), так?

Так.

кстати,заметил, что один cachable для регистров дисплея тоже ведёт к повышению скорости обмена с индикатором- почему?

Потому что это режим write-through cache, и буфер записи все равно включен.

[axa09]

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

[aaarrr]

проснулся чисто спортивно-исследовательский интерес- можно ли ещё ускорить процесс фильтра, например написать на ассемблере код фильтра? или лучше, чем сделает Си-компилер,уже не сделать?

Что-то улучшить всегда можно. Но начинать стоит с самого алгоритма, соревноваться с RealView в плане скорости кода довольно трудно.

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

Prefetch для DCache можно сделать, выполнив последовательно чтение с интервалом, кратным размеру строки кэша (8 слов для ARM920T). Для ICache есть специальная инструкция.
Внятную информацию лучше всего брать из Technical Reference Manual (с примерами там только туго).

[Rst7]

проснулся чисто спортивно-исследовательский интерес

Это полезно

А какая у Вас в основном работа идет с пикселями исходного изображения? Имеется в виду - попиксельно или группами (блоками)?

Если попиксельно - рассмотрите вопрос о хранении пикселей исходной картинки, например, в виде 00rrr00ggg00bb00, по 16 бит на пиксель (конечно, буфер экрана будет весить в 2 раза больше). Тогда операцию усреднения можно выполнять сразу над пикселями и обращений к таблице будет намного меньше. Нечто такое:

Код

void foo(volatile unsigned char *dst, unsigned int *src)
{
  unsigned int t;
  //Пиксели по *src хранятся в виде
  //00rrr00ggg00bb00
  t=src[64];
  t+=*src++;
  t+=t<<16;
  //Имеем после сложения четырех пикселей
  //rrrxxgggxxbbxx00----------------
  
  //По таблице конвертируем r- и g-составляющую в rrrggg00, а составляющую b обрабатываем банальным сдвигом
  *dst=pal[t>>24]|((t>>20)&3);
  
  //Повторяем
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
}

В результате, одна итерация выглядит так (после IAR'а)

Код

   \   0000002C   002193E5           LDR      R2,[R3, #+256]
   \   00000030   04C093E4           LDR      R12,[R3], #+4
   \   00000034   02208CE0           ADD      R2,R12,R2
   \   00000038   022882E0           ADD      R2,R2,R2, LSL #+16
   \   0000003C   22CCD1E7           LDRB     R12,[R1, +R2, LSR #+24]
   \   00000040   222AA0E1           LSR      R2,R2,#+20
   \   00000044   032002E2           AND      R2,R2,#0x3
   \   00000048   0C2082E1           ORR      R2,R2,R12
   \   0000004C   0020C0E5           STRB     R2,[R0, #+0]

Вроде ниче не напутал.

[axa09]

если нетрудно,напишите пожалуйста фрагмент кода на Си для работы с префетчем.
я понял это так:
читаем 8 последовательных 32-битных слов, сделав перед этим префетч с начального адреса где лежат слова, я не напутал?

напишите плиз ещё асм-код самого префетча.

на счёт исходных данных- картинка не статичная- она постоянно рендерится програмно-1 элемент байт-индекс в палитре. увеличивать размер индекса и пользовать цвета напрямую нельзя в силу специфики программы(такое требование)

[aaarrr]

читаем 8 последовательных 32-битных слов, сделав перед этим префетч с начального адреса где лежат слова, я не напутал?

Напутали, похоже:
1. Располагаем данные так, чтобы начало было выровнено по границе 8-ми слов.
2. Читаем слово 0, затем слово 8, затем 16 и т.д. На каждом чтении происходит загрузка строки кэша.

напишите плиз ещё асм-код самого префетча.

ICache prefetch:
MCR p15, 0, Rd, c7, c13, 1

А описание можете прочитать в TRM

[axa09]

Спасибо за ответы!

В той же программе оптимизирую другой кусок кода.

Есть функция, которая заполняет буфер 32 байта. Этот буфер требуется переслать по SPI периферийному устройству, которое имеет внутренний аппаратный буфер.
Периферийное устройство шлет внешнее прерывание контроллеру когда нужна порция данных в аппаратный буфер.

Сейчас сделано так:
в обработчике прерывания циклом засылаю в SPI Data register по-очереди все 32 байта. После передачи каждого байта тупо жду. На последнем 31-м шаге цикла перед опросом состояния вызываю функцию постройки нового буфера 32 байт, в надежде потратить время на постройку буфера.

Но к сожалению времени иногда не хватает, а на первых 31 шагах цикла время теряется на тупой опрос состояния занятости SPI.

Ядро 200мгц, SPI клок 8мгц (ограничение периферийного устройства).
Вот я и прикинул : 200/(8/8/32) = 6400 тактов теряем впустую - а ведь можно было это время потратить целиком на построение буфера.

Значит надо использовать DMA.

Псевдокод обработчика прерывания:

__irq void SebdData(void)
{
static u32 i=0;
DMA_Send(Buffer[i],32); //посылаем в DMA первый буфер Buffer[0] - 32 байта
CreatePacket(Buffer[i^1]); //строим второй Buffer[1] - 32 байта
i^=1; //переворачиваем для того чтоб обменять первый и второй буферы местами для следующего раза
AIC_EOI=0; // конец перывания
}

в силу специфики системы использую SPI с указанием NPCS в регистре SPI_TDR (регистр передачи)
тоесть :

SPI_TDR=(номер NPCS<< на сколько-то бит)|Data;

вопрос, как организовать пересылку по DMA?
кеши у меня включены оба.

где-то читал, что с SPI+DMA заморочки по поводу буферов - нужно тратить все 32 бита для того чтоб отправить в SPI.

помогите пожалуйста с DMA в моем случае!

что должно быть в буфере, который должен съесть DMA? (формат). Для моего случая

буфер приёма тоже должен быть? и при DMA-передаче должен быть ещё прием, так?

если можно, то напишите Си-кодом плиз.

Сообщение отредактировал axa09 - Feb 26 2009, 01:36

[axa09]

если текущий режим spi не подходит, можно сменить на fixed mode, получив возможность организовывать 8-битный буфер без лишнего.

для ДМА нужен некешируемый кусок памяти,так?
появилась идея внутреннюю срам закэшировать по адресу 0х00000000-для векторов прерываний и др. нужд.
та же память, но доступная по адресу 0х00200000-не кешировать- для ДМА.

Получится ли так использовать внутренюю срам чтоб кешировалась при обращении к ней по первому адресу и не кешировалось по второму?
если да, то remap- forever

p.s. не хочу заводить ТТВ второго уровня (4кб страницы) или гробить 1мб памяти для каких-то 32 байт для ДМА.
можно кэш данных вкл./выкл., но нежелательно из-за потери производительности функции построения буфера

[aaarrr]

Получится ли так использовать внутренюю срам чтоб кешировалась при обращении к ней по первому адресу и не кешировалось по второму?

Получится. Нужно только не смешивать кэшируемые и некэшируемые области при работе.

[axa09]

удалось запустить ДМА.
Фокус с ремэпом прокатл-к той же памяти можно обращаться как к кешируемой и нет,через разные адреса!

кстати для дма-памяти оставлять buferable?
он не нужен,полезен или вреден?

дма также работает на передачу с памятью которая кэширована, но небуферизована- почему?

меня аж заинтересовало

[aaarrr]

кстати для дма-памяти оставлять buferable?
он не нужен,полезен или вреден?

Он полезен, но использовать с DMA нужно с осторожностью, т.е. своевременно очищать.

дма также работает на передачу с памятью которая кэширована, но небуферизована- почему?

Во-первых, память не бывает кэширована, но при этом не буферизирована. Во-вторых, почему DMA не должен работать (когерентность данных тут другой вопрос)?

[axa09]

как и когда очищать буферизованый буфер для ДМА?

ЗЫ: ДМА дал свои плоды в приросте производительности!
делаю так:
в обработчике прерывания возобновляю указатель и счётчик передачи. затем строю вторую половину буфера(ёмкий процесс!)
жду окончания пересылки ДМА(почти ничего по времени!)
затем свопаю указатели половин буфера.
выхожу из прерывания
и до следующего раза.
играет быстро и без заиканий!

[aaarrr]

как и когда очищать буферизованый буфер для ДМА?

Очевидно, что очищать надо после записи буфера и до старта DMA. Команда сопроцессора есть в мануале.

[axa09]

Не совсем понял.
команду очистки давать до старта дма, когда уже в буфер(массив в программе) записали данные?

а если я пишу в этот массив через другое адресное пространство(ремэп) которое кэшировано+буферизовано?

где и когда следует выполнять префетч для кода?

[aaarrr]

Не совсем понял.
команду очистки давать до старта дма, когда уже в буфер(массив в программе) записали данные?

Да.

а если я пишу в этот массив через другое адресное пространство(ремэп) которое кэшировано+буферизовано?

Тогда нужно еще и сбросить кэш, если он write-back.

где и когда следует выполнять префетч для кода?

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

[axa09]

Подскажите пожалуйста где здесь функция очистки буфера и сброса кэша которые необходимы в моем случае:

Function/operation Data format Instruction
Invalidate ICache and DCache SBZ MCR p15, 0, <Rd>, c7, c7, 0
Invalidate ICache SBZ MCR p15, 0, <Rd>, c7, c5, 0
Invalidate ICache single entry (MVA) MVA MCR p15, 0, <Rd>, c7, c5, 1
Invalidate ICache single entry (Set/Way) Set/Way MCR p15, 0, <Rd>, c7, c5, 2
Prefetch ICache line (MVA) MVA MCR p15, 0, <Rd>, c7, c13, 1
Invalidate DCache SBZ MCR p15, 0, <Rd>, c7, c6, 0
Invalidate DCache single entry (MVA) MVA MCR p15, 0, <Rd>, c7, c6, 1
Invalidate DCache single entry (Set/Way) Set/Way MCR p15, 0, <Rd>, c7, c6, 2
Clean DCache single entry (MVA) MVA MCR p15, 0, <Rd>, c7, c10, 1
Clean DCache single entry (Set/Way) Set/Way MCR p15, 0, <Rd>, c7, c10, 2
Test and clean DCache - MRC p15, 0, <Rd>, c7, c10, 3
Clean and invalidate DCache entry (MVA) MVA MCR p15, 0, <Rd>, c7, c14, 1
Clean and invalidate DCache entry (Set/Way) Set/Way MCR p15, 0, <Rd>, c7, c14, 2
Test, clean, and invalidate DCache - MRC p15, 0, <Rd>, c7, c14, 3
Drain write buffer SBZ MCR p15, 0, <Rd>, c7, c10, 4
Wait for interrupt SBZ MCR p15, 0, <Rd>, c7, c0, 4
Invalidate TLB Invalidate set-associative TLB SBZ MCR p15, 0, <Rd>, c8, c7, 0
Invalidate TLB single entry (MVA) Invalidate single entry MVA MCR p15, 0, <Rd>, c8, c7, 1
Invalidate instruction TLB Invalidate set-associative TLB SBZ MCR p15, 0, <Rd>, c8, c5, 0
Invalidate instruction TLB single entry (MVA) Invalidate single entry MVA MCR p15, 0, <Rd>, c8, c5, 1
Invalidate data TLB Invalidate set-associative TLB SBZ MCR p15, 0, <Rd>, c8, c6, 0
Invalidate data TLB single entry (MVA) Invalidate single entry MVA MCR p15, 0, <Rd>, c8, c6, 1

Там ещё есть какие-то примерчики, только из описания ничего непонятно что делают и для чего надо:

tc_loop: MRC p15, 0, r15, c7, c10, 3 ; test and clean
BNE tc_loop

tci_loop: MRC p15, 0, r15, c7, c14, 3 ; test clean and invalidate
BNE tci_loop

Помогите плиз!

[aaarrr]

Подскажите пожалуйста где здесь функция очистки буфера и сброса кэша которые необходимы в моем случае:

В Вашем случае сначала нужно разобраться с работой кэша и составить четкое представление, когда он нужен/полезен, а когда наоборот.
Для буфера, который будет только отправлен наружу через DMA, он однозначно вреден.

Очистка буфера записи:

Код

Drain write buffer SBZ MCR p15, 0, <Rd>, c7, c10, 4

[axa09]

тоесть Rd должен быть равен нулю:

mov r0, 0
mcr p15, 0, r0, c7, c10, 4

так?

какую бы вы литературу посоветуете по кэшам?

[axa09]

в чём хорош режим сквозной записи кэша по сравнению с обратной записью?
ведь каждый раз пишем во внешнюю память вместе с кэшем.

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

паралельно нашёл про software dma- команды
ldmia
stmia
за один присест сразу 8 слов копирует!
есть ли смысл применить их в функции отрисовки, чтоб быстрее было?

хочу с АРма9 выжать всё