Costic (02.05.2022 16:54, просмотров: 144) ответил VladislavS. на Для полноты картины посмотрим листинг и этого варианта. За сдвиг
записи полезных данных на одну команду к началу прерывания платим
дополнительной переменной в SRAM и более длинным прерыванием:-
- Во-первых, даже для чтения переменной из RAM надо сначала загрузить
её адрес из флэшь. Во-вторых, РОН экономить смысла нет, они при
входе в прерывание сохраняются в достаточгом количестве. В-третьих,
чтение 8/16/32 бит из флэшь занимает одинаково времени, ничего тут
не сэкономишь. Ну и самое главное, зачем в рантайме вычислять из
индекса адрес элемента массива, если его можно вычислить на этапе
компиляции? Так что, приводите листинг вашего варианта - будем
посмотреть. - VladislavS.(02.05.2022 17:31)
- По-вашему, наверное как-то так: Costic(209 знак., 02.05.2022 20:59, ссылка)
- Даже проверять не буду. Кода будет стопудово больше. Надо загрузить
адрес начала массива, загрузить адрес текущего индекса, загрузить
сам индекс и сложить их. Вместо того чтобы загрузить сразу
указатель. Желание на 32-битной системе сэкономить на разрядности
переменной улыбает - обычно эффект обратный получается. Кстати,
Cortex-M0 не умеет невыровненный доступ к памяти. Если вы сделаете
упакованную структуру с малоразрядным индексом, то получите вместо
экономии VladislavS.(146 знак., 02.05.2022 21:56)
- Чушь. Вы грузите свой 32-битный указатель, у которого старшие 16+
битов всегда одни и те же. Т.е. впустую гоняете данные из медленной
флеш. В моем варианте загружается только смещение (младшие 16 бит).
О выравнивании структуры пусть компилятор заботится. короче,
демагогия. - Costic(02.05.2022 23:18)
- Компилятор как раз таки позаботится о выравнивании и будет ваши 16 бит гонять в 32-битных словах. А если вы ему выкрутите руки и упакуете структуры, то будет побайтово их читать, ибо не умеет контроллер невыровненный доступ. Збсь такая "экономия". Адресация 32-битная, а значит к вашим 16 младшим битам нужно подгрузить и прибавить старшие вместо того чтобы одним чтением загрузить сразу указатель. И нет никакой проблемы с пропускной способностью флэша в современных VladislavS.(187 знак., 02.05.2022 23:57)
- Чушь. Вы грузите свой 32-битный указатель, у которого старшие 16+
битов всегда одни и те же. Т.е. впустую гоняете данные из медленной
флеш. В моем варианте загружается только смещение (младшие 16 бит).
О выравнивании структуры пусть компилятор заботится. короче,
демагогия. - Costic(02.05.2022 23:18)
- Даже проверять не буду. Кода будет стопудово больше. Надо загрузить
адрес начала массива, загрузить адрес текущего индекса, загрузить
сам индекс и сложить их. Вместо того чтобы загрузить сразу
указатель. Желание на 32-битной системе сэкономить на разрядности
переменной улыбает - обычно эффект обратный получается. Кстати,
Cortex-M0 не умеет невыровненный доступ к памяти. Если вы сделаете
упакованную структуру с малоразрядным индексом, то получите вместо
экономии VladislavS.(146 знак., 02.05.2022 21:56)
- По-вашему, наверное как-то так: Costic(209 знак., 02.05.2022 20:59, ссылка)
- Во-первых, даже для чтения переменной из RAM надо сначала загрузить
её адрес из флэшь. Во-вторых, РОН экономить смысла нет, они при
входе в прерывание сохраняются в достаточгом количестве. В-третьих,
чтение 8/16/32 бит из флэшь занимает одинаково времени, ничего тут
не сэкономишь. Ну и самое главное, зачем в рантайме вычислять из
индекса адрес элемента массива, если его можно вычислить на этапе
компиляции? Так что, приводите листинг вашего варианта - будем
посмотреть. - VladislavS.(02.05.2022 17:31)