ARM начинающим Опции

[slabnoff]

2 dxp - Полностью поддерживаю!

Немного о своем опыте. Конечно, Embedded програмированием занимаюсь не особо долго, всего 8 лет, из них только 6 лет действительно серьезно и чисто программированием. Окончил я кафедру Информационных Измерительных Технологий Питерского Политеха - 50 на 50 железа и софта. Соответственно и начинал я как железячник+программист, что называется "все в одном".

Году в 1998 начал применять в своих разработках AVR-ки. На тот момент все, что было для разработки - asm от Atmel + отладчик. С учетом того, что в принципе с asm я еще 6 класса школы хорошо был знаком (первая моя программа была вообще в маш. кодах для Радио-86РК написана) и не смотря на то, что к тому моменту уже сделал пару коммерческих проектов на Си, программирование на asm'е меня не напрягало. В тот момент я еще относился к программированию как к искусству... Но все же, какое для меня было счастье получить компилятор Си! Действительно, первое время взглянув на код, генерируемый компилятором, я ужасался. Но с другой стороны, "вам шашечки или ехать?". Программировал я коммерческие изделия и от времени разработки зачастую зависела и оплата (а премии очень хотелось ), заниматься искусством от программирования позволить я себе не мог. В результате через годик уже с десяток небольших проектов были сделаны на Си. Плоды этого решения я пожинаю до сих пор: ассемблер AVR я уже плохо помню ибо больше мне не нужен, а вот поддержка старых разработок иногда возникает. Так вот поддержка ассемблерного кода зачастую вызывает ужас: ради минимальных изменений приходится иногда кардинально перелопачивать программу (в основном как раз из-за тех самых оптимизаций). В ряде случаев просто переписываю всю программу на Си. Те же программы, которые были изначально написаны на Си требуют минимальных телодвижений.

С 1999 года работаю на новом месте. Специфика работы несколько изменилась: железом занимаюсь крайне редко и только чтобы совсем не потерять квалификацию. Так вот начинал я здесь с довольно объемного проекта (порядка 50000 строк только кода, не считая таблиц, комментариев, технологического ПО, библиотек плавающей арифметики и т.п.), в котором людьми "не верящими в Си" был продавлен чистый ассемблер - я был молодой, зеленый и не мог сопротивляться мэтрам. Проект - ПО крейтовой резервированной измерительной системы, в качестве процессоров в модулях - ADSP-2185, используемые на 90% времени как быстрые микроконтроллеры. Да, конечно ассеблер у ADSP - просто сказка, но все же ОЧЕНЬ МНОГО ВРЕМЕНИ ушло на такие вещи, которые бы в случае использования Си делать бы просто не пришлось, типа всевозможных библиотек плавающей арифметики (в итоге таки презаточил/доделал под себя библиотеку Си-компилятора) - процессоры были новыми для нашей фирмы и ничего готового не было. Из-за большого объема кода такой роскоши, как серьезная оптимизация я себе просто позволить не мог - иначе был уверен, что проект потом просто умру поддерживать; все равно пришлось делать оверхеды для функций, подобные тому, что генерирует компилятор, организовывать программный стек. В итоге времени на проект было положено, на мой взгляд, слишком много. Аналогичный по объему проект на Си, правда на другой платформе, по моим оценкам был сделан за в ТРИ РАЗА меньшее время (да, конечно код там получился весьма неэффективным - на оптимизации времени не было совсем), но заказчика ведь волновали только две вещи: СРОК ИСПОЛНЕНИЯ И РАБОТОСПОСОБНОСТЬ ИЗДЕЛИЯ.

Сейчас веду проект на ARM'ах. Естественно пишу в основном на Си. Все что пришлось сделать пока на асме - переделать порт операционки под свои нужды. Надобности в ассемблерных оптимизациях пока нет. Более того, пока и оптимизации компилятора не делал. Я просто оптимизирую код сразу на Си, при этом он остается вполне читаемым, а по ассемблерному листингу - вполне эффективным. При необходимости, конечно буду использовать ассемблер...

В общем с чем я категорически не согласен, так вот с этим:

Как я замечал в частных беседах об достоинствах и недостатках "С".
Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.
Как я понимаю этим они просто оправдывают свою не компитентность.

Я знаю очень классных программистов-эмбеддеров пишущих ТОЛЬКО на Си. Знаю натуральных, извините, дебилов воспевающих ассемблер (пришлось как-то такой чужой проект поддерживать - чуть с ума не сошел от того, что там было сделано, причем комментариев было один на 300 строк). По моему принципы любой разработки - "вам шашечки или ехать?"+"уважаю ли я того, кто будет поддерживать мой код"+"следует умножать сущности без необходимости".

С уважением, Андрей Слабнов.

[AlexeyAS]

А что такие проекты уже не структуируются средствами АСМ и не документируются по процедурно?

Это можно сделать, но фактически нужно будет работать компилятором с ЯВУ в уме. Это не интересно.

Ну это как посмотреть незачем делать работу препроцессора руками есть макросредства где более хлипкие, где наоборот настолько расширенные, что пользоваться ими только удобно.

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

А что Вас stdcall не устраивает уже Если не способны отследить кроссы между регистрами и на регистровую передачу не тянете - пользуйтесь и stdcall и фреймами в процедурах. Честно говоря особой проблемы не вижу.

Для мелких архитектур, типа х51 размещение локальных переменных функций в памяти - вообще задача не тривиальная, если ее делать руками. Ну и т.п. А потом ради чего? Ради мифических 30% размера кода/производительности? Так оно и на Ц с некоторым запасом.

аргумерты оптимизации и сверхоптимизации (asm) по порядку

a) при определенной экономии кода остается место на бесполезненную модернизацию путем soft upgrade в масштабах того же устройства как понимаете.
б) при определенной экономии ресурса (производительности) опять таки остается возможность функциональной модернизации путем того же soft upgrade.
в) остается гипотетическая возможность заказного чипа на порядок дешевле но без излиществ в ASIC - это сейчас широко практикуется.

Возразить можно что а) и б) можно успеть сделать после, но вопрос что дешевле сразу или несколько погодя?

Сейчас такие средства появляются как графические ассемблеры - это вообще лучший выход из ситуации.

Это сейчас, а я говорю про 5 лет назад. Да и мое имхо, все эти вижал-средства для embedded больше игрушки. Попытка ввести в embedded то, что сейчас есть на ПК. Программирование контроллеров при помощи мыши. Фигня - не верю.

