AVR GCC&IAR

IU> Вpядли это pелигия:) И споp в целом ведется с твоим не совсем веpным

MP> Я вижу, что результирующий код неэфективен. Я могу написать короче, лучше, MP> понятнее, красивее. Какое я должен составить представление?

Короче и лучше может быть и не нужно. Релтайм он или соблюдается или нет. В релтайме нет требования чем быстрее, тем лучше. Или успеваешь - или нет. Если ты на ассемблере успеваешь за 20 мкс, а я на Си - за 35, но нужно успевать за 100 мкс, то мы оба успеваем и вся твоя экономия идет лесом. Чаще так и бывает. "Понятнее и красивее" понятия вообще субъективные и в конечном изделии они не фигурируют, на удешевлении не сказываются.

IU> Безyсловно. Я конечно имею ввидy пpимеpно одинаковое знание и того и IU> дpyгого языка. У меня довольно пpиличный опыт ассемблеpщика, и очень IU> скpомный опыт сишника, но даже пpи таком pаскладе Си мне легче читать.

MP> Да мне тоже легко читать си. Hо вот писать на нем куда сложнее.

Твоя ошибка в утверждении: "Си плох, потому что я не могу на нем писать" "В Си большой оверхед, потому что я не могу на нем писать и следовательно реально проверить - но оверхед большООООй""

MP> И главное - мне не понравится то, что я напишу!

Откуда уверенность, если ты даже не пробовал?

MP> Простой пример. Если ты знаешь синтаксис скажем немецкого языка (как самого MP> простого) то для чтения тебе достаточно знать фонетику букв и знаков. Hадеюсь MP> ты понимаешь, что между чтением немецкого текста и пониманием, что собственно MP> там написано - пропасть? Точно такая же пропасть между пониманием текста и MP> возможностью свободно общатся на этом языке (чтоб другие люди понимали). Hо MP> самое хреновое, если при всем при этом ты в совершенстве владеешь английским! MP> Тогда простые фразы ставят тебя в тупик и ты пытаешься интерпретировать MP> сказанное не на том языке и даже хуже - вставлять в немецкую речь английские MP> слова. Я наступил на эти грабли с несколькими асм-ам и постоянно ловлю себя на MP> попытках вставить команды одного CPU в другой. С тех пор я пытаюсь любыми MP> удобными путями избавится от знания языков программирования которые не помогают MP> мне в работе а так-же от изучения каких-либо новых.

Пример интересный - а выводы неверные. Почему ты тогда предпочитаешь значть 10 ассемблеров вместо одного Си?

MP> Кто-нибудь считает, что он смог бы такое написать? ;)

кто он?

MP> Как на счет поменять битики (ножки портов) ? ;)

#define P10 0x90 #define P11 0x91 #define P12 0x92 #define P13 0x93

#define BUTTON_PORT P10 #define LED_PORT P11

sbit BUTTON = BUTTON_PORT; sbit LED = LED_PORT;

MP> Кто-нибудь понял бы это, если бы там небыло коментариев?

где ты видишь комментарии?

for (;;) { LED = BUTTON; }

???

MP> Как это можно перенести на проц без битовых операций?

Переписыванием кода под тот, что приводил VV. Как тебе уже говорили и приводили примеры, многие компиляторы заменяют манипуляцию одним битом на битовую операцию. Оверхед такой конструкции будет небольшой. Кроме того, копирование одного бита порта в другой - настолько частая ситуация в реальных проектах, что ну житья от этого оверхеда нету :)

MP> Ведь это написано на самом понятном языке в мире!

Понятным, для тех кто удосужился его изучить.

И намного более понятным, чем:

main: btfsc BUTTON bsf LED btfss BUTTON bcf LED goto main

если не знать ни ассемблера PIC и ни Си совсем.

MP> Да - я получил доказательство того, что на си это можно написать MP> как на асме.

Ты разве просил что-то еще? Думаю для высосанного из пальца фрагмента, занимающего 0.05% кода какого-то фантомного проекта, вполне достаточно.

MP> Только вот при этом куда-то подевалось понимание...

Куда могло подеваться понимание, если его у тебя и не было?

LB> А как ты в этих макросах проверяшь/устанавливаешь текущий банк LB> памяти?

MP> А вот это уже стиль. Hикак - ибо все одиночные переменные находятся в 0 банке а MP> все массивы находятся в остальных и адресуются четко структурированными кусками MP> через FSR. Если так не получается - контроллер не соответствует задаче!

А в Си на это можно было бы, мягко говоря, положить.