"Äà áå ÿñíî òè å. Íà ìåí êàòî ñè ïîãëåäíà ñòàðèòå àñì ñîðñîâå, íèùî íå ìè å ÿñíî â ïúðâèÿ åäèí ÷àñ. Õè÷ íå ìå óáåæäàâàé ÷å 10 ñòðàíèöè ñîðñ íà àñåìáëåð ìîæå äà å ïî-ïðåãëåäåí îò 5 ñòðàíèöè Ñ "

Àáå, Öåöêî, àáå ïðèÿòåëþ, àêî íà òåáå íå òè å ÿñíî íåùî, èëè íå ìîæåø äà ïîìíèø êîäîâå íà ASM, ùî ñå ïðà'èø îáîáùåíèÿ è çàáëóæäàâàø êîëåãèòå. Áÿõ ðåøèë äà íå òè îòãîâàðÿì, àìà 'àèäå îò ìåí äà ìèíå.
È òàêà çàùî å íóæåí àñåìáëåðà îñîáåíî ñåãà êîãàòî âñè÷êè ïèøàò íà C, C++, Delphi è äð.? À Öåöêî, çàùî ? Äåéñòâèòåëíî ìíîãî ìîæå äà ñå íàïèøå íà Ñ, íî íå ìîæå äà ñå íàïèøå àáñîëþòíî âñè÷êî. À ñåãà çà îñòàíàëèòå êîëåãè:
1. Íà ASM ñå ïèøå êîãàòî ñå èçêà ìàêñèìàëíà ñêîðîñò íà èçïúëíåíèå íà ïðîãðàìàòà íàïð. âàæíè êëîíîâå îò ïðîãðàìàòà, ÿäðà íà ÎÑ è RTOS èëè ïðîñòî êðèòè÷íè ó÷àñòúöè îò ïðîãðàìàòà.
2.Ïðè ðàáîòà ñ ïîðòîâå è âçàèìîäåéñòâèå ñ âúíøíè óñòðîéñòâà - êàêâî ïî ïðîñòî îò BSF èëè BCF ?
3.Ïðè ìíîãîçàäà÷íà ðàáîòà. Íå òè òðÿáâà SALV-à, íå òè òðÿáâàò ãëóïîñòè, ñàì ñè ãîñïîäàð íà ÂÑÈ×ÊÎ, ñàì ñè îðãàíèçèðàø âñè÷êî, êàêâîòî èçêàø è ìîæåø òîâà ïðàâèø.
4.Ãîëÿìà ÷àñò îò òîâà êîåòî ñå ïèøå íà åçèê îò âèñîêî íèâî, ñå ïèøå è ÏÎ-ÁÚÐÇÎ è ÏÎ-ËÅÑÍÎ è ÏÎ-ÏÐÎÑÒÎ è ÏÎ-ËÎÃÈ×ÍÎ íà ASM.

Àñåìáëåðèòå îòäàâíà íå ñà òîâà êîåòî ñà áèëè ïðåäè âðåìå. Òå âå÷å èìàò ìàêðîñè è ìíîãî ìíîãî äðóãè íåùà, çà äà ìîæå òåçè êîéòî ïèøàò íà òÿõ, äà ïèøàò ìàëêî, äà ïèøàò áúðçî, äà ïèøàò áåç ãðåøêà. Èìà è ìíîãî áèáëèîòåêè è ò.í.ò è ò.í.ò.

Åäèíñòâåíî êîåòî ASM íå ïðàâè âìåñòî òåá, å ÷å íå ñå ãðèæè äà òè ïðåâêëþ÷âà áàíêèòå è ñòðàíèöèòå, íî ïîíå òå ïðåäóïðåæäàâà. Ò. å. ãîñïîäàð íà ïîëîæåíèåòî ñè ñè ïàê òè.