Что за ерунда!!! Какие еще визуал средства?! Какие мышевозения?! Что Вы, господь с вами! Или вот это:

r1 <- r2 + r3

считается визуал средствами визуйльной разработки? Я говорю про такие вещи как AVR AlghoritmBuilder помогающий структуировать низкоуровневый код настолько понятно и куда наглядней ЯВУ. Таже модульность только в низкоуровневом исполнении.

А ради чего, вопрос риторический.
Следую вашей логике можно как и в мире CPU платить огромные деньги за 30% прибавку производительности, что бы писать на ЯВУ всем и как угодно, затем еще на 10% что бы писать было быстро и каждый год по 5% что бы еще быстрее.

Вопрос очень даже практический. Если программа занимает 1К на асме, и 1.5К на Ц при доступной памяти 2К, то 0.5К оверхеда Ц бесплатно.

Как правило оверхед все таки выше, ведь мы рассматриваем проект а не несколько функций из него, к тому же еще и оптимизированных по асм подстрочнику. В среде embedded нет мощных оптимизирующих компиляторов допрыгивающих например до Watcom. Для того что бы достигнуть подобного уровня нужно "разжевывать" иначе компилер еще и ляпы даст, такие что выйдет дабловерхедом. Например процедура сортировки пузыркем в классическом виде будет иметь 30% оверхед и размера и производительности. Иногда компилеру просто невозможно разжевать и сдвиг то через C есть намболее качесвтенный пример

Только не надо мне петь про тот граничный случай, когда на асме влазит в 1 кристалл, а на Ц нужно брать более старший и платить на с50 больше. Если это даже так, то в наших, российских условиях, где преобладает мелкотиражное производтство, это мало кого волнует.

А я Вам и не пою про размеры кристаллов, как Вы уже могли заметить, я назвал причины а),б),в) должные побудить писать на средствах низкого уровня (заметье я не говорю именно ассемблер). Только попробуйте скажите что средства низкого уровня не позволяют структуировать и заставляют делать дурную работу

Гораздо больше волнует выскочить на рынок быстрее, а там других расходов немерянно. Те же испытания на ЭМС сделать, метрологию, в коммандировки слетать по 3000р за номер/сутки - и c50 за контроллер покажутся вам каплей в морe, если до этого действительно дойдет.

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

Их еще надо начать заработывать на этом проекте, а потом, если уж это будет настолько критично, можно и вылизать программу хоть на асм и снизить производтственные затраты. Но это будет оправдываться действительно при очешь больших тиражах, что для россии все же редкость.

Насчет "вылизать" я не буду верить в это с самого начала коммерческого проекта. Самое интересное то что так говорят абсолютно все! В итоге, проект бросается и заказчику говорят, да бросьте вы свой пылесосо, КПК или телефон (к примеру) мы выпустили новый, а старый там же нет того и того, а оно вам так надо! Не ощущаете схожесть ситуаций?!

[Andy Mozzhevilov]

Это можно сделать, но фактически нужно будет работать компилятором с ЯВУ в уме. Это не интересно.

Ну это как посмотреть незачем делать работу препроцессора руками есть макросредства где более хлипкие, где наоборот настолько расширенные, что пользоваться ими только удобно.

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

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

А что Вас stdcall не устраивает уже Если не способны отследить кроссы между регистрами и на регистровую передачу не тянете - пользуйтесь и stdcall и фреймами в процедурах. Честно говоря особой проблемы не вижу.

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

Для мелких архитектур, типа х51 размещение локальных переменных функций в памяти - вообще задача не тривиальная, если ее делать руками. Ну и т.п. А потом ради чего? Ради мифических 30% размера кода/производительности? Так оно и на Ц с некоторым запасом.

аргумерты оптимизации и сверхоптимизации (asm) по порядку

a) при определенной экономии кода остается место на бесполезненную модернизацию путем soft upgrade в масштабах того же устройства как понимаете.
б) при определенной экономии ресурса (производительности) опять таки остается возможность функциональной модернизации путем того же soft upgrade.
в) остается гипотетическая возможность заказного чипа на порядок дешевле но без излиществ в ASIC - это сейчас широко практикуется.
Возразить можно что а) и б) можно успеть сделать после, но вопрос что дешевле сразу или несколько погодя?

Заказной чип на порядок дешевле - не смешите. Сейчас контроллер ARM стоит от $2, куда дешевле? Знаете сколько стоит подготовка производства заказных чипов? Знаете, при каких тиражах это все начинает окупаться? Сколько раз в своей практике вы делали заказ заказных чипов?

Что за ерунда!!! Какие еще визуал средства?! Какие мышевозения?! Что Вы, господь с вами! Или вот это:

r1 <- r2 + r3

Как это выражение относится к словосочетанию графический ассемблер?
Наличием стрелочки в пересылке? Что такое здесь r1 r2 и r3, какие сущности они выражают? В чем кайф?

Как правило оверхед все таки выше, ведь мы рассматриваем проект а не несколько функций из него, к тому же еще и оптимизированных по асм подстрочнику.

Да ну вас.

классическом виде будет иметь 30% оверхед и размера и производительности. Иногда компилеру просто невозможно разжевать и сдвиг то через C есть намболее качесвтенный пример

Как я и писал выше, любимый пример, сдвиг через перенос.

Насчет "вылизать" я не буду верить в это с самого начала коммерческого проекта. Самое интересное то что так говорят абсолютно все! В итоге, проект бросается и заказчику говорят, да бросьте вы свой пылесосо, КПК или телефон (к примеру) мы выпустили новый, а старый там же нет того и того, а оно вам так надо! Не ощущаете схожесть ситуаций?!

нет, не ощущаю, устал от непробиваемости, больше на разводы руками и вопросы из теории вероятности в стиле "а вот бывает" отвечать не намерян. Жду стандартного в этих случаях "оппонент слил, слив защитан".

PS: Впрочем, предлагаю пари любому ассемблерщику. Формулируем ТЗ на какой-нибудь проект средней сложности, в который не закладывается необходимотсь знаний в специфических областях и который может быть реализован в пределах простой evalboard на uC с периферией типа UART, светодиоды, кнопки и т.п., то есть в конфигурации, которую может сделать быстро любой. Я выполняю требования ТЗ на Ц, кто-либо на асм. Результаты сравниваем. Я утверждаю, что оверхед по объему быстродействию будет в пределах 30-50%, и скорее менее, чем более. Делать буду на LPC213x

[AlexeyAS]

