[Evgeny_CD 0]

На надёжность то он не будет влиять (вся секьюрная логика на сервере), максимум - на уровень речевой культуры в помещении. :) Представляю себе реакцию человека, бегущего по нужде с картой доступа наперевес... а замок вдруг зависает :maniac:

Вы не поняли! Сервера нет!!!!

 

Есть железяка с RTOS (например, на PPC405 - SDRAM ECC). На ней крутится интерпретатор CLI. Все фукции!!!

 

А пЫсюк только для тестирования и настройки.

[white.wind 0]

Частично реализацию библиотек .NET можно найти ...

 

Еще есть такая утилита как Reflector for .NET :)

[white.wind 0]

На ней крутится интерпретатор CLI.

 

Если ничего не поменялось, то интерпретатор не нужен :)

 

Там при первом запуске байткод сразу в натив компилируется под тот проц., в котором работает. Причем, компилируются только те методы, которые реально исполняются.

 

Другой вариант, откомпилить все сразу утилитой ngen, например, при инсталяции.

[TED17 0]

Если MicroFramework пойдет по пути CompactFramework, то - сливай воду- все остальное скоро станет экзотикой и будет отторгаться производителями как несовместимое и неудобное при коллективной разработке. Пробовал работать под CompactFW(для WinCE) - нет проблем - нормальный компилятор и отладка на хорошем симуляторе. А с дровами и портами уM$ никогда поблем не было. Так что скоро все основные производители embedded объявят о локализации на свои чипы и платы - а там посмотрим - много ли останется любителей экзотики. M$ можно не любить, как монополиста, но не учитывать его как серьезного игрока - большая ошибка.

[beer_warrior 0]

ак что скоро все основные производители embedded объявят о локализации на свои чипы и платы - а там посмотрим - много ли останется любителей экзотики.

И на скоки платформ они сделают порт? Или единым фронтом ARM/WinCE закроют все дыры?

[Evgeny_CD 0]

Если MicroFramework пойдет по пути CompactFramework, то - сливай воду- все остальное скоро станет экзотикой и будет отторгаться производителями как несовместимое и неудобное при коллективной разработке. Пробовал работать под CompactFW(для WinCE) - нет проблем - нормальный компилятор и отладка на хорошем симуляторе. А с дровами и портами уM$ никогда поблем не было. Так что скоро все основные производители embedded объявят о локализации на свои чипы и платы - а там посмотрим - много ли останется любителей экзотики. M$ можно не любить, как монополиста, но не учитывать его как серьезного игрока - большая ошибка.

Написание дров под свою периферию для такой системы - это целое искусство, вероятно.

 

Простой пример - 926 ядро ARM пихают в девайсы уже года три как, а массового увлечения embedded JAVA я как-то не наблюдаю (может, разве что в сотиках), особенно для промавтоматики. Или просто Embedded JAVA рано выстрелила? А за счет жезели ускорение должно быть нехилое...

 

Я, откровенно говоря, SUN не понимаю. Они что, решили присоединиться к DEC в аналах истории? :blink:

 

Ведь вот от этой штуки исходники должны лежать на кажом углу!

http://sunspotworld.com/products/

 

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

 

В конце концов, для мелкосерийных, но достаточно сложных вещей стоимость разработки важнее стоимости железа - а применение .NET похоже, способно сильно упростить разработку "верхнего уровня". Ибо в диапазоне "до 30$" сейчас умещаются PPC процы-контроллеры с производительностью 700+ DMIPS (MPC5200 от FreeScale). И обвязки им надо всего ничего - FLASH да SDRAM, которые при небольших объемах встанут не более чем в 4$.

 

Вот и представим себе, что появится "платочка" на MPC5200 за 100$, с готовыми дровами для весьма и весьма умной периферии этого камня, и все удобство .NET Studio к нашим услугам...

 

Понятно, что от M$ порт micro-.NET под PPC не появится (нет же PPC в списке целевых архитектур WinCE), так что придется натурально хачить DotGNU.

[Evgeny_CD 0]

Вроде есть еще один - Solo, но я не нашел.

Возможно, имеется в виду Mono

Да, это оно!

[TED17 0]

ак что скоро все основные производители embedded объявят о локализации на свои чипы и платы - а там посмотрим - много ли останется любителей экзотики.

