AM> Hе применяй такие конструкции, которые вызывают неопределенное AM> поведение. Все решается стилем программирования.
GS> При чём тут стиль? Hачиная с размера "байта" и "инта" - сплошные GS> "определяется реализацией". Какой при этом может быть стиль? :-/
Определяется, но оно известо для данной коткретной платформы.
GS>> Мне приходилось и через 4 года вносить изменения в достаточно GS>> сложный ассемблерный код. О котором уже и забыл, что он был GS>> написан ;) Очень быстро сделал, благо давно перешёл на GS>> "хороший" стиль программирования, экономя не на нажатиях GS>> клавиш, а на усилиях того, кто будет разбираться в исходнике.
AM> Я бы хотел посмотреть на результат, если бы сопровождать код пришлось AM> другому программисту, не знакомому с твоим стилем.
GS> _Так_ задача не ставилась. Кстати, разбираться пришлось бы GS> меньше,
Не уверен
GS> чем в аналогичной по сложности сишной программе в GS> типичном для сишников "минималистском" духе ;)
Что значит типичный для сишников? Почему все, кто не пишет на Си, считает, что программа на си это нечно в виде:
#include <stdio.h>
#include <stdlib.h>
#define P printf #define I atoi int main(int a,char*v []){int r=7, i;if(a>1 ) r=I(v[1]); if(r<=0) r=5;if(r%2==0)++r;for (i=0; i<r*r; P(i/r==(
3*r)/2-(i%r+1)||i/r== r/2 - i%r||i/r==r/2+i %r||i/r==i%r-r/2?"*": " "),i++, i % r==0?P( "\n") : 0);return 0;}
GS> У меня комментария в несколько раз больше, чем кода...
На Си запрещены комментарии? Почему ты считаешь, что , к примеру у меня на Си нет комментариев. Иногда на пару строк пишу 30-50 строк комментариев с временными диаграмами, потому что бывает не очевидно, что здесь делается. И не очевидно не с точки зрения арифметико-логических операций, а с точки зрения алгоритма работы.
AM> Hу Кнут, конечно классика, но я попросту думаю, что если бы первое AM> издание вышло в наше время, то для иллюстрации алгоритмов был бы AM> выбран какой-либо ЯВУ.
GS> Можно, конечно программировать сразу на "высокоуровневом" языке. GS> И учат сейчас преимущественно на Паскеле. Hо знание "нижнего уровня" GS> всё-таки даёт очень много преимуществ. Особенно в эхотаге...
Никто не отменяет ассемблер, тебе уже сто раз говорили, что не надо крайностей. Но большинство проектов решаются либо вообще без асма, либо со вставками в критических по скорости или объему кода местах. Общее количество асма обычно не превышает 3-5% объема кода.
GS>> Другое дело, избавиться в ассемблере от аппаратных особенностей GS>> конкретного процессора (вроде функционирования флажков состояний) GS>> невозможно, поэтому приходится принимать какие-то условные GS>> соглашения и по возможности избегать "трюков". AM> То есть болеть головой о том, о чем можно не болеть на ЯВУ.
GS> Для того ЯВУ и придумывали, чтобы об этом голова не болела ;)
Да
GS>> Практика свидетельствует об обратном. Если брать равную GS>> квалификацию программистов. AM> Чья практика? Моя свидетельствует о 15-30%, причем я пишу и на асм, и AM> на Си, то есть имею равную кваливикацию.
GS> А с чего ты взял, что ты имеешь равную квалификацию на сях и асме?
Тем, что разглядывая код после Си я видел примерно то-же, что я бы написал на асме, на асме возможно чуть более оптимально, но и то не везде.
GS> Это ещё доказать нужно!
Я никому ничего не должен доказывать. Придется поверит на слово.
GS> AM> Сначала писал полностью на асм. При переходе на Си получил GS> AM> 15-30% оверхеда по объему кода.
GS> У меня поначалу тоже кошмарные программы получались. Hо через GS> несколько лет пришло понимание, как на уровне "низкоуровневых GS> трюков", так и на "высоком" уровне - организации структур и GS> процессов в системе. И теперь мои программы имеют размер в разы GS> меньше, чем аналоги на сях от опытных программистов.
Для определенных действий всегда существует минимально-возможный объем операций (команд процессора). Большинство компиляторов на Си приближаются к нему достаточно сильно, допуская небольшой оверхед. Уменьшить его в несколько раз физически не возможно. Впрочем, для Фомы неверующего предлагаю дать сюда простой алгоритм чего либо. Я скомпилирую его на Кейл х51 и дам листинг, попробуй ужать его хотя бы в 2 раза. Скомпилировал бы на PIC,но увы не использую. Впрочем, может будет у кого желание.
AM> По RAM на Си иногда можно получить выигрыш на "не стековх AM> архитектурах", из-за трудности вручную на ассемблере сделать AM> компилированный стек.
GS> Hа PIC стека, считай, вообще нету.
Куда же локальные переменные кладутся? Правильно - распределяются по RAM, то есть получается не в чистом виде стек, а компилированный стек.
AM> Про 16-битные и выше uC я вообще не говорю. Hа асм там писать смысла AM> вообще нет.
GS> Это не бесспорное утверждение. Есть люди, которые этим вполне GS> успешно занимаются. Опять же, для эхотажных применений такой GS> подход более осмыслен, хотя бы из-за ограниченности ресурсов GS> встраиваемой системы. GS> Как минимум приходится делать ассемблерные вставки в "высокоуровневый GS> код".
Приходится, но и то не всегда. Во всяком случае я сейчас преимущественно пишу для платформы MB90, ассемблерная вставка мне понадобиласть для портации uCOS-II (без этого никак, потому что нужно стек корректировать), и когда я прописывал полуаппаратно-программный UART на таймере, мне показалось, что нужно его сделать на асм, чтобы оптимизировать по скорости обработку прерываний. Впрочем, вряд ли я достиг даже 50% выигрыша по скорости.