È òàêà Öåöêî, çàïîìíè ÷å âàæíè â ïðîãðàìèðàíåòî ñà àëãîðèòìèòå, äà ïè÷ àëãîðèòìèòå, à íå òîâà äàëè ñà íà Ñ èëè íà Ñ++ èëè íà äðóãî.
Áàñ äúðæà ïè÷, ÷å ïðîãðàìà ïèñàíà íà Ñ, îò òåá, ùå å äâà ïúòè ïî ãîëÿìà îò òàêàâà ïèñàíà îò ìåí íà ASM. È òàêà ïè÷, çàåáè ò'âà íà êàêâî êîäèðàø, ó÷è àëãîðèòìèòå ïè÷, è òîãàâà ùå òè å âñå
åäíî íà êàêâî êîäèðàø.

Ïîçäðàâè è óñïåõè íà âñè÷êî ïðîãðàìèñòè íà C è íà ASM !

Приятелю 3D,
Тексът на песента, която пееш е общо взето точен и верен. Мелодията която си подел - НЕ! Човекът си е казал мнението и за това, което е казал едва ли е най-добре да му се подиграваш. Още повече, че мнението му е съвсем смислено и аргумантирано ( според мен ). Подобен тон като твоя не е показател за професионализъм. Провери си CV-to и виж дали не си пропуснал първите 7 години!

Така е, bateAz е прав, (или седнал но правилно)
ако се почне с подигравките ще се омажат нещата като в другите форуми, ще почне едно изливане на гов.. , и сбогом хубаво форумче!
3D може би ще пожелаеш да се регистрираш, А?Мнението ти, ми допада, но не и тонът ти ... пък к'во ли ти пука ??!!
Реконструкторе, може би е време да поразгледаш статуса за анонимните постове

Асемблера определено си има предимство, но С-то спестява доста работа, последното нещо което писах е около 1000 реда С, компилирано около 7 к, първо ако го бях писал на асм щеше д ами отнеме поне 3 пъти повече време, и второ щеше да е много по нечетливо, дори и с коментари. А това даже нямаше ред асм ... чак се чудя как работи ...., аз обикновенно доста асм ползвам но ... а програмата позлва всики възможни прекъсвания и всички пинове на 877, общо взето максимума от процесора, та повам да мисля че когато свикнеш с един компилтор, много рядко ти се налага да позлваш asm, за прекъсванията да, защото това дето го описах работи със сравнително бавни процеси, а стандартната процедура доста гълта, но в случая не ми е проблем.

Аз далеч не съм защитник на тоя или оня език. Мога обаче да се обзаложа на каса бира, че на С за пик 18 ще напиша каквото искате и след компилация няма да е с повече от 10% по дълго (и то само за някой специфични случаи при прекъсване) и не повече от 5% по бързо на код написан на асемблер от вас. Изключваме математиката (и то само деленето - на С е универсално но бавно) Казвам 18 серия защото този компилатор ми е най-познат. Компилаторите на С за микроконтролери са оптимизирани доста добре. На въпроса за BCF и BSF на С изглеждат така:

INTCONbits.TMR0IE = 1 (или 0). Въпросния ред след компилация съдържа само инструкцията BCF или BSF. Нищо друго. Както и

if(INTCONbits.TMR0IE) се компилира като btfss нищо повече. Само човек който не е работил прилично време на С за микроконтролер (с добър компилатор де), може да се изказва толкова неподготвен. С то се отличава с доста проста структура за разлика от Паскал, Бейсик, С++ , Java и нагоре. Всеки оператор на С е мислен така че да е оптимален след компилация. С то е правено да е ефективно. Поради тази причина в С съществува адресна аритметика, указатели (поинтери) и пр. Разликата между С и макроасемблер, е като между макроасемблер и машинен код.

Не си мисли че съм куц в Асемблера. Преди да почна да използвам С имам поне 5 години пикове на асемблер (нямаше С тогава). Преди това доста асемблер за старите ПЦ-та. И сега пиша на асемблер някой времево критични математики (деленето им куца на компилаторите).

Ама айде де не разбунваме духовете. Кой на квото го кефи на това да пише.