Году в 1998 начал применять в своих разработках AVR-ки. На тот момент все, что было для разработки - asm от Atmel + отладчик. С учетом того, что в принципе с asm я еще 6 класса школы хорошо был знаком (первая моя программа была вообще в маш. кодах для Радио-86РК написана)

Как все однако похоже Найти бы тех людей которые монитор писали для РК и попросить бы их его на Си переделать, посмотрел бы я на нас тогда в то время как бы мы прыгали в поисках ПЗУ чуть больше стандартных 2К. Или его писали на Си )

Программировал я коммерческие изделия и от времени разработки зачастую зависела и оплата (а премии очень хотелось  ), заниматься искусством от программирования позволить я себе не мог. В результате через годик уже с десяток небольших проектов были сделаны на Си.

Вот заметьте все сводится к заурядному "время - деньги" не более!
И еще в таких коллективах !наверное! не желают тратить время на изучение других средств и технологий проектирования, а любителям в этом случае проще у них есть время и желание и возможность искать другие средства. Для 0x86 например давно уже существует c--, для AVR как я и говорил граф. ассемблер и отзывы только положительные. Сам приеняю Си только тогда когда в AVR Buider не хватает лимита по коду (у меня Демо). Было бы подобное под ARM пользовался бы не задумываясь.

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

Это случай перехода с платформы на платформу?

вещи: СРОК ИСПОЛНЕНИЯ И РАБОТОСПОСОБНОСТЬ ИЗДЕЛИЯ.

Ну все сказано этими строками абсолютно все.

[AlexeyAS]

Ну это как посмотреть незачем делать работу препроцессора руками есть макросредства где более хлипкие, где наоборот настолько расширенные, что пользоваться ими только удобно.

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

э...э.... Нет ну Вы, извините, даете. Знаете я тоже люблю Си, очень люблю С++, но отрицать очевидное....... Его препроцессор те же макросы. Далеко вы уедите без препроцессора на Си? при компиляции ключ -E поставте.

По поводу макросов на ассемблере я же говорю есть разные реализации и реинкарнации препроцессора для ассемблера, может вы не все видели?

А что Вас stdcall не устраивает уже Если не способны отследить кроссы между регистрами и на регистровую передачу не тянете - пользуйтесь и stdcall и фреймами в процедурах. Честно говоря особой проблемы не вижу.

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

Не понимаю, только что говорили о макросах и stdcall завернуть в макрос это не долго.
Собственно я о чем толкую я видел на wasm.ru как пользуются успешно очень успешно примитивным стандартным препроцессором, честно скажу так как я умею им пользоваться мне завидно, поэтому то что я пишу на Си, они пишут на ассемблере не напрягаясь. Нужно уметь пользоваться инструментом - это факт.

аргумерты оптимизации и сверхоптимизации (asm) по порядку

a) при определенной экономии кода остается место на бесполезненную модернизацию путем soft upgrade в масштабах того же устройства как понимаете.
б) при определенной экономии ресурса (производительности) опять таки остается возможность функциональной модернизации путем того же soft upgrade.
в) остается гипотетическая возможность заказного чипа на порядок дешевле но без излиществ в ASIC - это сейчас широко практикуется.
Возразить можно что а) и б) можно успеть сделать после, но вопрос что дешевле сразу или несколько погодя?

Заказной чип на порядок дешевле - не смешите. Сейчас контроллер ARM стоит от $2, куда дешевле?

Ну-ну. Вы все таки норовите не дочитать

в) остается гипотетическая возможность заказного чипа

Знаете сколько стоит подготовка производства заказных чипов? Знаете, при каких тиражах это все начинает окупаться?

Знаю.

Сколько раз в своей практике вы делали заказ заказных чипов?

Ноль.

Значит будем считать что с а) и б) Вы согласны

Что за ерунда!!! Какие еще визуал средства?! Какие мышевозения?! Что Вы, господь с вами! Или вот это:

r1 <- r2 + r3

Как это выражение относится к словосочетанию графический ассемблер?

да очень просто http://home.tula.net/algrom/russian.html

Ему такое название дали потому что он не текстовое а графическое средство.

Кстати существуют такие же средства для Си, думаете излишество?

Наличием стрелочки в пересылке? Что такое здесь r1 r2 и r3, какие сущности они выражают? В чем кайф?

ну хорошо не нравятся регистры там и подругому можно, так лучше

family <- roma + masha

Теперь хотя бы очевидны сушности

Вы попоробуйте - кайф он сам приходит во время работы и от хорошо сделанной работы

классическом виде будет иметь 30% оверхед и размера и производительности. Иногда компилеру просто невозможно разжевать и сдвиг то через C есть намболее качесвтенный пример

Как я и писал выше, любимый пример, сдвиг через перенос.

Т.е. я так понимаю в МК это излишество да? Пользоваться им не нужно и реализация этого в кристалле бесплатный довесок?

Ну вот вам из x86 - bswap, да и вообще любые свапы, что замечено разработчиками c-- и очень простенько пределано в синтаксис Си:

i >< j

Насчет "вылизать" я не буду верить в это с самого начала коммерческого проекта. Самое интересное то что так говорят абсолютно все! В итоге, проект бросается и заказчику говорят, да бросьте вы свой пылесосо, КПК или телефон (к примеру) мы выпустили новый, а старый там же нет того и того, а оно вам так надо! Не ощущаете схожесть ситуаций?!

нет, не ощущаю, устал от непробиваемости, больше на разводы руками и вопросы из теории вероятности в стиле "а вот бывает" отвечать не намерян. Жду стандартного в этих случаях "оппонент слил, слив защитан".

Собственно не ожидал ничего другого.

PS: Впрочем, предлагаю пари любому ассемблерщику.

Я не ассемблерщик. Я тот кто в чем то защищает опонентов ратающих за полное использование ресурсов.

Формулируем ТЗ на какой-нибудь проект средней сложности, в который не закладывается необходимотсь знаний в специфических областях и который может быть реализован в пределах простой evalboard на uC с периферией типа UART, светодиоды, кнопки и т.п., то есть в конфигурации, которую может сделать быстро любой. Я выполняю требования ТЗ на Ц, кто-либо на асм. Результаты сравниваем. Я утверждаю, что оверхед по объему быстродействию будет в пределах 30-50%, и скорее менее, чем более. Делать буду на LPC213x

Я с цифрами 30-50% соглашусь заранее зачем терять время. Только не пойму что это доказывает. В рамках светодиодов спорить не очем, а от более крупного проекта вроде ОС+сотовый телефона - при том же процентном оверхеде, абсолютные цифры будут другие и они как раз таки скажутся на его цене. Или несогласны.

