Ответ на »сообщение 6214« (Lisp Hobbyist)
___________________________

Ответ на »сообщение 6212« (Trurl)
___________________________
Впрочем, в целом я совсем не против улучшения поддержки ЯВУ непосредственно в железе. Но при условии, что это будет сделано более-менее эффективно, и языково-независимо наподобие LMI K-machine (которую, как ни странно, ее авторы позиционировали как Lisp-only)

Так существуют успешные реализации типизированных архитектур - совершенно языково-независимые. Наши Эльбрус-1,2 (не произведённый E2k не считаю) и IBM AS/400, по сей день очень успешно применяющийся. Правда, в AS/400 часть проверок сделана на уровне кодогенератора из промежуточного представления.

Ответ на »сообщение 6210« (Mirage)
___________________________
Ассемблер, думаю, можно в С-эквивалент (или Оберон ;) ) перевести, сведя тем самым задачу к предыдущей.:)
А попробывать слабо? Что-то реасемблеры не слишком часто встречаются :(

Ответ на »сообщение 6212« (Trurl)
___________________________

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

В PDP-10 были команды извлечения/вставки из слов произвольных фрагментов (которые, насколько я помню, тоже назывались "байтами"). Правда, я уже не помню, они были совмещены с командой выборки/записи в память, или надо было их писать отдельно. Насколько я помню, главным аргументом введения аппаратных тегов была возможность их проверки параллельно с исполнением команд. Но сейчас мы имеем суперскалярные процессоры, в которых явно заданный код такой проверки вполне может выполняться параллельно же, но на универсальном ФУ, которое во время исполнения команд, где проверка не требуется (а при статической типизации таких команд ИМХО гораздо больше, чем при выполнении сильно динамического кода типа лисповского), может быть занято чем-то более полезным.

Впрочем, в целом я совсем не против улучшения поддержки ЯВУ непосредственно в железе. Но при условии, что это будет сделано более-менее эффективно, и языково-независимо наподобие LMI K-machine (которую, как ни странно, ее авторы позиционировали как Lisp-only), а не в виде аппаратного интерпретатора некоторого ЯВУ.

Ответ на »сообщение 6206« (Mirage)
___________________________
Не понимаю что там может быть завязано именно на C. Теоретически ни чего, практически интел заинтересован в продвижении своих процессоров (коих и так не мало), а не всех существующих языков. Делать аналог .NET, пусть даже в два-три раза более быстый нет им ни какого смысла.

Ответ на »сообщение 6208« (Lisp Hobbyist)
___________________________
А чем процессоры с аппаратным контролем типов существенно облегчат жизнь модным нынче языкам со строгой статической типизацией?

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

Ответ на »сообщение 6208« (Lisp Hobbyist)
___________________________

Ответ на »сообщение 6205« (Trurl)
___________________________
А чем процессоры с аппаратным контролем типов существенно облегчат жизнь модным нынче языкам со строгой статической типизацией?

Языкам - ничем! А вот операционным системам и программно-аппаратным системам в целом - очень даже.
Если архитектура сделана грамотно, то "переповешаться" придётся уже не честным сишникам (которые всегда могут просто "не хацкать"), а вирусописателям и прочей братии. Ибо сквозь аппаратную защиту уже не прорвёшься :-)
См. http://www.mcst.ru/SECURE_INFORMATION_SYSTEM_V5_2r.pdf

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

Ответ на »сообщение 6209« (Сергей Перовский)
___________________________

Ответ на »сообщение 6206« (Mirage)
___________________________
В качестве контрпримера: попробуйте в качестве входных языков представить ассемблеры процессоров с другой архитектурой. И как их переводить в этот промежуточный язык? Хотя императивнее ассемблера трудно найти :)

Ассемблер, думаю, можно в С-эквивалент (или Оберон ;) ) перевести, сведя тем самым задачу к предыдущей.:)

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

Кстати, идея оптимизатора для Блэкбокса "малой кровью".:)
Берется блок исходного кода, переводится в С (есть вроде такое уже), отдается компилятору (ICC, GCC, BCC,с каким сростется), тот выдает объектник, который уже можно запихать в код.

Ответ на »сообщение 6206« (Mirage)
___________________________
Собственно хотелось бы, чтобы было не свое, а общее. Хотя бы для императивных языков.
В качестве контрпримера: попробуйте в качестве входных языков представить ассемблеры процессоров с другой архитектурой. И как их переводить в этот промежуточный язык? Хотя императивнее ассемблера трудно найти :)

Ответ на »сообщение 6205« (Trurl)
___________________________

Задача ведь не в том, чтобы испортить жизнь сишникам, а чтобы облегчить её остальным.


А чем процессоры с аппаратным контролем типов существенно облегчат жизнь модным нынче языкам со строгой статической типизацией? Если мне не изменяет память, Лука Карделли определял "type soundness" именно как принципиальное отсутствие ошибок типизации во время исполнения программ. Что же касается динамических языков --- там поддержка железа может пригодиться, но что на самом деле важнее всего? Насколько я помню, некоторое количество лет назад об этом был разговор в comp.lang.lisp, где, кажется, один из сотрудников Franz сказал, что им больше всего не хватает в архитектуре x86 вовсе не тегов, а быстрой обработки прерываний и аппаратной поддержки барьеров чтения/записи, нужных в эффективных алгоритмах сборки мусора.

Ответ на »сообщение 6206« (Mirage)
___________________________


Не понимаю что там может быть завязано именно на C. Что вообще умеет делать ICC? Надо Pepper'a спросить. :)


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