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

c этого момента пожалуйста поподробнее...

но у меня ошибка была на этапе компиляции самой функции, а не в точке её вызова. Или это как-то взаимосвязвно ?

хотел применить 2-е но в результате остановился на 1-м.

??? Вообще-то Вы сами это либо задаёте либо нет в настройках проекта.

Ошибка у Вас стилистическая. А то, о чем сообщает компилятор, об этом Вам уже говорили. Повторюсь.
Вы писали Это означает, что pStr постоянно хранится в памяти или в регистрах в изначальном виде (типе). Временно приводится к типу char*, изымается по нему значение, он инкрементируется (если ещё инкрементируется), а в каком виде его теперь хранить (какого он типа?)?
В таком случае и нужен промежуточный указатель (не факт, что в результате он будет не тем же самым), который инициализируется единождыи в дальнейшем только он и используется.

Насколько я помню тип __generic подразумевает также возможность указывания на __eeprom. Но даже и без этого Ваш код будет неприятно больше и работать будет заметно медленнее.

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

да это я уже понял.

ясно, это тоже проверю.

Привожу данные после исследования скорости выполнения и размера *.bin файла (всего проекта) для 4 MHz m128.
сравнил вывод числа 65535 в массив при помощи sprintf(LCD,"%hu", 0xffff); (Normal DLIB)
и при помощи FloatToLCD(0,0,65535.0,0,1);
sprintf
без опт. разм. 6442 байт и 62008.5us с макс опт. разм. 6436 байт и 62008.25us
без опт. скор. 6442 байт и 62008.5us с макс опт. скор. 6436 байт и 62008.25us
FloatToLCD
без опт. разм. 2220 байт и 2315us с макс опт. разм. 2072 байт и 2287.75us
без опт. скор. 2252 байт и 2303us с макс опт. скор. 2116 байт и 2262.75us

Вариант с одним указателем типа __generic для вычитки из SRAM
без опт. разм. 2345 байт и 117.75us с макс опт. разм. 2073 байт и 92us
без опт. скорости 2351 байт и 96.5us с макс опт. скор. 2059 байт и 71.5us

Вариант с одним указателем типа __generic для вычитки из FLASH
без опт. разм. 2348 байт и 120.75us с макс опт. разм. 2080 байт и 94.75us
без опт. скор. 2354 байт и 99.5us с макс опт. скор. 2060 байт и 74.25us

Вариант с двумя указателями для SRAM и FLASH и равенстве нулю FLASH.
без опт. разм. 2353 байт и 115us с макс опт. разм. 2067 байт и 115.75us
без опт. скор. 2373 байт и 92us с макс опт. скор. 2073 байт и 74.25us

Вариант с двумя указателями для SRAM и FLASH и равенстве нулю SRAM.
без опт. разм. 2354 байт и 125.5us с макс опт. разм. 2068 байт и 118.5us
без опт. скор. 2374 байт и 102.5us с макс опт. скор. 2074 байт и 82.5us

Комментировать не буду, дабы не быть уличенным в пропаганде

Вот это хит! ;>

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

To &-rey.
Я тут для себя тоже провел кое-какие эксперименты по созданию универсальной функции чтения строк. В соответствии с предложенными выше IgorKossak вариантами решения написал три функции, каждая из которых читает сроку из SRAM/FLASH/EEPROM и записывает ее в SRAM (если интересно файлы проекта прилагаются). И для себя сделал вывод, что более подходящий второй вариант (информация о типе указателя как аргумент в функции) (в моем случае Funk1(…)). Во-первых, в моем случае он работает быстрее чем остальные варианты (за исключением чтения из флэш, тут немного быстрее функция с __generic). Во-вторых, этот вариант более универсальный в плане переносимости на другой компилятор (ИМХО квалификатор __generic поддерживается только ИАР-ом), и в плане доступа к различным типам памяти: как я понял __generic не работает с ЕЕПРОМ. Есть конечно и недостатки: второй вариант решения занимает несколько больше места в памяти программ (по сравнению с __generic) но с этим ИМХО можно мириться. Конечно результаты достаточно относительны и зависят от реализации. На всякий случай привожу результаты тестирования .
Информация о типе указателя как аргумент в функции ( функция Funk1):
чтение из SRAM – (макс. оптимиз. по р-ру) 345 цикл., (макс. оптимиз. по скорости)340цикл.
чтение из FLASH – (макс. оптимиз. по р-ру) 428 цикл., (макс. оптимиз. по скорости)426цикл.
чтение из EEPROM – (макс. оптимиз. по р-ру) 937 цикл., (макс. оптимиз. по скорости)938цикл.
Объем кода, макс. опт.по разм./ макс. опт. по скор. – 70/70

Использование квалификатора __generic (функцияFunk2):
чтение из SRAM – (макс. оптимиз. по р-ру) 387 цикл., (макс. оптимиз. по скорости)387цикл.
чтение из FLASH – (макс. оптимиз. по р-ру) 417 цикл., (макс. оптимиз. по скорости)417цикл.
чтение из EEPROM –не работает.
Объем кода, макс. опт.по разм./ макс. опт. по скор. – 44/44