[Andy Mozzhevilov]

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

э...э.... Нет ну Вы, извините, даете. Знаете я тоже люблю Си, очень люблю С++, но отрицать очевидное....... Его препроцессор те же макросы. Далеко вы уедите без препроцессора на Си? при компиляции ключ -E поставте.

И в Ц макросы - зло, если их использовать вместо функций. Я думаю о чем тут речь, понятно, если вы действительно хорошо владеете Ц.

нет, не ощущаю, устал от непробиваемости, больше на разводы руками и вопросы из теории вероятности в стиле "а вот бывает" отвечать не намерян. Жду стандартного в этих случаях "оппонент слил, слив защитан".

Собственно не ожидал ничего другого.

жаль, что вы именно так думаете

PS: Впрочем, предлагаю пари любому ассемблерщику.

Я не ассемблерщик. Я тот кто в чем то защищает опонентов ратающих за полное использование ресурсов.

Я правильно понял, что если в проекте не была использована ни разу, скажем команда сдвига через перенос, то ресурсы считаются не использованными на 100% и это вас напрягает?

Я с цифрами 30-50% соглашусь заранее зачем терять время. Только не пойму что это доказывает. В рамках светодиодов спорить не очем, а от более крупного проекта вроде ОС+сотовый телефона - при том же процентном оверхеде, абсолютные цифры будут другие и они как раз таки скажутся на его цене. Или несогласны.

Считаю, что проекты под вытесняющей ОС начинают требовать меньше вычислительных ресурсов процессора при проходе некоторой критической точки сложности проекта.

[Виктория]

То AlexeyAS

Ну уж про Algoritm Bilder - это совсем зря. Тоже мне графический язык (мыслить на уровне блок-схем - это тот же ассемблер).

Если нужен пример другого подхода графического программирования - то обратите взор на стандарт IEC 61131-3. Вот это профессиональный подход (правда только для предметной области АСУТП). Чтобы избежать дальнейших провокаций - да здесь еще менее оптимально, чем на Си. Но зато какая технология!

А уж про Algoritm Bilder, это уж Вы совсем зря... Ничего эта среда не дает. Кроме того, что это все на заре появилось (не было IAR и т.п.)

З.Ы: Замечено при чтении сегодняшней бурной дискуссии, что сторонники ассемблера избегают описания своего жизненного (проектного) пути

[Andy Mozzhevilov]

Сейчас я уже дома, сыт и доволен, поэтому могу неспеша и подробно ответить.

С учетом того, что в принципе с asm я еще 6 класса школы хорошо был знаком (первая моя программа была вообще в маш. кодах для Радио-86РК написана)

Как все однако похоже Найти бы тех людей которые монитор писали для РК и попросить бы их его на Си переделать, посмотрел бы я на нас тогда в то время как бы мы прыгали в поисках ПЗУ чуть больше стандартных 2К. Или его писали на Си )

Вам пытаются показать, что опыт конкретных людей не с пустого места вырос, и что конкртеные люди прошли в том числе через коды, асм и прочие прелести. Ваши же смайлики и передергивания здесь выглядят как минимум издевкой.
Да, я тоже писал в кодах совсем давно. Писал для Zx на бумаге, потом по таблицам переводил в коды и через оператор DATA интерпретатора бейсик заносил в память и там запускал. Писал очень давно на Atati - были такие мелкие компы на 6502, тоже на ассемблере с ручным переводов в коды.
Это плохо?

Программировал я коммерческие изделия и от времени разработки зачастую зависела и оплата (а премии очень хотелось  ), заниматься искусством от программирования позволить я себе не мог. В результате через годик уже с десяток небольших проектов были сделаны на Си.

Вот заметьте все сводится к заурядному "время - деньги" не более!

В том или ином виде - да. Но если бы я писал сейчас ради хобби, это был бы Ц.

И еще в таких коллективах !наверное! не желают тратить время на изучение других средств и технологий проектирования, а любителям в этом случае проще у них есть время и желание и возможность искать другие средства.
Для 0x86 например давно уже существует c--, для AVR как я и говорил граф. ассемблер и отзывы только положительные. Сам приеняю Си только тогда когда в AVR Buider не хватает лимита по коду (у меня Демо). Было бы подобное под ARM пользовался бы не задумываясь.

Это разрозненные технологии, "театр одного актера", инструмент одного процессора. Положительная сторона Ц в том, что существует стандарт на язык, в рамках которого реализованы компиляторы с него. При смене платформы необходимо лишь изучить расширения языка, связанные с особенносями архитектуры конкретного ядра.
А технологии, которые действительно помогают качественно разрабатывать и сопровождать проекты изучать надо. Могу посоветовать изучать RTOS - как технологию программирования, и CVS/SVN - как средство сопровождения проектов (независимо от того, на чем они написаны).

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

Это случай перехода с платформы на платформу?

У меня есть обширный и положительный опыт повторного использования исходников в различных проектах и для различных платформ. Есть опыт ведения одного проекта сразу на 2 платформах, скажем последний - Fujitsu MB90 и ARM.

вещи: СРОК ИСПОЛНЕНИЯ И РАБОТОСПОСОБНОСТЬ ИЗДЕЛИЯ.

Ну все сказано этими строками абсолютно все.

тогда озвучьте ваш поинт, ваше мнение, на чем вы стоите? что пытаетесь доказать?

[AlexeyAS]

И в Ц макросы - зло, если их использовать вместо функций.

