добре, тука вече съм много съгласен, но не се сетих как да укажа размер на масив с 256 елемента в един байт.... може би 0 трябваше да е 256 елемента, така или иначе няма масиви с 0 елемента........ аз затова и пуснах задачата тук, исках да видя решението на това, не как се местят елементи или се търси минимум и максимум, това е ясно че всеки го може, аз лично изходих от това да напиша програма която използва колкото може по малко на брой и по размер променливи, сметнах че това се търси в условието, като получа отговора ще ви го кажа...

относно С-то, за сега не мисля да минавам на него, но няма да се връщам и към basic , лично мое мнение е че специално за PIC няма значение на какъв език пишеш, никой не ти дава предимство пред другия, те ги направиха и трите еднакви само дето синтаксиса е различен, та нека всеки си пише на квото му допада, програмиста или е програмист и може да свърши работата или не.......


Да публикувам ли и втората задача?

Някак си много е мило да правиш такива умозаключения .
Иначе масив с 256 елемента е масив с индекс от 0 до 255, т.е. както и другите ти казаха побира се индекса в един байт и аз поне още не мога да зацепя защо ти трябва числото 256, което вече е два байта ?

И аз не разбирам какьв е проблемьт. Така формулирано заданието предполага, че ще работиш с масиви с максимална големина 255 елемента. Това е максималното число, което може да се кодира с един байт.
Но ако толкова дьржиш на масив с 256 елемента просто перефразираш заданието и като параметьр на функцията предаваш не размера на масива, а индекса на последния елемент. Както ти казаха вече масив с 256 елемента вьрви от 0 до 255.
С 1Byte можеш да кодираш 256 адреса.
Hяма проблеми просто тьлкувай заданието по друг начин. Дори функцията не трябва да променяш, ако логиката вьтре е да се работи с размер вместо с индекс на последния елемент, ами увеличи с 1 и си готов. Сега ако искаш да се придьржаш стриктно хем кьм заданието (което си е безсмисленa инициатива), хем да можеш да работиш с 256 елемента, е не може. Но не е и необходимо

ем щото ps66 каза че не трябва да подавам последния индекс на масива както правя, а размера.....
пък иначе мисля че почти всички тук още в 5-6 клас сме знаели колко се побира в един байт.......

Какво значи колко се побира в еидн байт ? 1 байт си е еидн байт, той адресира ни по малко ни повече от 256 клетки памет ако го разглеждаш като адрес, и предава стойности от 0-255 ако говориш за данни.
След като функцията е с дефиниран вход от 1 байт и на главата си да застанеш няма как да предаваш повече от 255 като стойност или 256 адреса. Функцията ти има вход, това е променливата дефинирана като byte, така че да излизаш от презюнкцията че ще и подаваш с едно по малко е много некоректно, ти ще подаваш с едно, някой друг с две и т.н. това е абсолютно неправилно.
При условие че искаш да ползваш всичките 256 елемента от масива изрично трябва да укажеш че функцията работи с индекси, т.е. трябва да го слжиш като коментар. Това е и нормалния начин, в смисъл това е по подразбиране. В С когато се обръщаш към масив, нормлано е да очакваш че подаваш индекса на клетката която те интересува а не нейният номер. Ако работиш с номера, то самата функция би следвало да го намалява с 1 за да получиш днните които ти трябват, което е малко глупаво.

с две думи искате да кажете, че :



е по - правилно решение

Приемайки, че предаваме размера на масива в първата функция бихме могли да спестим променливата i по следния начин:



освен това спестяваме пресмятането на n-1 на всяка итерация на цикъла.

Във втората функция можем да спестим променливата temp и пресмятането на n - i - 1 и на n/2 (което е важно, защото деленето отнема доста цикли на процесора):

@stoianp Що не оставиш оптимизациите на компилатора...
Сорс кода трябва да е разбираем и преносим.
При варианта който предлагаш за втората функция не спестяваш нищо. Деленето на 2 всеки компилатор ще го направи с >>1 което не отнема толкова много цикли. А тези побитови XOR може да изглеждат оригинално, но я си представи че масивът m[] се намира в по-бавна памет ... Променливата temp най-вероятно компилатора ще я разположи в регистър и ще стане по-бързо.

Абе дотолкова доколкото пише за PIC няма проблем с това което прави, а преносимоста е хубаво нещо, обаче при контролерите не е много задължителна, там лично аз предпочитам да оптимизирам кода за съответния процесор.

&ToHu Говорим в конкретния случай за една проста swap функция. Интересно ми е да видя асемблера, който генерира компилатора за PIC, с който работиш за единия и за другия предложен вариант. А аз продължавам да твърдя че сорс кода трябва да е разбираем и преносим пък макар и да пишеш за PIC. Това разбира се не означава че когато пиша на С не се съобразявам с конкретния процесор и не държа сметка за това как ще изглежда компилирания код.
Между впрочем темата не е обвързана с PIC и в случая по-важно е сорса да е разбираем, защото се обсъжда от няколко човека. И все пак ми е интересно да видя резултатите от компилатора за
void invert_array(unsigned char n);
За първата функция ми е ясно че се постига по-оптимизиран код, но за втората нещо не съм убеден.

@Zdrav Напълно съм съгласен с теб, но в задачата не се казва нито какъв е процесора, нито какъв е компилатора - идеята ми беше да спестя променливи.