Три указателя (функция Funk3):
чтение из SRAM – (макс. оптимиз. по р-ру) 389 цикл., (макс. оптимиз. по скорости)363цикл.
чтение из FLASH – (макс. оптимиз. по р-ру) 509 цикл., (макс. оптимиз. по скорости)481цикл.
чтение из EEPROM – (макс. оптимиз. по р-ру) 1085 цикл., (макс. оптимиз. по скорости)1057цикл.
Объем кода, макс. опт.по разм./ макс. опт. по скор. – 86/94

Хит это или нет, но я и имел ввиду, что компилятор не знает, сдвигать указатель на бит или нет. Читайте внимательнее топики (или купите монитор многодюймовый)

"Не говорите мне что делать, и я не скажу Вам куда идти" © begin...end.

В Вашей цитате не было написано того, о чем Вы сейчас говорите. Чтобы сказанное Вами было понятно не только Вам, а всем, я бы добавил, что указатели на Flash могут быть двух типов:
1. указатель на функцию - тогда флеш указатель указывает на СЛОВО (сдвинут на 1 вправо);
2. указатель на данные - тогда флеш указатель указывает на БАЙТ (линейный указатель как и при адресации SRAM).

Согласитесь, что "указатель содержит адрес не байта, как в SRAM мо, а слова, где младший бит адреса указывает на тип байта в слове (старший или младший)" - фраза не совсем понятная и не раскрывает сути вопроса.

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

Сообщение отредактировал prottoss - Jan 9 2006, 19:56

Извините, в этом я был действительно неправ.

Я думаю неправильно говорить компилятор незнает или неумеет. По стандарту "C" обязан делать инкремент УКАЗАТЕЛЮ типа void и при этом безразлично как в конечном итоге интерпретируется адрес. Дело в том что архитектура AVR непозволяет этого сделать. Доступ, насколько я помню, к FLASH области и SRAM области совсем разные...

А мне как раз кажется наоборот. И что серьезно "...По стандарту "C" обязан делать инкремент УКАЗАТЕЛЮ типа void и при этом безразлично как в конечном итоге интерпретируется адрес...". А как тогда, к примеру, Вы прокомментируете вот такой код:



Интересно, как MySuperFunc узнает, с каким типом данных ей работать? Размер одного типа данных отличается от другого в два раза. Прочитает исходник? Ей же кроме адреса массива ничего больше не передается! Вот если бы мы кроме указателя передавали еще одним параметром в функцию ее тип, то функция могла бы определить , с чем ей работать. Допустим примерно так:

указатель void, ИМХО, действительно не может знать величину приращения при любыхарифметических действиях с ним.
void MySuperFunc(void* ptr, char type){
Struct1* ptr1 = ptr;
Struct2* ptr2 = ptr;
if(type == TYPE_STRUCT1) ptr1++;
if(type == TYPE_STRUCT2) ptr2++;
}

1. Если что-то кажется, я конечно извеняюсь, есть единственный выход - берем стандарт к примеру 99й и смотрим.
2. Можно приводить примеры работы со структурами, пайпами и.т.д, но ни я никто другой ничего об этом не говорил, а говорили об адресации.
3. Также, я не говорил что через указатель на void можно перескакивать через несколько байт, слов или элементов структур (применительно к их расположению в памяти) (хотя по стандарту для некоторых архитектур возможно), а адресация к ячейкам памяти - пожайлуста.
4. В этом топике обсуждались функции вывода СТРОК только из двух источников, а не чего-либо из структур (можно и строку расположить по три символа в разных частях SRAM - тогда все приведенные функции будут неверны).
5. К 1 вдогонку - попробуйте на любых других архитектурах (x86, PowerPC тотже ARM) сделать инкремент УКАЗАТЕЛЯ на void - и все ОК, для 86й на куче компиляторов, на PPC и ARM тоже все нормально (правда только под gcc пробовал).

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

То что я говорил, не меняет того факта, что сделать нормальную универсальную функцию нельзя, но всетаки... смысл то имеет разобраться в стандартах и как в таких случаях поступает компилятор...

Что-то все равно не понятно. Отсылания к Стандартам, к сожалению, не проясняют ситуацию. Если уж ссылаетесь на Стандарт, то указывайте конкретный номер параграфа и пункта. А еще лучше прямо цитату сюда.

Я проще спрошу, хотя и тоже на примере (чтобы понятнее было). Вот имеем функцию:


Условия следующие: пусть аппаратная платформа AVR программная EWAVR - все это означает, что

sizeof(char) == 1
sizeof(int) == 2
sizeof(long) == 4
sizeof(float) == 4
sizeof(void*) == 2
и т.д.

Теперь пусть имеем, скажем, массив

char A[64];

расположенный по адресу 0x100, и передаем его адрес в функцию:
...
f((void*)A);
...

Вопрос: по какому адресу запишется число 20 (если этот код вообще скомпилируется, в чем есть большие сомнения )? И как эту ситуацию описывает Стандарт - с ссылкой на конкретный пункт, пожалуйста.