Верно е...Ако искаш да напишеш нещо сериозно, първо почни на ASM, пък както един приятел вика : "Ако те мързи, го напиши на С"...

Писането на асемблер е оправдано само и единствено тогава, когато не ти стигат ресурсите ( памет, време ) да го изпълниш на C. Всъщност има още 2 случая, които го оправдават 1. За обучение 2. За корекции на муто поведение на компилатора ( има го, има гоооо! ) Третият случай е от мазохизъм, но това не е технически, а медицински проблем.
Имам предвид, ако не стигат ресурсите на контролера, не на програмиста. То ако на такъв пишман програмист не му стигат на C, на асемблер по-добре да не се захваща.

Ìîëÿ äà ìå èçâèíèòå çà ôàëøèâîòî ïååíå, íî àêî ïîãëåäíåòå íàêîé îò ïî ãîðíèòå ïîñòèíãè, ñúùî áèõòå âèäåëè ôàëøèâè íîòêè, àìà íèêîé íå ñå âúçìóòè. Ìîëÿ ïðèáåðåòå ìàùàáíèÿò ìåòúð è ìåðåòå åäíàêâî.
Ïîçäðàâè

Значи, извинявам се, че не се появих вчера, ама имаше проблемчета с връзката.
На мнение съм, че наставническият тон и пишкомерството са симптоми на пубертета, за това няма да ги толерирам по ниакъв начин тук. Ако още веднъж се появи подобен постинг (като на 3Д), ще забраня нерегистрирани да пишат.

За хардкорд асемблер-маниаците, ще публикувам малко от свръх-секретния си код. Предствлява, грубо казано, алгоритъм за възстановяване на липсващи данни:



И малко дефиниции:



Това би било невероятна клизма да го напиша на асм. Особено ако трябва да се пише за едни известни процесори на една известна фирма, дето не поддържат аритметични операции с пренос. Ако добавим структуриране на данните и съотве
тната нужда от читава адресна аритметика (отново бих споменал известните чипове, на известната фирма, дето трябва да превключваш банки), ситуацията става наистина плачевна, що се отнася асемблера.
Според мен оптималното съотношение между C и асемблер в един фирмуер е някъде 90% към 10% в полза на Ц-то.

Хммм....??? а на кой ред правиш обръщането към харда ? ... МАЙТАП
Честно да си призная, винаги когато карам пика да си вади елката, ми итръпват зъбите като си помисля че може да съм проспал някой възможен пренос или заем (на асм разбира се), ще вземете да ме навиете да го пробвам пак това Ц бре.

Честно, да си умреш от смях като четеш...
Обаче не сте ли съгласни че за да се пише нещо на Ц за PIC например, ще е доста по-лесно ако сте наясно с асемблер?!

Predator: "Обаче не сте ли съгласни че за да се пише нещо на Ц за PIC например, ще е доста по-лесно ако сте наясно с асемблер?"

Oпределено, да! Още повече, че инцидентно компилаторът "върши глупости". Затова и аз когато пиша на C честичко го проверявам к'ви ги е надробил в асм листа. И това далеч не е само за PIC.
Това може би си е непреодоляна детска болест ( почти всички сме започнали с асемблер ), но не считам, че е грешно.

Ролята на харда в случая изпълнява един 24LC515. Четенето е напълно асинхорнно и въпросният код се намира в един колбак, който се вика, когато четенето приключи (вади пишките! ). Изобщо всички (или около това) операции с периферията (всички устройства различни от ядрото и паметта), са асинхронни и просто не виждам как би могло този фирмуер да се напише на асм, без да се изхабят няколко живота и 2-3 милиона чипа. Ако, обаче, се мине на по-високо от C/C++ ниво, например BASIC (да, има такъв компилатор за AVR) ще има сериозно performance penalty, от което може да последва издуване на мегахерците над максималните, дадени от производителя, нататък нещата са непредвидими.
Така че лично за мен - C/C++ завинаги.

Не милсиш ли, че това което си направил ще стане и с Bascom-AVR?