Абсолютное? Что же за категоричность то такая?!
Вы вообще то, хидеры то включаете в проекты? А я то считал что использование макросов как функций облегчает порт своего кода на чужую платформу, или вы считаете что делать тайпкастинг параметров нужно каждый раз при вызове, ну просто потому что макрос-функция абсолютное зло и религия его не позволяет использовать? А совершенно детский пример реализации Max(A, и Min(A, через макрос, зряшен, будем везде писать его чистую реализацию?! Бедный Ричи! Тогда чего уж по инкапсуляции не пройтись в C++, она тоже некоторые моменты реализации скрывает, не будем использовать?

Я думаю о чем тут речь, понятно, если вы действительно хорошо владеете Ц.

Да бросьте Вы такие вещи, я не зеленый пацан что бы меня разводить на подобном )!
Я очень посредственно владею Си и гораздо хуже чем Си владею С++. Мне не стыдно придерживаться принципа «Чем шире круг познания, тем огромней граница с незнанием».

Я не ассемблерщик. Я тот кто в чем то защищает опонентов ратающих за полное использование ресурсов.

Я правильно понял, что если в проекте не была использована ни разу, скажем команда сдвига через перенос, то ресурсы считаются не использованными на 100% и это вас напрягает?

Вы знаете почему то нет, «нет» в смысле не правильно Вы меня поняли. Видимо Ваша предубежденность таки сказывается. Меня напрягает то что существует «эффективное» и «не эффективное» использование. А Вы вместо того что бы согласится, что мол да «не эффективно» мы используем ресурсы кристалла и нет в наших поделках особого изыска и красоты, воздвигаете такую ситуацию в ранг сверхнормальных «так должно быть!».
Если бы так должно быть и Си недолжна практически никогда использовать сдвиг через С (и еще кучу чего), то почему бы производителю чипов не согласится с Вами и не выпустить партию с еще более урезанной системой команд? Видимо осознает производитель что подобная способность кристалла будет востребована.
Вы же все время упираете на то что нет «кроме Си бога на земле и С++ пророк его», что с моей точки зрения совершенно необоснованно. Я вам привел пример развития как парадигмы Си (C--) так и парадигмы Асм (граф.ассемблер). Не станете же Вы отрицать что они используют ресурсы платформы в разы полнее, нет?

Я с цифрами 30-50% соглашусь заранее зачем терять время. Только не пойму что это доказывает. В рамках светодиодов спорить не очем, а от более крупного проекта вроде ОС+сотовый телефона - при том же процентном оверхеде, абсолютные цифры будут другие и они как раз таки скажутся на его цене. Или несогласны.

Считаю, что проекты под вытесняющей ОС начинают требовать меньше вычислительных ресурсов процессора при проходе некоторой критической точки сложности проекта.

Тьфу ты нуты…. Так оверхед то свое возьмет, плюс еще кретинизм не самых худших в мире разработчиков (например Samsung) и как пить дать придется и Вам и мне как потребителям на 1,5 тыс. лишнего переплачивать за бедную функциональность при весьма богатых возможностями потрохах. И через год дорабатывать его firmware будут пара тройка хакеров, так как о «на Си сгенерированном коде внутри» забудет даже сам самсунг.

[AlexeyAS]

То AlexeyAS

Ну уж про Algoritm Bilder - это совсем зря. Тоже мне графический язык (мыслить на уровне блок-схем - это тот же ассемблер).

Да что Вы говорите? Вот уж не думал что наше государство думало жопой когда ГОСТы по оформлению алгоритмов принимала. Вам выслать парочку, прочтение очень между прочим дисциплинирует. Так дальше пойдет, скоро скажем да что там алгоритм и алгоритмические конструкции – разве де мыслить так возможно Погорячились что то Вы с ремаркой.

Если нужен пример другого подхода графического программирования - то обратите взор на стандарт IEC 61131-3. Вот это профессиональный подход (правда только для предметной области АСУТП). Чтобы избежать дальнейших провокаций - да здесь еще менее оптимально, чем на Си. Но зато какая технология!

Зачем поднимать тему в этом случае, я же говорю подобные вещи существую и под С++. Но Algorithm Builder уникален именно тем что не создает подобных оверхедов при этом оставаясь интуитивно понятным в противовес ассемблеру.

А уж про Algoritm Bilder, это уж Вы совсем зря... Ничего эта среда не дает. Кроме того, что это все на заре появилось (не было IAR и т.п.) .

Был IAR и был GNU и был CodeVision, это Вы зря.

З.Ы: Замечено при чтении сегодняшней бурной дискуссии, что сторонники ассемблера избегают описания своего жизненного (проектного) пути

Я уже отвечал что я не сторонник Асм, но и Си не оправдываю за его «косность» в абсолютном большинстве случаев.


Что касается жизненного пути, я не хотел отвечать на этот вопрос, но пост ниже наполнен каким то негативом и агресией в мою сторону, хотя смайлы я ставлю именно для того что бы обсуждение не перетекло в закидывание банановой кожурой. Только что толку медалями бряцать, поверьте мне есть чем гордится. Ну так же с РК86 и ассемблера 8080 начинал по галимой бумажки писать программы без еще самого РК, но только в 8 классе, так как в мое время в 6 классе мне не так свезло и были только «Наука и Жизнь» + «ТМ» в которых описывался МК-61, БЗ-34. Их то с трудом можно считать за компьютер (у меня был МК-61), ах да в то время мне удалось познакомится еще с калькулятором от TI, с магнитными карточками для считывания и скоростью выполнения всей программы, как у МК-61 один шаг То что я писал под них – куда эффективней чем то что сейчас на Си, так как вся программа была алгоритмически выверена на десятки раз с помощью тех самых присловутых блок схем (это не долго поверьте мне, зато мысли дисциплиниурет). А еще помню на 59 (или нет?) АЦП стоял но не успел замучить (делал расчет титрования для химиков). До мозолей в пальцах (от набивок дампов из Радио) знаком с РК86 (то что печатали в ЮТ решил не делать, так как "печатку" от РК нашел вперед), Орион (эх его бы на два года раньше опубликовать), Z80 во всех реинкарнациях от сэра Клайва как и все в то время (именно с Z80 начал осваивать Си и Паскаль) , ДВК и PDP в институте, ИСКРА на кафедре и «Поиск» в личном владении (ох и Г.) мои первые x86. Пневмо-автоматика и карты Карно для оптимизации- защита диплома на кафедре это первый «макроконтроллер» . Начиная с этого момента все конструкции только для себя PIC, затем AVR, ну про x86 молчу. Теперь наконец получил из аргусса AT91SAM7S64.
Все проекты только для себя и собственной конторы как уже и говорил. Да я сроками не ограничен, потому могу позволить себе эксперименты с оптимизацией и поиском других инструментов. Жалко того кто себе такого позволить не может. По ЯВУ (Паскаль, Модула, Оберон, FORTH, DSSP [была даже реализованная попытка DSSP на AVR, но быстро понял что DSSP будет блистать только обрамленным в ПЛИС]) перебрав почти все и пописал на всем этом для x86, настолько долго что чуть не позабыл ассемблер, остановился на C++. Умнее Watcom компиляторов не видел, тем что вытворяет он под x86 не один другой похвастаться не может, жалко что его нет под ARM. А под ARM не один компилер не может похвастаться большим чем любой оптимизирующий под x86, хочу посмотреть на Metrowerks под ARM может он «могет»(работал с ним под BeOS), но до «своих» не дорос .

[AlexeyAS]

С учетом того, что в принципе с asm я еще 6 класса школы хорошо был знаком (первая моя программа была вообще в маш. кодах для Радио-86РК написана)

Как все однако похоже Найти бы тех людей которые монитор писали для РК и попросить бы их его на Си переделать, посмотрел бы я на нас тогда в то время как бы мы прыгали в поисках ПЗУ чуть больше стандартных 2К. Или его писали на Си )

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

