Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 6216 27-12-2007 08:22 | |
Ответ на »сообщение 6214« (Lisp Hobbyist)
___________________________
Ответ на »сообщение 6212« (Trurl)
___________________________
Впрочем, в целом я совсем не против улучшения поддержки ЯВУ непосредственно в железе. Но при условии, что это будет сделано более-менее эффективно, и языково-независимо наподобие LMI K-machine (которую, как ни странно, ее авторы позиционировали как Lisp-only)
Так существуют успешные реализации типизированных архитектур - совершенно языково-независимые. Наши Эльбрус-1,2 (не произведённый E2k не считаю) и IBM AS/400, по сей день очень успешно применяющийся. Правда, в AS/400 часть проверок сделана на уровне кодогенератора из промежуточного представления.
№ 6215 27-12-2007 05:24 | |
Ответ на »сообщение 6210« (Mirage)
___________________________
Ассемблер, думаю, можно в С-эквивалент (или Оберон ;) ) перевести, сведя тем самым задачу к предыдущей.:)
А попробывать слабо? Что-то реасемблеры не слишком часто встречаются :(
№ 6214 27-12-2007 04:48 | |
Ответ на »сообщение 6212« (Trurl)
___________________________
Вот возьмем Ocaml. Компилятор очнь старается в плане оптимизации и у него неплохо получается. Но все же ему приходится постоянно двигать туда-сюда биты в целых числах, чтобы использавать один из них в качестве тега.
В PDP-10 были команды извлечения/вставки из слов произвольных фрагментов (которые, насколько я помню, тоже назывались "байтами"). Правда, я уже не помню, они были совмещены с командой выборки/записи в память, или надо было их писать отдельно. Насколько я помню, главным аргументом введения аппаратных тегов была возможность их проверки параллельно с исполнением команд. Но сейчас мы имеем суперскалярные процессоры, в которых явно заданный код такой проверки вполне может выполняться параллельно же, но на универсальном ФУ, которое во время исполнения команд, где проверка не требуется (а при статической типизации таких команд ИМХО гораздо больше, чем при выполнении сильно динамического кода типа лисповского), может быть занято чем-то более полезным.
Впрочем, в целом я совсем не против улучшения поддержки ЯВУ непосредственно в железе. Но при условии, что это будет сделано более-менее эффективно, и языково-независимо наподобие LMI K-machine (которую, как ни странно, ее авторы позиционировали как Lisp-only), а не в виде аппаратного интерпретатора некоторого ЯВУ.
№ 6213 27-12-2007 02:39 | |
Ответ на »сообщение 6206« (Mirage)
___________________________
Не понимаю что там может быть завязано именно на C. Теоретически ни чего, практически интел заинтересован в продвижении своих процессоров (коих и так не мало), а не всех существующих языков. Делать аналог .NET, пусть даже в два-три раза более быстый нет им ни какого смысла.
№ 6212 27-12-2007 00:38 | |
Ответ на »сообщение 6208« (Lisp Hobbyist)
___________________________
А чем процессоры с аппаратным контролем типов существенно облегчат жизнь модным нынче языкам со строгой статической типизацией?
Вот возьмем Ocaml. Компилятор очнь старается в плане оптимизации и у него неплохо получается. Но все же ему приходится постоянно двигать туда-сюда биты в целых числах, чтобы использавать один из них в качестве тега.
№ 6211 26-12-2007 13:13 | |
Ответ на »сообщение 6208« (Lisp Hobbyist)
___________________________
Ответ на »сообщение 6205« (Trurl)
___________________________
А чем процессоры с аппаратным контролем типов существенно облегчат жизнь модным нынче языкам со строгой статической типизацией?
Языкам - ничем! А вот операционным системам и программно-аппаратным системам в целом - очень даже.
Если архитектура сделана грамотно, то "переповешаться" придётся уже не честным сишникам (которые всегда могут просто "не хацкать"), а вирусописателям и прочей братии. Ибо сквозь аппаратную защиту уже не прорвёшься :-)
См. http://www.mcst.ru/SECURE_INFORMATION_SYSTEM_V5_2r.pdf
аппаратной поддержки барьеров чтения/записи, нужных в эффективных алгоритмах сборки мусора
Хорошая вещь, кто ж спорит.
№ 6210 26-12-2007 12:00 | |
Ответ на »сообщение 6209« (Сергей Перовский)
___________________________
Ответ на »сообщение 6206« (Mirage)
___________________________
В качестве контрпримера: попробуйте в качестве входных языков представить ассемблеры процессоров с другой архитектурой. И как их переводить в этот промежуточный язык? Хотя императивнее ассемблера трудно найти :)
Ассемблер, думаю, можно в С-эквивалент (или Оберон ;) ) перевести, сведя тем самым задачу к предыдущей.:)
Вообще критичные к быстродействию алгоритмы они часто ведь похожую структуру имеют. Как правило это цикл, что-то берущий из памяти и что-то вычисляющий. Возможно, записывающий в память.
Кстати, идея оптимизатора для Блэкбокса "малой кровью".:)
Берется блок исходного кода, переводится в С (есть вроде такое уже), отдается компилятору (ICC, GCC, BCC,с каким сростется), тот выдает объектник, который уже можно запихать в код.
№ 6209 26-12-2007 11:27 | |
Ответ на »сообщение 6206« (Mirage)
___________________________
Собственно хотелось бы, чтобы было не свое, а общее. Хотя бы для императивных языков.
В качестве контрпримера: попробуйте в качестве входных языков представить ассемблеры процессоров с другой архитектурой. И как их переводить в этот промежуточный язык? Хотя императивнее ассемблера трудно найти :)
№ 6208 26-12-2007 11:16 | |
Ответ на »сообщение 6205« (Trurl)
___________________________
Задача ведь не в том, чтобы испортить жизнь сишникам, а чтобы облегчить её остальным.
А чем процессоры с аппаратным контролем типов существенно облегчат жизнь модным нынче языкам со строгой статической типизацией? Если мне не изменяет память, Лука Карделли определял "type soundness" именно как принципиальное отсутствие ошибок типизации во время исполнения программ. Что же касается динамических языков --- там поддержка железа может пригодиться, но что на самом деле важнее всего? Насколько я помню, некоторое количество лет назад об этом был разговор в comp.lang.lisp, где, кажется, один из сотрудников Franz сказал, что им больше всего не хватает в архитектуре x86 вовсе не тегов, а быстрой обработки прерываний и аппаратной поддержки барьеров чтения/записи, нужных в эффективных алгоритмах сборки мусора.
№ 6207 26-12-2007 10:18 | |
Ответ на »сообщение 6206« (Mirage)
___________________________
Не понимаю что там может быть завязано именно на C. Что вообще умеет делать ICC? Надо Pepper'a спросить. :)
Я не пользовался интеловским компилятором в работе. Вычисления с плавающей точкой меня мало интересуют.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|