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

Пиплы, смотрите, какая замечательная идея! -> Путь будущего? http://www.gnu.org/software/lightning/
Делаем некий полу-виртуальный процессор. Он виртуален в том смысле, что его нет в виде чипа (пока нет), но архитектурно он близок, например, к MIPS. Далее софты компилим под эту виртуальную систему команд, а на целевой платформе компилим этот код в целевой. Вот отличие от маразма с х86 архитектурой, где убогую систему команд транслируют в специальный супер-пупер процессор, который живет по всех процах, начиная с Pentium, здесь лошадь стоит впереди телеги. Промежуточная система команд достаточно совершенна, и если целевой процессор убог - нам не повезло. А если он совершенен (MIPS | PowerPC, например) - так мы используем его на всю катушку. Преимущества: * в отличие от CLI, JAVA и пр., изначальный виртуальный код более приближен к реалиям железа, чем CLI, компилировать его проще. И он чуть совершенне, чем реальные процессоры, так что транформация происходит проще. Нет проблемы усоверешнствовать убогий код совершенным реальным процессором - есть проблема легкого даугрейда совершенного кода. * исчезает проблема с либами, которая есть один из hell при перекомпиляции с платформы на платформу. Либа уже прилинкована к нашему виртуальному коду. * нет проблем с модернизацией виртуальной машины. Будет MIPS-II (условно) - ок, снова сделаем виртуальную машину, чтобы она была не менее совершенна, чем реальный процессор. Самое прикольное, что по быстродействию можем и не проиграть! Смотрите. Всю сложную оптимизацию "большой" компилятор уже сделал - вынос константы за цикл и пр. (например, http://www.rusdoc. …les/10781/index2.shtml ). Нам остается только проанализировать относительно большой фрейм кода (перемещаем фрейм по коду), и оптимально впихнуть его в нашу архитектуру. А отличие от супер-пупер CLI, методы нащего виртуального кода близки к реальным методам, и задача становится сложной, но линейной - не сомневаюсь, что теоретики от алгоритимостроения сделают очень эффективный алгоритм оптимизации кода. Никаких либ нет, да хоть тупо перебирай все варианты оптимизаци и сравнивай их эффективность. Более того, в варианте многоядерности это вообще может стать хорошим подспорьем. Шансы на успех этого дела - хз. Стремно! Открывает дорогу на рынок делателям новых архитектур, да и вообще сделают поцессор под целевую архитектуру - все остальные будут курить. Так что толстые могут это дело пытаться придавить. Вообще, стратегически, от виртуализации процов никуда не уйти. Совсем скоро, чую я, это и до мелких встраиваемых систем доберется. По железу для толстых систем ваще кайф! Вместо тупой парадигмы шины стандартизуем блочный интерефейс обмена и систему виртуальных прерываний. Усе! А как блок памяти оказался там или куда он оттуда делся - это задача аппаратуры и дополнительных процессоров (я понимаю, что Intel и AMD, думают, что в машине всего ОДИН процессор, но это глупое граничение :). Впрочем, идея не нова - сопроцессор ввода-вывода. Еще в мейнфреймах применялся (и для 8086 был, кажись, 8089 назвался):)