И на скоки платформ они сделают порт? Или единым фронтом ARM/WinCE закроют все дыры?

У M$, как известно, "гретьи" производители железа сами пишут дрова, минипорты и пр., а M$ их только сертифицирует. Немного времени на раскачку и желающих попасть в мощный поток будет предостаточно. ARM/WinCE/CF является лишь примером удачности такого подхода. Вот и идет продолжение.

[Thistle 0]

Мне кажется некоторым участникам дискуссии стоит погуглить по словам Оберон, Никлаус Вирт, Zonnon....удачи.

[SpiritDance 0]

Мне кажется некоторым участникам дискуссии стоит погуглить по словам Оберон, Никлаус Вирт, Zonnon....удачи.

А также модула-2 :laugh: Как же припоминаем... "Вы прострелете себе голову..."

Извините за оффтопик не удержался.

 

Еще чуть-чуть оффтопика по поводу языков и sun. Вот что назревает

http://research.sun.com/projects/plrg/

[Evgeny_CD 0]

Мне кажется некоторым участникам дискуссии стоит погуглить по словам Оберон, Никлаус Вирт, Zonnon....удачи.

И что я, как один из участников дискуссии, должен узреть в Zonnon?

http://www.software.unn.ac.ru/zonnon/files...ody-toprint.pdf

 

 

Нетривиально - бо'льшая часть ресурсов по Zonnone имеют российское происхождение

http://www.zonnon.ethz.ch/language/books.html

 

Кто знает, что это такое - может просветит в кратце?

 

 

Если из Zonenon есть компилятор в .NET - то какова же скорость выполнения кода в итоге получится?

 

Вообще, судя по изобилию новых языков, в основе которых лежит байт-код, развитие идет строго по спирали:

 

CISC -> RISC -> CISC II ->?

 

CLI вполне так себе CISС архитектура...

 

Вообще, похоже наше светлое будущее - это обычный CPU какой-нибудь + FPGA, которую каждый использует в меру своей испорченности. В принципе понятно - чтобы базовый набор объектов, в который компилируется решение задачи, оптимально соотвествовал специфике решаемой задачи.

 

http://research.microsoft.com/workshops/SS...#681,2,Hardware - на сахаре подсказали...

[TED17 0]

Вообще, похоже наше светлое будущее - это обычный CPU какой-нибудь + FPGA, которую каждый использует в меру своей испорченности. В принципе понятно - чтобы базовый набор объектов, в который компилируется решение задачи, оптимально соотвествовал специфике решаемой задачи.

 

http://research.microsoft.com/workshops/SS...#681,2,Hardware - на сахаре подсказали...

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

И связка линии .NET ( Framework - CmpactFramework - MicroFramework) с полной обвязкой и есть логичное движение к единообразию процесса.

[Evgeny_CD 0]

Я так понимаю ситуацию со всеми этими новомодными языками

 

Есть три слоя embedded системы

 

* дрова; ASM оптимизированные части

* RTOS, C приложения

* интерпретатор/компилятор байткода

 

И за счет этого можно проводить многопараметрическую оптимизацию разработки:

 

* тираж, и стоимость целевого проца при таком тираже

* стоимость полного цикла разарботки, влючая документацию и тестирование

* стоимость рисков "юзер нашел глюк"

* стоимость суппорта за все время жизни проекта

* перспектива использования существующего кода в этом проекте

* перспектива использования кода этого прокта в других проектах

 

Разработчик сам определяет, что писать на С, ASM, а что на C#.

 

Собственно, нет темы для спора. Никто и никогда не буде писать на Zonnon ОСь, дрова, ISR и т.д. А вот сложные управляющие алгоритмы - очень дажа запросто. А зыку, описание которого занимает 30 страниц, можно обучать продвинутых заказчиков - и пусть они сами себе пишут алгоритмы верхнего уровня. Собственно, такая идея давно известна в промавтоматике - с IEC языками. Там кустмеры (продвинутые) сами ишут программы, при этом мыслят категориями целевой задачи, а не категориями указатель, массив и пр. И ничего - все работает!

 

Собстенно, прелесть ЯВУ-2 в том, чтобы дать кустомеру весь набор необходимых ему сущностей, и дать очень простой механизм работы с эими сущностями.

 