Я удивлен что Вам стал не понятен смысл скрутой здесь фразы (я просто понастальгировал слегка). Читайте пост выше, специально для Вас отписался.

Ваши же смайлики и передергивания здесь выглядят как минимум издевкой.

Мои смайлики подчеркивают мое эммоциональное настроение не более.

Да, я тоже писал в кодах совсем давно. Писал для Zx на бумаге, потом по таблицам переводил в коды и через оператор DATA интерпретатора бейсик заносил в память и там запускал. Писал очень давно на Atati - были такие мелкие компы на 6502, тоже на ассемблере с ручным переводов в коды.
Это плохо?

Почему то ваша сытость, перешла в агрессию, обычно наооборот бывает. Еще раз повторю: я сам прошел через все это, так как в детском возрасте совершенно не по детски этим болел. И показал же специально на то что если бы "монитор" от РК86 не влазил бы в РФ-ку 2Кб размером то как пить дать у меня бы его не было, потому как и РФ-ку то я нашел с огоромным трудом (это потом настали другие времена, буквально через три года все изменилось и стало доступным кое что и большее). Теперь понимаете о чем я когда говорил о том что не дай бог "монитору" быть писанным на Си.

Вот заметьте все сводится к заурядному "время - деньги" не более!

В том или ином виде - да. Но если бы я писал сейчас ради хобби, это был бы Ц.
Видимо этим мы и различаемся.

И еще в таких коллективах !наверное! не желают тратить время на изучение других средств и технологий проектирования, а любителям в этом случае проще у них есть время и желание и возможность искать другие средства.
Для 0x86 например давно уже существует c--, для AVR как я и говорил граф. ассемблер и отзывы только положительные. Сам приеняю Си только тогда когда в AVR Buider не хватает лимита по коду (у меня Демо). Было бы подобное под ARM пользовался бы не задумываясь.

Это разрозненные технологии, "театр одного актера", инструмент одного процессора. Положительная сторона Ц в том, что существует стандарт на язык, в рамках которого реализованы компиляторы с него. При смене платформы необходимо лишь изучить расширения языка, связанные с особенносями архитектуры конкретного ядра.

Как часто вы меняете платформу?

Это разрозненные технологии, но на примере C# видно куда стремятся все разрозненные технологии. Не забывайте что свита делает короля, а не наоборот.

А технологии, которые действительно помогают качественно разрабатывать и сопровождать проекты изучать надо. Могу посоветовать изучать RTOS - как технологию программирования, и CVS/SVN - как средство сопровождения проектов (независимо от того, на чем они написаны).

Я с ними знаком. И речь идет не о мне к сожалению. Изучать RTOS как технологию программирования, ну может быть, у нас с Вами разные предпочтения - меня интересуют инструменты.

Это случай перехода с платформы на платформу?

У меня есть обширный и положительный опыт повторного использования исходников в различных проектах и для различных платформ. Есть опыт ведения одного проекта сразу на 2 платформах, скажем последний - Fujitsu MB90 и ARM.

Легко и непринужденно перенесутся только общие сущности, выражаясь Вашими словами. Попробуйте портируйте с x86 на ARM что нибудь очень простое, ну скажем ядро NewOS (он почти целиком на Си). Я так думаю из механизмов управления памятью портируется один хип и то !!!! головняки будут. Что говорить про переферию? Лучше оставить эту тему, порт одинаково сложен будет и для граф.асм. и для Си, к примеру.

тогда озвучьте ваш поинт, ваше мнение, на чем вы стоите? что пытаетесь доказать?

Я это уже давно сделал, почему то Вы пропустили одно слово из моих постов написанное к тому же большими буквами - меня не устраивает ЭКСТЕНСИВНЫЙ путь развития нынешних проектов, который все больше эмбедерами перенимается от PC. Будете спорить на эт утему? Да это просто очевидно. Если будете спорить я Вам теорию Вернадского озвучу и может быть Вас тогда "вставит", а может и нет. Жалко что в ВУЗах это теорию не включили в стандартный курс философии.

На чем я стою.
Для меня идеалом было бы вообще исключить прослойку между маш.кодом и ЯВУ, на этом я стою. Сделать это можно двумя способами приближая ЯВУ к палтформе (Граф.асм, C--) или приближая платформу к ЯВУ (FORTH,JAVA,DSSP - Машины). Понятно что разработчики в силу привычки и гонки за прибылью будут больше сопротивляться в первом случае. Что и происходит в рамках, например, данной дискуссии.

[Andy Mozzhevilov]

