Здравствуйте, кт, Вы писали:
кт>Вопрос: есть ли еще компиляторы (с любых языков) с таким подходом к реализации динамических границ массивов? Нужно для статьи.
кт>Вот как здесь
Зачем это в язык запихивать? Просто написать, как в Сях или Паскале, нельзя?
Да еще код такой, что попробуй разберись.
Вот эти объявления попробуй прочитай. Хотя бы не сокращали. Стоило писать DECLARE вместо DCL,
Думаю также, мало кто знает, что такое BASED. Сишные указатели легче освоить.
Псевдопеременных, кроме PL/1, больше нет нигде. Знаки вопроса в начале каждой строки я вижу впервые.
?INDEX(1,2)=M; ?INDEX(2,2)=N;
?RET(ADDR(A)); // ИЗМЕНЯЕМ КОМАНДЫ ДЛЯ A
?INDEX(1,2)=N; ?INDEX(2,2)=Q;
Из текста я не понял, эти массивы в PL/1 подобны векторам или память под них выделяется один раз? Если один, то такие массивы [allocatable] есть в фортране 90. Хотя тут что-то другое. размеры передаются в процедуру извне, то есть заранее известны.
Как все же здорово, что старшие коллеги предпочли Фортран!
Здравствуйте, Privalov, Вы писали:
P>Зачем это в язык запихивать? Просто написать, как в Сях или Паскале, нельзя?
чтобы работало быстрее
P>Знаки вопроса в начале каждой строки я вижу впервые
Знак вопроса — просто разрешенный символ для имен. С этого знака начинаются имена предопределенных объектов
P>Из текста я не понял, эти массивы в PL/1 подобны векторам или память под них выделяется один раз?
нет, сколько угодно раз
P>Как все же здорово, что старшие коллеги предпочли Фортран!
Вопрос был, известны ли компиляторы, которые меняют сами команды (или операнды команд, как здесь) для реализации динамических массивов
Здравствуйте, Privalov, Вы писали:
P>Как все же здорово, что старшие коллеги предпочли Фортран!
У меня есть предположение, что предпочли они его потому как для численных алгоритмов он лучше оптимизировался, более ни для чего он был негоден.
Но если бы состояние вычислительной техники заморозилось (не развивалось в сторону персоналок и новых ЯП) в тот момент, то у PL/1 был бы шанс вытеснить его и оттуда.
Здравствуйте, кт, Вы писали:
кт>Вопрос: есть ли еще компиляторы (с любых языков) с таким подходом к реализации динамических границ массивов? Нужно для статьи.
кт>Вот как здесь
Это вообще имеет какое то значение в современных условиях для быстродействия?
Гораздо большее значение имеет как данные будут ложиться в кэш,
Здравствуйте, swame, Вы писали:
S>Это вообще имеет какое то значение в современных условиях для быстродействия?
Слухи о том, что быстродействие увеличивать больше не надо, сильно преувеличены
S>Гораздо большее значение имеет как данные будут ложиться в кэш,
Данные будут ложиться одинаково во всех реализациях, поскольку адреса в конечном итоге вычисляются одни и те же. А вот число выполняемых команд для вычисления адресов заметно уменьшается
Здравствуйте, кт, Вы писали:
P>>Зачем это в язык запихивать? Просто написать, как в Сях или Паскале, нельзя?
кт>чтобы работало быстрее
Куда уж быстрее чем в современном Си ?
Вы вообще смотрели как устроены современные аллокаторы ? Например jemalloc. У каждого процессора свой кеш. Выделение памяти — перестановка одного указателя! Причём БЕЗ синхронизации.
А ещё для ваших примитивных типов в Си можно выделить маппинг (один сисколл), объекты внутри выделять одной операцией ADD, а затем "грохнуть" весь пул.
Отлично подходит для разовой работы с огромным числом мелких объектов (например сложный парсинг). Покажете как это можно сделать в PL/x быстрее ?
Здравствуйте, кт, Вы писали:
S>>Это вообще имеет какое то значение в современных условиях для быстродействия? кт>Слухи о том, что быстродействие увеличивать больше не надо, сильно преувеличены
Ты лучше подумай какой пц начнётся если вдруг этот код будет выполняться из разных потоков, когда одному надо так а другому эдак.
А вообще от самомодифицирующегося кода давно отказались по многим причинам.
Здравствуйте, IID, Вы писали:
IID>Куда уж быстрее чем в современном Си ?
Быстрее в ассемблере
IID>Вы вообще смотрели как устроены современные аллокаторы ?
Извините, но это в данной ветке вообще не по теме.
Речь идет о вычислении адресов элементов многомерных массивов через индексы.
Здравствуйте, CreatorCray, Вы писали:
CC>Ты лучше подумай какой пц начнётся если вдруг этот код будет выполняться из разных потоков, когда одному надо так а другому эдак.
Параллельность приходится явно учитывать и во многих других случаях. А если даже параллельности нет, то все равно не смей ничего ускорять?
CC>А вообще от самомодифицирующегося кода давно отказались по многим причинам.
Даже в Лиспе?
Т.е. ответ на заглавный вопрос я получаю в виде: "нет больше таких компиляторов, потому, что так делать нельзя"
Здравствуйте, pagid, Вы писали:
P>У меня есть предположение, что предпочли они его потому как для численных алгоритмов он лучше оптимизировался, более ни для чего он был негоден.
Да, там в основном работали тяжелые числодробилки. И графики надо было строить. Собственно, Фортран использовался для своей предметной области. Но вообще-то на нем и обработку текстов писали. При полном отсутствии в Фортране 4 строковых переменных (они появились только в Фортране 77). На PC Все, чего Фортрану не хваьало, мы на Сях дописали, а я потом все в кучу собрал.
P>Но если бы состояние вычислительной техники заморозилось (не развивалось в сторону персоналок и новых ЯП) в тот момент, то у PL/1 был бы шанс вытеснить его и оттуда.
Напомню, что PL/1 создавался с целью заменить Фортран и Кобол. В СССР он был весьма популярен. На самом деле он собрал все грабли Фортрана и Кобола (а их было немало) и добавил еще своих. Я уж деталей не помню.
Читать его тажело. Особенно когда кто-то применяет сокращенный синтаксис (DCL вместо DECLARE, CTL вместо CONTROLLED и т. д.). Зарезервированных слов нет.
Если я правильно понимаю, в современных платформах (кроме совсем уж мелкого эмбеда) исполняемый код защищён от модификации и даже чтения средствами процессора/операционной системы. Так что вряд ли кто-то сейчас особо парится на эту тему — разве что из академического интереса. Ну и при таком раскладе придётся под досом запускать всё это.
зы: про pl/1 — прямо глаз защипало, перфокарты вспомнились, ЕС-1040, фокусы, примусы, JCL и "устройства быстрой печати"
Здравствуйте, кт, Вы писали:
кт>Вопрос был, известны ли компиляторы, которые меняют сами команды (или операнды команд, как здесь) для реализации динамических массивов
Самомодифицирующийся код в защищенном режиме на x86 сделать штатными средствами нельзя. Кодовый сегмент может быть вообще от чтения защищен. Процессор может только выполнять код. Для чтения его специально открывать надо. Для записи теоретически надо описать этот же сегмент как сегмент данных в новом селекторе. Насколько это сложно на практике, я не знаю. Думаю, разработчикам компиляторов, особенно таких, как PL/1, и без этих выкрутасов есть чем заняться.
P.S. Много лет назад в каком-то журнале предлагали компилятор, умеющий делать код для 32-битового реального режима процессоров 386. У процессора можно было как-то снять ограничение на 64 К размер сегмента. Авторы статьи экономили несколько десятков наносекунд за счет более простой адресации.
x>Если я правильно понимаю, в современных платформах (кроме совсем уж мелкого эмбеда) исполняемый код защищён от модификации и даже чтения средствами процессора/операционной системы.
P>Самомодифицирующийся код в защищенном режиме на x86 сделать штатными средствами нельзя. Кодовый сегмент может быть вообще от чтения защищен. Процессор может только выполнять код. Для чтения его специально открывать надо. Для записи теоретически надо описать этот же сегмент как сегмент данных в новом селекторе. Насколько это сложно на практике, я не знаю.
По мнению этих авторов в статье описан невозможный случай.
Однако для этого в получаемом PE-файле транслятору достаточно лишь дописать флаг W в таблице секций:
Здравствуйте, Privalov, Вы писали:
кт>>Вопрос был, известны ли компиляторы, которые меняют сами команды (или операнды команд, как здесь) для реализации динамических массивов P>Самомодифицирующийся код в защищенном режиме на x86 сделать штатными средствами нельзя.
JIT же в каком-то смысле — код может оптимизироваться (генерятся маш-коды для данных условий), деоптимизироваться (если условия поменялись) и оптимизироваться опять, уже по-другому.
Скажем, в hotspot есть https://wiki.openjdk.java.net/display/HotSpot/RangeCheckElimination ... Правда не уверен, что именно где-то есть именно такие варианты реализации дин-массивов, да и нужны ли они вообще...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, кт, Вы писали:
кт>По мнению этих авторов в статье описан невозможный случай. кт>Однако для этого в получаемом PE-файле транслятору достаточно лишь дописать флаг W в таблице секций:
Точно достаточно? Давно это, конечно, было. Но сдается мне, значения этих флагов для кодового сегмента отличаются от значений для сегмента данных. Вот этот W в случае кодового сегмента разрешает его читать.
Здравствуйте, Privalov, Вы писали:
P>Точно достаточно? Давно это, конечно, было. Но сдается мне, значения этих флагов для кодового сегмента отличаются от значений для сегмента данных. Вот этот W в случае кодового сегмента разрешает его читать.
Key to section flags:
C - contains code
D - discardable
E - executable
I - contains initialized data
P - may not be paged
R - readable
W - writeable
По-моему, Вы не обращаете внимание на заголовки. Там присутствует слово "реализация". Т.е. это все уже сделано и работает.
Здравствуйте, Privalov, Вы писали:
P>Самомодифицирующийся код в защищенном режиме на x86 сделать штатными средствами нельзя.
Можно, легко.
НО! Не нужно!
(Кстати, помимо сисколла для изменения атрибутов страницы, накладными расходами будет сброс TLB для адреса, в который писали, чтобы процессор не исполнял закешированное, а "подхватил" изменения)
P>Кодовый сегмент может быть вообще от чтения защищен.
На интеле такого быть не может.
Потому что битов доступа такие:
(P)resent: 0 — память по этому VA отсутствует, 1 — память присутствует, можно осуществлять трансляцию
(R)ead/(W)rite: 0 — можно только читать, 1 — можно писать
(N)onE(X)ecutable: 0 — можно исполнять, 1 — нельзя исполнять
Здравствуйте, ·, Вы писали:
P>>Самомодифицирующийся код в защищенном режиме на x86 сделать штатными средствами нельзя.
·>JIT же в каком-то смысле — код может оптимизироваться (генерятся маш-коды для данных условий), деоптимизироваться (если условия поменялись) и оптимизироваться опять, уже по-другому.