Вопрос по .NET. Вот написал я приложение на пысюке. Скомпилил в CLI. Запускаю на embedded системе. Либы (простые - prinf) для этого приложения линкуются также в CLI, или они должны быть реализованы отдельно на моей целевой платформе?

[bialix 0]

Согласен, ибо наблюдаю такие траблы у людей, возящихся с OC2000, QNX, Linux, которых в WIN и в помине нет. Отвратный интерфейс, документация, не поддерживается более - менее новое железо (PCI-Express, USB2, IEEE 1394, Gigabit Ethernet).

Не забудьте, что часть (большая) этих стандартов была разработана специально, чтобы "согнать" народ, который "прижукался" в 98 и 2000 виндах (ну а линухоидов "шугануть" - это вообще святое! чтобы они не забыли почувствовать себя людьми второго сорта - вот у Васи мышка с синим светиком в заднице рабоает, ибо он крутой, ему родители пЫсюк с ХРенью купили, а Петя, который полгода корпел над книжками и таки научился ставить линух, не может завести такую мышку - дров нету и не будет, ибо мышка не для пиплов второго сорта. Вывод: девочки, дружите с Васей - у него все в жизни будет правильно. А Петя - тот по жизни будет "очки драить", и в сводобное время линуховать в свое удовольствие). Ибо при создании этих стандартов изначально все, кому положено, договорились - не будет дров под старые оси.

 

Что касается технической ценности, то она есть только в PCI-Express да Gigabit Ethernet.

 

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

 

Посмотрим на это с другой стороны. Я -- производитель компьютерного железа. Не ПО! Мой бизнес -- суть продажа железяк. Как на него вляет ПО? Очень просто: под каждую ОС я, как производитель, должен написать драйвер. Т.е. держать штат драйверописателей. Хотя они не приносят прямую прибыль. Прямую прибыль приносят продажи железяк, которые покупают пользователи. Если я делаю мышки, которые прродаю по низкой цене, то я должен продать их как можно большему количеству людей, чтобы поиметь суперприбыль. Значит надо минимизировать побочные издержки. Значит нафиг мне иметь 300 программеров, которые будут писать драйвера на 300 операционнок, если пользователей операционки одного типа более 80%. И именно они главные мои покупатели? Да забью я на всякие альтернативные и старые ОС, потому что мне экономически это не выгодно. Фсё.

 

Я прочитал внимательно всю эту дискуссию. И мое мнение: имхо, даже эмбеддед отрась слишком многослойна, чтобы так однозначно делать выводы, кто победит МС или нет. Слишком много применений, и плясать надо не от тиражей в месяц, а от ожидаемого срока разработки/срока эксплуатации/общего тиража системы за ожидаемый срок продаж. И здесь искать какую прибыль обеспечит та или иная технология.

 

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

[Evgeny_CD 0]

Посмотрим на это с другой стороны. Я -- производитель компьютерного железа. Не ПО! Мой бизнес -- суть продажа железяк. Как на него вляет ПО? Очень просто: под каждую ОС я, как производитель, должен написать драйвер. Т.е. держать штат драйверописателей. Хотя они не приносят прямую прибыль. Прямую прибыль приносят продажи железяк, которые покупают пользователи. Если я делаю мышки, которые прродаю по низкой цене, то я должен продать их как можно большему количеству людей, чтобы поиметь суперприбыль. Значит надо минимизировать побочные издержки. Значит нафиг мне иметь 300 программеров, которые будут писать драйвера на 300 операционнок, если пользователей операционки одного типа более 80%. И именно они главные мои покупатели? Да забью я на всякие альтернативные и старые ОС, потому что мне экономически это не выгодно. Фсё.

Нет, вы будете поддерживать мелкомягких еще и потому, что у Вас появится легальная возможо "подкидывать" Ваших кустомеров. Новая ОСь - новое поколение "мышей" от Вас. А старое - ну оно уже устарело, зачем далать дрова для старья.

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

Если сливной бачек .NET будет сам по интеренету сообщать о количестве оставшейся бумаги и чистоте своих внутренностей, и, самое главное, будет совместим с M$ Office Pack (условное название; разумеется M$ позаботится о том, чтобы куль хацкер с AT91SAM7S не смог сделать такое же решение, - протокол общения будет столь сложен, что куль хацкер быстро устанет) - не сомневайтесь, его будут раскупать просто пачкам.