PS
Ага, то есть нужен еще чат #comp_arch
Size: a a a
2020 April 07
D
а есть чаты про ЯП в общем?
Есть чат про архитектуру — t.me/oop_ru (на ссылку не смотри)
PS
К компиляторам. Представим, что мы делаем учебный компилятор в машинный код. Как бы вы предложили делать instruction selection из промежуточного IR ?
Но я, кстати говоря, не уточнил, что у Вас за целевое представление. Вдруг, речь о стековой машине, например :)
А
Так давно уже нет глобальной памяти. Это особенно заметно было тем, кто работает в области DSP, HPC... скоро и в настольных применениях будет очевидным :)
Ну сейчас есть. В тех архитектурах, которые широко используются
АЕ
Так давно уже нет глобальной памяти. Это особенно заметно было тем, кто работает в области DSP, HPC... скоро и в настольных применениях будет очевидным :)
Но память же есть. Пусть и не глобальная. А не функции.
А
Ну сейчас есть. В тех архитектурах, которые широко используются
Не совсем глобальная конечно, с поправкой на виртуальную адресацию, но всё же.
MM
> Но в каждом потоке всё вполне последовательно.
Да, при условии что потоки не пишут и не читают общую память, перестановка команд не может влиять на видимый пользователем результат
Да, при условии что потоки не пишут и не читают общую память, перестановка команд не может влиять на видимый пользователем результат
IJ
«Функциональное программирование», наверняка, полезная штука. Я просто отношу его немного к отдельной области знаний.
на императивном И функциональном свет клином не сошёлся. Стилей полно, и между регулярными выражениями, Verilog и SQL общего мало, однако всё это совершенно не академические инструменты.
IJ
Но я, кстати говоря, не уточнил, что у Вас за целевое представление. Вдруг, речь о стековой машине, например :)
я думал в тот момент об x64 :)
PS
Но память же есть. Пусть и не глобальная. А не функции.
Это да. Естественно внутри чипа нет никакого "железного" лямбда-исчисления. Просто общие архитектурные принципы весьма схожи с классическим ФП — локализация эффекта, вычислительные графы с зависимостями по данным...
АЕ
на императивном И функциональном свет клином не сошёлся. Стилей полно, и между регулярными выражениями, Verilog и SQL общего мало, однако всё это совершенно не академические инструменты.
Мне привели пример ФП, и там о другом шла речь, другой тезис. Вы путаете (две ветви разговора).
PS
я думал в тот момент об x64 :)
Кстати, это не отменяет стекового подхода. Только стековая машина будет символической, а результат ее работы — x64-код :) Можно использовать ту же простую идею, которую авторы V8 утянули из работ 80-х по реализации Scheme :)
G
Мне кажется, это очень узкий взгляд который в дальнейшем очень мешает.
+
2020 April 08
λ
IJ
Кстати, это не отменяет стекового подхода. Только стековая машина будет символической, а результат ее работы — x64-код :) Можно использовать ту же простую идею, которую авторы V8 утянули из работ 80-х по реализации Scheme :)
Хм. не уверен, что я правильно понял идею
PS
Хм. не уверен, что я правильно понял идею
Ура! Вопрос по компиляторам! С удовольствием отвечаю! :)
Предположим, что мы уже получили IR в виде кода для стековой машины. Далее можно было бы заняться простейшим видом генерации x64-кода на основе макроподстановки. Основная проблема, однако в том, что работу со стеком придется постоянно имитировать -- то есть получится нечто в духе подпрограммного шитого кода, если говорить в терминах Форта. Ситуацию можно немного улучшить с помощью peephole-замен, но это явно не самое эффективное решение.
С другой стороны, можно было бы представить, что стек у нас виртуальный, на вершине его находятся аппаратные регистры, а далее идут ячейки стековой памяти. Тогда мы могли бы заняться интерпретацией стекового IR таким образом, чтобы при появлении push или pop определять, где у нас реальные операнды и соответствующим образом генерировать целевые команды.
Схожая техника под названием DDCG работает за один проход и хорошо известна в компиляторной Scheme-школе. Вот, в частности, статья на тему от K. Dybvig и др. "Destination-Driven Code Generation": https://pdfs.semanticscholar.org/16f1/89ec98c0a9bd0c672ce14799347fab8b4726.pdf
Но совсем в наглядном варианте подход этот описан в презентации "One-pass Code Generation in V8":
https://github.com/eatonphil/one-pass-code-generation-in-v8/blob/master/One-pass%20Code%20Generation%20in%20V8.pdf
Кроме того, можно посмотреть часть лекции Булычева под названием "Интерпретатор стековой машины с символическим стеком как генератор кода". Я сразу для удобства перемотал до нужного места: https://youtu.be/XFjXmYFu3Ik?t=2958
Предположим, что мы уже получили IR в виде кода для стековой машины. Далее можно было бы заняться простейшим видом генерации x64-кода на основе макроподстановки. Основная проблема, однако в том, что работу со стеком придется постоянно имитировать -- то есть получится нечто в духе подпрограммного шитого кода, если говорить в терминах Форта. Ситуацию можно немного улучшить с помощью peephole-замен, но это явно не самое эффективное решение.
С другой стороны, можно было бы представить, что стек у нас виртуальный, на вершине его находятся аппаратные регистры, а далее идут ячейки стековой памяти. Тогда мы могли бы заняться интерпретацией стекового IR таким образом, чтобы при появлении push или pop определять, где у нас реальные операнды и соответствующим образом генерировать целевые команды.
Схожая техника под названием DDCG работает за один проход и хорошо известна в компиляторной Scheme-школе. Вот, в частности, статья на тему от K. Dybvig и др. "Destination-Driven Code Generation": https://pdfs.semanticscholar.org/16f1/89ec98c0a9bd0c672ce14799347fab8b4726.pdf
Но совсем в наглядном варианте подход этот описан в презентации "One-pass Code Generation in V8":
https://github.com/eatonphil/one-pass-code-generation-in-v8/blob/master/One-pass%20Code%20Generation%20in%20V8.pdf
Кроме того, можно посмотреть часть лекции Булычева под названием "Интерпретатор стековой машины с символическим стеком как генератор кода". Я сразу для удобства перемотал до нужного места: https://youtu.be/XFjXmYFu3Ik?t=2958
IJ
Ура! Вопрос по компиляторам! С удовольствием отвечаю! :)
Предположим, что мы уже получили IR в виде кода для стековой машины. Далее можно было бы заняться простейшим видом генерации x64-кода на основе макроподстановки. Основная проблема, однако в том, что работу со стеком придется постоянно имитировать -- то есть получится нечто в духе подпрограммного шитого кода, если говорить в терминах Форта. Ситуацию можно немного улучшить с помощью peephole-замен, но это явно не самое эффективное решение.
С другой стороны, можно было бы представить, что стек у нас виртуальный, на вершине его находятся аппаратные регистры, а далее идут ячейки стековой памяти. Тогда мы могли бы заняться интерпретацией стекового IR таким образом, чтобы при появлении push или pop определять, где у нас реальные операнды и соответствующим образом генерировать целевые команды.
Схожая техника под названием DDCG работает за один проход и хорошо известна в компиляторной Scheme-школе. Вот, в частности, статья на тему от K. Dybvig и др. "Destination-Driven Code Generation": https://pdfs.semanticscholar.org/16f1/89ec98c0a9bd0c672ce14799347fab8b4726.pdf
Но совсем в наглядном варианте подход этот описан в презентации "One-pass Code Generation in V8":
https://github.com/eatonphil/one-pass-code-generation-in-v8/blob/master/One-pass%20Code%20Generation%20in%20V8.pdf
Кроме того, можно посмотреть часть лекции Булычева под названием "Интерпретатор стековой машины с символическим стеком как генератор кода". Я сразу для удобства перемотал до нужного места: https://youtu.be/XFjXmYFu3Ik?t=2958
Предположим, что мы уже получили IR в виде кода для стековой машины. Далее можно было бы заняться простейшим видом генерации x64-кода на основе макроподстановки. Основная проблема, однако в том, что работу со стеком придется постоянно имитировать -- то есть получится нечто в духе подпрограммного шитого кода, если говорить в терминах Форта. Ситуацию можно немного улучшить с помощью peephole-замен, но это явно не самое эффективное решение.
С другой стороны, можно было бы представить, что стек у нас виртуальный, на вершине его находятся аппаратные регистры, а далее идут ячейки стековой памяти. Тогда мы могли бы заняться интерпретацией стекового IR таким образом, чтобы при появлении push или pop определять, где у нас реальные операнды и соответствующим образом генерировать целевые команды.
Схожая техника под названием DDCG работает за один проход и хорошо известна в компиляторной Scheme-школе. Вот, в частности, статья на тему от K. Dybvig и др. "Destination-Driven Code Generation": https://pdfs.semanticscholar.org/16f1/89ec98c0a9bd0c672ce14799347fab8b4726.pdf
Но совсем в наглядном варианте подход этот описан в презентации "One-pass Code Generation in V8":
https://github.com/eatonphil/one-pass-code-generation-in-v8/blob/master/One-pass%20Code%20Generation%20in%20V8.pdf
Кроме того, можно посмотреть часть лекции Булычева под названием "Интерпретатор стековой машины с символическим стеком как генератор кода". Я сразу для удобства перемотал до нужного места: https://youtu.be/XFjXmYFu3Ik?t=2958
Вот! Теперь понял. Ключевая фраза там для меня — класть в стек расположения операндов, а не их самих. И спасибо за статьи :)
RS
В x86 в качестве стека получится использовать регистры вещественной арифметики или же регистры SSE и другие?
AT
Rifat S
В x86 в качестве стека получится использовать регистры вещественной арифметики или же регистры SSE и другие?
А смысл?
RS
Смысл в том, что будет больше ячеек, к которым очень быстрый доступ, и реже надо будет обращаться к памяти.