Абсолютное? Что же за категоричность то такая?!
Вы вообще то, хидеры то включаете в проекты? А я то считал что использование макросов как функций облегчает порт
своего кода на чужую платформу, или вы считаете что делать тайпкастинг параметров нужно каждый раз при вызове, ну
просто потому что макрос-функция абсолютное зло и религия его не позволяет использовать? А совершенно детский пример
реализации Max(A, и Min(A, через макрос, зряшен, будем везде писать его чистую реализацию?! Бедный Ричи!

Со времен Ц K&R много воды утекло. Сейчас есть inline функции, которые поддерживаются в С99, и С, а также имеются в качестве расширения во многох компиляторах Ц.
В С так уж сам бог велел ими пользоваться, со всеми вытекающими проверками типов и т.п.
А реализация будет ни сколько не хуже, чем при использовании макросов, только без свойственных макросам недостатков.

Тогда чего уж по инкапсуляции не пройтись в C++, она тоже некоторые моменты реализации скрывает, не будем использовать?

Это одна из парадигм языка, а не побочные эффекты использования

Вы знаете почему то нет, «нет» в смысле не правильно Вы меня поняли. Видимо Ваша предубежденность таки сказывается.
Меня напрягает то что существует «эффективное» и «не эффективное» использование. А Вы вместо того что бы согласится,
что мол да «не эффективно» мы используем ресурсы кристалла и нет в наших поделках особого изыска и красоты,

А вы мои посты выше почитайте в этой теме, так я там об этом сразу говорил. Или я должен конкретно в обрашении к вам это повторить?
Да, не эффективно, не полностью, не выжимаем из кристалла все до последней капли. Но потери известны, и они не так велики, и в большом числе случаев бесплатны.

воздвигаете такую ситуацию в ранг сверхнормальных «так должно быть!».

А как вы хотели? Получая скорость в одном - разработке, удобство в другом - сопровождении, нисколько не потерять в быстродействии/объеме?
Да, так и должно быть, главное здесь, отдавать себе отчет в этом, уметь оценить % потерь.

Если бы так должно быть и Си недолжна практически никогда использовать сдвиг через С (и еще кучу чего), то почему бы
производителю чипов не согласится с Вами и не выпустить партию с еще более урезанной системой команд? Видимо осознает
производитель что подобная способность кристалла будет востребована.

Во первых, никто не говорит, что С флаг не используется компиляторами Ц. Просто этот флаг напрямую недоступен программисту.
А так, посмотрите, например, какой код будет при сдвиге 16 битной переменной на 8 битных платформах.
Ц сгенерит код для переноса разряда между старшим и младшим байтом через флаг С.
А потом, ассемблер в критических местах никто не отменял.

Вы же все время упираете на то что нет «кроме Си бога на земле и С++ пророк его», что с моей точки зрения
совершенно необоснованно.

Дайте ссылку на мои слова или цитату.

Я вам привел пример развития как парадигмы Си (C--) так и парадигмы Асм (граф.ассемблер).
Не станете же Вы отрицать что они используют ресурсы платформы в разы полнее, нет?

Нет, не стану. Как и не делал этого никогда. Но, как я и говорил уже, это в большинстве случаев искусство ради искусства.

Считаю, что проекты под вытесняющей ОС начинают требовать меньше вычислительных ресурсов процессора при проходе
некоторой критической точки сложности проекта.

Тьфу ты нуты…. Так оверхед то свое возьмет, плюс еще кретинизм не самых худших в мире разработчиков (например
Samsung) и как пить дать придется и Вам и мне как потребителям на 1,5 тыс. лишнего переплачивать за бедную
функциональность при весьма богатых возможностями потрохах. И через год дорабатывать его firmware будут пара тройка
хакеров, так как о «на Си сгенерированном коде внутри» забудет даже сам самсунг.

Вы не разрабатывали RealTime приложения под вытесняющей ОС и сложные проекты, поэтому и не понимаете, отчего там получается выигрыш при использовании RTOS.
Поэтому, я воздержусь здесь от лишних доказательств. Лучше почитайте форум по RTOS.

Как часто вы меняете платформу?

Бывает, вот список основных, с которыми я работал плотно и под которые были реальные проекты:
Z80, x51, AVR, Fujitsi FFMC, ARM
кроме того, менее плотно: PIC, Z8, DSP56F.

Часть проектов Z80-x51 живет на одних исходниках.
Сейчас проект FFMC-ARM живет на одних исходниках.
Множество исходников повторно используются в разных проектах, либо на разных пратформах, либо и так и так.

Легко и непринужденно перенесутся только общие сущности, выражаясь Вашими словами. Попробуйте портируйте с x86 на
ARM что нибудь очень простое, ну скажем ядро NewOS (он почти целиком на Си). Я так думаю из механизмов управления
памятью портируется один хип и то головняки будут. Что говорить про переферию? Лучше оставить эту тему, порт
одинаково сложен будет и для граф.асм. и для Си, к примеру.

Для периферии пишется HAL для конкретной платформы, и возможно даже для конкретного чипа платформы. HAL обладает стандартным API
на всех платформах. Все, что выше, уже платформонезависимо. А выше - как раз основное, алгоритмы работы устройства.

На чем я стою.
Для меня идеалом было бы вообще исключить прослойку между маш.кодом и ЯВУ, на этом я стою. Сделать это можно двумя
способами приближая ЯВУ к палтформе (Граф.асм, C--) или приближая платформу к ЯВУ (FORTH,JAVA,DSSP - Машины). Понятно
что разработчики в силу привычки и гонки за прибылью буддут больше сопротивляться в первом случае. Что и происходит в
рамках, например, данной дискуссии.

Вы стоите на том, чего в данный момент не существует, либо существует в виде разрозненных технологий для ограниченного
набора либо единичного процессора. Тут можно мечтать о всем, чем угодно. Но здесь идет обсуждение существующих реальностей.

[AlexeyAS]

[QUOTE]Со времен Ц K&R много воды утекло. Сейчас есть inline функции, которые поддерживаются в С99, и С, а также имеются в качестве расширения во многох компиляторах Ц.
В С так уж сам бог велел ими пользоваться, со всеми вытекающими проверками типов и т.п.
А реализация будет ни сколько не хуже, чем при использовании макросов, только без свойственных макросам недостатков.[/QUOTE]

Вы отключите как макросы в хидерах ну хотя бы в GCC GNU для ARM (я молчу про x86) и посмотрим куда денется повторное использование кода, накопленного годами. Или все таки вы вообще не подключаете хидеров, а может они у Вас собственные, полностью переписанные в inline? То что вы говорите про inline – обыкновенное «множить сущности, без достаточной на то необходимости» и это IMHO (не стоит оппонировать). У inline свои проблемы использования. Запретить макросы для Си, все равно что заставить Си строго типизировать. Использовать или нет макросы – это все равно, что выбирать между безопасностью секса в рваном презервативе и вообще без презерватива. Хотите безопасного – пользуйте Виртовское семейство или Java с C#. Например гнутые Паскали я видел и мне кажется там был ARM.

[QUOTE][QUOTE]
Тогда чего уж по инкапсуляции не пройтись в C++, она тоже некоторые моменты реализации скрывает, не будем использовать?
[/QUOTE]
Это одна из парадигм языка, а не побочные эффекты использования[/QUOTE]

Вы упорно не хотите замечать, что у каждой медали есть реверс и есть аверс?

[QUOTE]
[QUOTE]
Вы знаете почему то нет, «нет» в смысле не правильно Вы меня поняли. Видимо Ваша предубежденность таки сказывается.
Меня напрягает то что существует «эффективное» и «не эффективное» использование. А Вы вместо того что бы согласится,
что мол да «не эффективно» мы используем ресурсы кристалла и нет в наших поделках особого изыска и красоты,
[/QUOTE]
А вы мои посты выше почитайте в этой теме, так я там об этом сразу говорил. Или я должен конкретно в обрашении к вам это повторить?[/QUOTE]

Так, простите, в настоящий момент как раз таки я свою позицию Вам разжевываю, а Вы сопротивляетесь очевидным фактам.

[QUOTE]Да, не эффективно, не полностью, не выжимаем из кристалла все до последней капли. Но потери известны, и они не так велики, и в большом числе случаев бесплатны.[/QUOTE]

Ну тогда уж сделайте следующий шаг и скажите, наконец, что при увеличении проекта количественно - возрастет абсолютная цифра «оверхеда». Чего вы упрямитесь то – сей математический факт нет смысла отрицать. Отсюда простые выводы – оверхед душит любой проект и толкает разработчиков заранее закладываться на большие ресурсы. Соответственно это повышает стоимость конечного устройства, в итоге в накладе клиент. Я сейчас говорю про сотовые и КПК как наиболее яркие представители.


[QUOTE][QUOTE]
воздвигаете такую ситуацию в ранг сверхнормальных «так должно быть!».
[/QUOTE]
А как вы хотели? Получая скорость в одном - разработке, удобство в другом - сопровождении, нисколько не потерять в быстродействии/объеме?
Да, так и должно быть, главное здесь, отдавать себе отчет в этом, уметь оценить % потерь.
[/QUOTE]
Ну вот про что и разговор с некоторых пор – это называется профессиональный подход. Я хотел бы по другому – не теряем в быстродействии/объеме, ВЫИГРЫВАЕМ в стоимости, проигрываем в начальном этапе освоения средств позволяющих это делать и выработке опыта работы с ними.
Если говорить о том "что так должно быть" – значит ждать когда количественное перейдет в качественное. За 70 лет советской власти принцип так и не сработал, ожидаете что сейчас он выстрелит?

[QUOTE][QUOTE]
Если бы так должно быть и Си недолжна практически никогда использовать сдвиг через С (и еще кучу чего), то почему бы
производителю чипов не согласится с Вами и не выпустить партию с еще более урезанной системой команд? Видимо осознает
производитель что подобная способность кристалла будет востребована.
[/QUOTE]
Во первых, никто не говорит, что С флаг не используется компиляторами Ц. Просто этот флаг напрямую недоступен программисту.
А так, посмотрите, например, какой код будет при сдвиге 16 битной переменной на 8 битных платформах.
Ц сгенерит код для переноса разряда между старшим и младшим байтом через флаг С.
А потом, ассемблер в критических местах никто не отменял.[/QUOTE]

Вот я и говорю что вы либо торопитесь ответить, либо плохо читаете:
[QUOTE]Если бы так должно быть и Си недолжна практически никогда использовать сдвиг через С[/QUOTE]

Назовите-ка лучше платформы где этого флага нет или двигать через него нельзя. Догадываетесь к чему я клоню?

[QUOTE][QUOTE]
Вы же все время упираете на то что нет «кроме Си бога на земле и С++ пророк его», что с моей точки зрения
совершенно необоснованно.
[/QUOTE]
Дайте ссылку на мои слова или цитату.[/QUOTE]

Хотите что бы я каждую вашу строчку отцитировал? Тяжело мне придется.
Ну что стоит хотя бы это:

[QUOTE]В том или ином виде - да. Но если бы я писал сейчас ради хобби, это был бы Ц.
[/QUOTE]
Это означает, в моем конечно же понимании, что вы даже ради хобби не готовы съехать с накатанных рельсов и попробовать, что либо другое.

[QUOTE][QUOTE]
Я вам привел пример развития как парадигмы Си (C--) так и парадигмы Асм (граф.ассемблер).
Не станете же Вы отрицать что они используют ресурсы платформы в разы полнее, нет?
[/QUOTE]
Нет, не стану. Как и не делал этого никогда. Но, как я и говорил уже, это в большинстве случаев искусство ради искусства.[/QUOTE]

Повторюсь! Не король делает свиту, а свита – короля! Тонкая оптимизация на Си так же сродни искусству, но вы же ей занимаетесь?


[QUOTE]Вы не разрабатывали RealTime приложения под вытесняющей ОС и сложные проекты, поэтому и не понимаете, отчего там получается выигрыш при использовании RTOS.[/QUOTE]

С чего это Вы взяли?

[QUOTE][QUOTE]
Как часто вы меняете платформу?
[/QUOTE]

Бывает, вот список основных, с которыми я работал плотно и под которые были реальные проекты: [/QUOTE]

Так как часто? Раз в месяц? Раз в год? Раз в квартал?

[QUOTE]Для периферии пишется HAL для конкретной платформы, и возможно даже для конкретного чипа платформы. [/QUOTE]

Да "не возможно" а именно так и есть!!! А переписать HAL та еще задача. Уж где где а в этом лэере не предвидится приятных сюрпризов.

[QUOTE]HAL обладает стандартным API на всех платформах. [/QUOTE]

Это не HAL обладает стандартным API это ядро обладает стандартным API, а HAL уж как получится. Да и потом сколько спецификаций аппаратных интерфейсов (тех же шин) поменялось через Вас? И какой процент старых аппартных интерфейсов с первых ваших платформ остался в нынешних?

[QUOTE]Все, что выше, уже платформонезависимо. А выше - как раз основное, алгоритмы работы устройства. [/QUOTE]

Ну и сколько это процентов?! Так на вскидку 10%-20%?
А теперь про FORTH контроллер скажите придется портировать? Видимо нет код то будет нативным.

По скромным прикидкам в ядре для порта только менеджер памяти и шедуллер. Ну а если это ядро – микро ядро или пико ядро, можете сразу писать его заново под новую платформу. Быстрее будет. В настоящее время куда все реал тайм ОС двигаются, к какому ядру тяготеют?

[QUOTE]Вы стоите на том, чего в данный момент не существует, либо существует в виде разрозненных технологий для ограниченного
набора либо единичного процессора. Тут можно мечтать о всем, чем угодно. Но здесь идет обсуждение существующих реальностей.[/QUOTE]

Что из того на чем я стою в настоящее время не существует?
Про разрозненность я уже говорил «свита программеров» делает их разрозненными.
Я ничего фантастического здесь не обсуждал, все о че я говорил существует. В сухом остатке Ваше не желание эти технологии осваивать, и не более того!

[Виктория]

Модератор, ау. Пора тормозить!

Пользы уже никакой - ни для начинающих, ни для продвинутых.

[IgorKossak]

Модератор, ау. Пора тормозить!

Пользы уже никакой - ни для начинающих, ни для продвинутых.

Давно пора бы.
Закрываю.