Средства и методы разработки

На самом деле это довольно интересное направление. Системы виртуализации "среднего уровня". Есть три варианта портируемых приложений: * байт код и виртуальная машина * исходники на языке * и перекомпиляци на целевой машине * исходники на мини-языке и перекомпиляци на целевой машине. Последнее и есть средний уровень. По сути, это дальнейшее развитие идеи промежуточного кода С/С++ компилеров. Преимущества очевидны: * нет "изначальных исходников" и типа ваши тайны кода - ваши :) * очень хорошая оптимизация под целевую машину * сложность процедуры перекомпиляции невысока, не сравнима с перекомпиляцией С/С++ Известные реализации подхода: * M$ CLI http://en.wikipedi …anguage_Infrastructure * GNU lightning http://en.wikipedi …org/wiki/GNU_lightning * Low Level Virtual Machine (LLVM) http://llvm.org * С-- http://caxapa.ru/155393.html Сравнение некоторых виртуальных машин и промежуточных кодов http://en.wikipedi …ation_virtual_machines Я бы сказал так. В современном быстро меняющемся мире разработка какого-то тяжелого приложения (CAD, например) со сроком жизни 10+ лет без применения подхода виртуализации того или иного уровня бесперспективна. Чисто виртуальные машины (Java, Python и пр) не канают в случае необходимости написания каких-то средне и низкоуровневых вещей. Т.е. они требуют гигантских билиотек низкого уровня, написанных под систему. А вот среднеуровневые системы позволяют писать хоть дрова без потери перфоманса или с минимальными потерями. Заметим, что среднеуровневые системы вполне подходят и для embedded целей. Пишем Ось + коммуникационный стек, компилим в LLVM какой-нибудь, и отдаем юзеру. + четкая инструкция по написанию дров. Далее юзер берет это добро и адаптирует дровами к своей железяке. Преимущества перед С - невыдача исходников. Т.е. используя закрытые либы с секретными исходниками, я могу отдавать промежуточный код, не нарушая лицензии. Преимущества перед либами и объектниками - куда более полное использование ресурсов машины. Т.е. у нас все-таки происходт перекомпиляция, все точно подстраивается, можно активно использовать "статические сущности", определяемые на этапе компиляции (весьма полезно для экономии малых набортных ресурсов), можно играть параметрами оптмизации до полного удовлетворения. Интересно, почему так не делают в сотиках? Куда перспективнее Java какой-нибудь. В современных сотиках так не мало ресрсов, что перекомпилятор влез бы на борт без особого напряга. Причем, заметим, идея привязки к монополии сохраняется. Можно сделать C-- имени нас, закрыть его, а далее гляй-не хочу: сегодня мы выпусили сотик на ARM, завтра на MIPS, после завтра - еще на каком-нибудь полузаказном проце, который очень эффективен по питанию, потом и до атома дело дойдет. В итоге, если хорошо продумать, получаем суперплатформу, которая пойдет на всем - от простого сотика до навороченного мегакоммуникатора, причем софт, написанный в соотвествии с нашим стандартом, эффективно пойдет на всем этом зоопарке. Различия в экранах и клаиватурах не важны: * если Ваше приложение хочет только 320х240 - юзерам с сотками 96х96 пикселей не повезло * если Ваше приложение написано грамотно и виртуализированно, и ему надо 4 строки на экране, чтобы ввести название станции и получить ближающую электричку - то оно пойдет на всем.