MP>> Этот религиозный спор бессмысленен. Понимание автоматически лучше MP>> на том языке который лучше знаешь, не может быть никакой легкости MP>> понимания си если лучше знаешь асм. Это же банально. AM> Только Си он один с его спецификацией.
GS> А спецификации его пестрят словами "определяется реализацией". GS> Поэтому в реальности он совсем не "один"...
Не применяй такие конструкции, которые вызывают неопределенное поведение. Все решается стилем программирования.
AM> Ассемблер же для каждого семейства свой и для понимая нужно знать все AM> ассемблеры, а также еще и многие тонкости конкретного ядра, явно не AM> отражаемые в мнемониках ассемблера (типа влияния операций на установку AM> флагов и т.п.) Оно конечно, когда постоянно пишешь на конкретном AM> ассемблере - помнишь это. Hо если выбадет случай сопровождения этого AM> кода через 2-3 года, то я либо тебе не завидую либо завидую твоей AM> памяти...
GS> Мне приходилось и через 4 года вносить изменения в достаточно GS> сложный ассемблерный код. О котором уже и забыл, что он был GS> написан ;) Очень быстро сделал, благо давно перешёл на GS> "хороший" стиль программирования, экономя не на нажатиях GS> клавиш, а на усилиях того, кто будет разбираться в исходнике.
Я бы хотел посмотреть на результат, если бы сопровождать код пришлось другому программисту, не знакомому с твоим стилем.
AM> В Си для х51 для использования битовых операций переменная объявляется AM> типа bit - это расширение языка.
GS> А на 51-х свет клином сошёлся? К тому же эта "область битовых GS> операций" ну никак не может охватить _все_ регистры и порты, GS> что без знания "тонкостей конкретного ядра" приведёт к куче проблем GS> у незадачливого любителя "переносимого ЯВУ" ;) GS> Вот и получается, что "си" в таком применении не столь уж GS> и "высокоуровневый" и "переносимый"...
VV приводил полностью переносимый код, независимый от наличия битовых операций в конкретном ядре. Чем он не устраивает? И что, на переносимости свет клином сошелся, что-ли? Она вообще не играет роли и не нужна при написании HAL, поскольку обычно там работа происходит с SFR корнкретного процессора, что не поддается переносу по определению. А выше HAL код делается переносимым без особых проблем. Основная проблема - это big/little endian, и то только при разборе буфера по полям, а это нужно только при написании связевых протоколов.
MP>> Да нет никакой легкости понимания - это очевидно. AM> Очевидно, что для понимания Си нужно знать только Си, для понимания AM> алгоритма на ассемблере знать N ассемблеров. Вообще никогда не видел, AM> чтобы в книгах алгоритмы писали на каком-то ассемблере, поскольку AM> якобы это проще для понимания :)
GS> Мало ты книг читал. Ассемблер ничуть не хуже для описания GS> многих алгоритмов. Если при его разработке головой подумать GS> (как это сделал, к примеру, Кнут, в своём "учебном ассемблере"), GS> а не громоздить хаос по примеру "специалистов" от Microchip'а.
Ну Кнут, конечно классика, но я попросту думаю, что если бы первое издание вышло в наше время, то для иллюстрации алгоритмов был бы выбран какой-либо ЯВУ.
GS> Другое дело, избавиться в ассемблере от аппаратных особенностей GS> конкретного процессора (вроде функционирования флажков состояний) GS> невозможно, поэтому приходится принимать какие-то условные GS> соглашения и по возможности избегать "трюков".
То есть болеть головой о том, о чем можно не болеть на ЯВУ.
MP>> Hесостоятельность оверхеда MP>> 15% я уже многократно доказывал. Как на собственном примере так и MP>> на чужих.
AM> Вообще - не помню, чтобы ты доказывал. Последнее доказательство ты AM> приводил для PC - оно не катит. Кроме того бессмысленно доказывать AM> большой оверхед одного маленького кусочка. Всегда можно найти пример, AM> где Си проиграет ассемблеру и в 5 раз. Hо в пределах проекта это AM> нивелируется и оверхед составит 15-30%, не более.
GS> Практика свидетельствует об обратном. Если брать равную квалификацию GS> программистов.
Чья практика? Моя свидетельствует о 15-30%, причем я пишу и на асм, и на Си, то есть имею равную кваливикацию. Сначала писал полностью на асм. При переходе на Си получил
15-30% оверхеда по объему кода. По RAM на Си иногда можно получить выигрыш на "не стековх архитектурах", из-за трудности вручную на ассемблере сделать компилированный стек. Про 16-битные и выше uC я вообще не говорю. На асм там писать смысла вообще нет.