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



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



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


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





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

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



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


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



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

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

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


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



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


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


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


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



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




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



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

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


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


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

[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]

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

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

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

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