AVR GCC&IAR

AM> И потом, кто сказал, что все задачи нужно (можно) решать на х86? AM> Требования к системе определяются AM> периферией/быстродействием/энергопотреблением/ценой и это в AM> большинстве случаев будет не х86.

MP> Hу надеюсь ты понимаешь что я на x86 реально не конечно не создаю embeded MP> зверушек?

Зачем тогда приводить в качестве аргумента x86 в конверенции, в назавнии которой явно фигурирует EMBEDDED? Мы ведь по польшей части здесь обсуждаем именно embedded.

MP> Хотя впрочем почему-бы нет, если это действительно хорошая идея...

Есть х86 для встраиваемых прилдожений, правда по производительности это далеко не пентиум.

AM> Думаю хорошим доказательством с твоей стороны всего AM> сказанного тобой будет представить такой код на ассемблере, к примеру AM> Mitsubishi M16 или Fujitsu F2MC (на выбор) через 2 дня (ну максимум AM> через неделю) здесь, в студии. В качестве исходного кода можешь взять AM> например стек

откомпилированнй под х86

MP> Я не буду этого делать, по нескольким причинам, вопервых это не на асме MP> написано а на ваших любимых сях,

Откомпилируй и полушишь exe, думаю тебе не проблема будет его дизассемблирвоать. Ты же сказал, что тебе даже не важно наличие исходного кода.

MP> во вторых - я не знаю асм митцу и фуджи, в 3-х MP> даже если таковая задача будет поставлена в пределах моей ограниченности - мне MP> лично это абсолютно не интересно, чтоб заниматся этим бесплатно или "на спор". MP> И вообще Анди - это тяжелая механическая работа не требующая ни ума ни MP> фантазии, ни каких-либо интересных исследований, любой программер с MP> фиксированой зарплатой может тебе ее сделать, ну пусть не за 2 дня (конкретно MP> эту реализацию, в которой кстати дочерта машинозависимого кода) но за неделю - MP> легко, так что спорим мы тут в конечном счете ни о чем.

То есть в конечно итоге - про 2 дня, и даже про неделю, это все распальцовка. И ассемблер ты оказывается не знаешь нужный. А кто вообще сказал, что ты его должен знать? Ты сказал про 2 дня те уточняя необходимости знания ассемблера.

MP>>> Кто-нибудь считает, что он смог бы такое написать? ;) AM>> кто он? MP>> Кто-то кроме тебя в здравом уме и без шпаргалки.

AM> Это наезд? AM> Аргументы кончились?

MP> Hет это не наезд а действительно серьъезный вопрос. Hадеюсь ты не хочешь MP> сказать, что помнишь названия всех 256-ти бит адресуемых элементов MCS51 и MP> соответствующих им кодов?

Нет конечно, им обычно сопоставлены символические имена в хидерах через #define. Хидеры пишутся один раз, а обычно вообще поставляются вместе с компилтором под все изветные чипы.

MP>> понял откуда берется 0x90 и как оно коррелирует с p1.0 AM> Hу что ты из себя изображаешь дурочка? AM> Сам все понял, ответить по существу нечего, взамен начинаешь глупо AM> улыбаться и придираться к запятым.

MP> Я тебе ответил по существу: MP> 1) да я понял. понял КАЖДУЮ СТРОЧКУ В ТВОЕМ КОДЕ! что, зачем, и почему. MP> 2) читаемости нет. Почему нет - потму что любого человека, который всю жизнь MP> писал на си но никогда не видел x51 это поставит в тупик. следовательно - тот MP> же асм, вид сбоку.

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

MP> Ты мои ответы или пропустил или проигнорировал - не знаю.

Это не ответы, это отговорки.

Всем привет!

Oleksandr Redchuk писал к George Shepelev snipped-for-privacy@f124.n.z2.fidonet.org> 18.01.2004:

OR> b = (bool)2;

GS>> У разработчиков компилятора руки сами знаешь из какого места росли ;) OR> А вот это можно будет заявить только в том случае, если после этого OR> он воспримет как true выражение OR> b==2

даже и в этом случае нельзя - имеет право (определяется реализацией). Единственное, что компилятор обязан обеспечить - это чтобы 0 оставался нулем, а любое ненулевое значение - не нулем. Большего от него стандарт не требует.

MP>> Для меня сама идея - бредова, что можно такого написать на асме MP>> 11-го проца, что нельзя было-бы вопервых понять до последнего MP>> байта, во вторых поддерживать в том виде что есть... была бы MP>> задача и оплата.

AM> У тебя видимо в запасе есть машина времени, или какой-то замедлитель AM> времени. Поделись, а?

MP> Hет - это похоже у тебя есть ускоритель! Ведь для поддержки проэкта на том-же MP> языке далеко не всегда нужно разбиратся в тонкостях работы каждой подпрограммы, MP> достаточно знать как это работает в общем и целом

Да уж. Это смотря как код написан. Может автор принял решение, что например, регистры R6 и R7 не подлежат модификации и используются для хранения глобальных переменных. Ты об этом - не знаешь/не прочитал/не увидел. При соправождении использовал R6 и получил букет трудно объяснимых глюков.

MP> , а вот для переписывания на MP> другой язык, (процессор) требуется как раз доскональное знание как всей MP> программы в целом, так и исходного ассемблерва и финального асм/ЯВУ, а тут уже MP> начинается колизия. Ведь если таковое знание есть, то переписывание - на самом MP> деле банальная потеря времени!

Вот для этого не нужно переписывать, а нужно сразу писать на ЯВУ. Противопоказаний к этому практически нет.

MP> Так что я например придерживаюсь мнения, что в данном конкретном примере Дима MP> ничего не изучал, и ничего не переписывал!, он просто написал заново с нуля MP> свой си-код, скорее всего по ТЗ, либо представляя алгоритм работы устройства MP> как "черного ящика", поскольку в мелких проэктах зачастую этот способ просто MP> быстрее, чем разбирательство в чужом коде (что я вам скажу тоже надо уметь)...

Именно поэтому поддержка на ассемблере и затруднена.

MP>> но если бы например одного из этих семейств небыло - мир бы не MP>> остановился!

AM> А если бы в твоем городе не было доступно ни одного семейства, ты бы AM> наверное пошел в дворники ? :)

MP> Смейся смейся. Знаешь как сложно найти нормального токаря?

Причем здесь токарь? Мы говорим про серийно выпускаемые контроллеры

MP> Программистов - как собак нерезанных!

Это кажимость. Действительно грамотных специалистов не так и много.

MP> В реале правда только штаны протирают, а как до дела так никто толком MP> ничего писать не умеет.

MP> А вот токаря фиг найдешь даже за $700 в MP> месяц, старое поколение давно спилось а у нового руки не из того места растут. MP> В пту учатся одни идиоты, после "школы жизни" так вообще - дибилы. Так что не MP> волнуйся, не пропадем ;)

Это ты в том смысле, что ты еще и токарь? :)))

Есть вполне себе х86 которые Пентиумы, и даже Пентиумы-4 и именно для ВСТРАИВАЕМЫХ применений, которые отнюдь не заканчиваются на размерах и энергетике "спичечных коробков".

Аркадий

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% выигрыша по скорости.