The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Прогресс в разработке компилятора для языка Rust на базе GCC, opennews (?), 30-Июн-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


197. "Прогресс в разработке компилятора для языка Rust на базе GCC"  +/–
Сообщение от Мимолеопард (?), 30-Июн-22, 23:27 
Эм, а как бы матчасть выучи.

Фон Неймановская - совместное хранения команд и данных в единой памяти
Гарвардсая - хранилище инструкций и хранилище данных представляют собой разные физические устройства

И все эти закидоны с безопасностью, W^X например, или защиты стека от ROP - именно следствие Неймановской.

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

Ответить | Правка | Наверх | Cообщить модератору

206. "Прогресс в разработке компилятора для языка Rust на базе GCC"  +/–
Сообщение от Аноним (206), 01-Июл-22, 06:33 
Технически никто не мешает в современном x86 сделать два селектора отображающих не пересекающиеся области памяти, у одного поставить разрешение на выполнение, у второго снять.

И всё, считай у тебя будет две независимых памяти, в одной можно выполнять код, в другой нет.

Так не делают из-за кучи легаси которая вся сломается, jit компиляторы, java, вот это всё.

Ответить | Правка | Наверх | Cообщить модератору

220. "Прогресс в разработке компилятора для языка Rust на базе GCC"  +/–
Сообщение от Аноним (-), 01-Июл-22, 10:52 
> Фон Неймановская - совместное хранения команд и данных в единой памяти

Современный x86 разделяет память на память для команд и данных. С точки зрения программиста -- прикладного, системного, ядерного -- разные области памяти нисколько не равноценны. ОС тщательно пытается скрыть эти нюансы и пытается создавать для приложения иллюзию фон неймановскости, но эта иллюзия сохраняется ровно до тех пор, пока ты не попытаешься сделать что-нибудь, для чего требуется фон неймановскость -- самомодифицирующися код, или подгрузить код библиотеки с диска, или даже прокинуть буфер в ядро -- тебе придётся учитывать, что это сильно не бесплатная операция, и в частности потому, что буфер в юзерспейсе и буфер в ядре -- это разные области памяти. Даже если ты создал два маппинга страниц для одного физического блока памяти, то это значит, что переключаясь между ядром и юзерспейсом, процессор будет сбрасывать одни кеши таблиц страниц, и загружать другие, хоть он и работает с одной физической памятью.

Приложено невообразимое количество усилий, чтобы сохранить иллюзию фон неймановскости как своего рода абстракцию, но это leaky абстракция, она течёт как peшeтo. И если ты хоть раз попробуешь сделать на современном железе что-нибудь интересное, ты увидишь это воочию.

Но я бы рекомендовал пойти и получить хорошее образование, потому что твоё явно осталось на уровне 8 класса 80-х годов.

> Да, части процессора используют идеи гарвардской - раздельные кэши, раздельные шины.

Да, и если мы решим что фон неймановскость -- это не о том, как для программиста выглядит, а как оно в железе реализовано, и закопаемся глубже чтобы посмотреть на устройство железа, мы увидим, что типов памяти гораздо больше. Ассоциативная память под кеши, RAM... И гора костылей поддерживающих иллюзию фон неймановскости. И эта абстракция не менее leaky чем софтварная.

> И все эти закидоны с безопасностью, W^X например, или защиты стека от ROP - именно следствие Неймановской.

Да, исправление фон неймановской архитектуры с целью повышения надёжности, багоустойчивости системы.

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

240. "Прогресс в разработке компилятора для языка Rust на базе GCC"  +/–
Сообщение от Аноним (-), 01-Июл-22, 21:56 
> Современный x86 разделяет память на память для команд и данных. С точки
> зрения программиста -- прикладного, системного, ядерного -- разные области памяти нисколько
> не равноценны. ОС тщательно пытается скрыть эти нюансы

1) Это не только ОС пытается.
2) Изначально таки равноценны.
3) Кто и какие права в MMU страницам прописывает это вообще к нейман vs гарвард не относится напрямую.


> и пытается создавать для приложения иллюзию фон неймановскости,

Все проще. В современном железе до людей дошло что логически оно должно быть нейманом а физически гарвардом. Т.е. деление на I-bus и D-bus (а также соотв кеши у жирдяев) как бы есть и они как бы параллельно могут ворочаться и так быстрее, но логически при программировании мы это обычно не видим, кроме каких-то сильно специальных случаев.

> фон неймановскость -- самомодифицирующися код,

С этим не было бы никаких проблем - если бы не соображения systems security которые нынче так то диктуют правило W^X из соображений зарубания потуг эксплойтов на корню. Но это чисто конфигурационные вопросы на тему того какие права в MMU страницам прописаны.

> или подгрузить код библиотеки с диска, или даже прокинуть буфер в ядро --

При взаимодействии с ядром надо понимать что адресное пространство процесса и ядра просто разные. Также есть виртуальная память и физическая, и это 2 большие разницы. Но к нейман vs гарвард это не относится. Более того mmap() в лине даже можно конкретный регион физической памяти отмаппить, конечно только от рута, и без lockdown'а, ибо ведет к полному поимению системы.

> в юзерспейсе и буфер в ядре -- это разные области памяти.

А современные шустрые zerocopy интерфейсы и оптимизации про это в курсе? Другое дело что там куча проверок и правами MMU конечно же порубано. Однако, операции, вот, удешевили. Вплоть до zerocopy.

> peшeтo. И если ты хоть раз попробуешь сделать на современном железе
> что-нибудь интересное, ты увидишь это воочию.

Вообще это довольно нормальная абстракция, если не лезть в очень сильные дебри. Обращение к физическому адресу 0x100500 это именно оно, и только так. Какие права там в MMU и не прилетит ли за это в тыкву - вопрос номер два.

> костылей поддерживающих иллюзию фон неймановскости. И эта абстракция не менее leaky
> чем софтварная.

Это попытка и рыбку съесть (не иметь гребли с гарвардом) и косточкой не подавиться (одновременно гонять инструкции и данные для них).

> Да, исправление фон неймановской архитектуры с целью повышения надёжности, багоустойчивости
> системы.

Однако это лишь настройки MMU
// я другой анон если что

Ответить | Правка | Наверх | Cообщить модератору

241. "Прогресс в разработке компилятора для языка Rust на базе GCC"  +/–
Сообщение от Аноним (-), 01-Июл-22, 23:09 
> 1) Это не только ОС пытается.

Естественно, совместные усилия процессора и софта. Так конфигурабельнее, чем железно прошивать что-то неизменяемое.

> 2) Изначально таки равноценны.

Да, на одних и тех же физических законах работают. Или ты про то, что они сделаны на транзисторах?

> 3) Кто и какие права в MMU страницам прописывает это вообще к нейман vs гарвард не относится напрямую.

Если ты задашься вопросом зачем придумали такие абстракции как "нейман" и "гарвард", а потом это "зачем" применишь к современности, то ты увидишь, что они сегодня элементарно не работают, не выполняют своих функций. Бывают MCU или недо-процы которые следуют нейману или гарварду, но все топовые процессоры давно такие гибриды всех всевозможных идей из прошлого, что классификациями из XX века можно подтереться.

Так же как и с языками программирования. Нам достались некоторые языки из прошлого, которые чисто императивны, или функциональны, или декларативны, или интерпретируемы, или ещё что. Но все языки XXI века не вписываются ни в одну парадигму, потому что тащат из всех парадигм то, что им удобно, и отбрасывают то, что не удобно.

> Это попытка и рыбку съесть (не иметь гребли с гарвардом) и косточкой не подавиться (одновременно гонять инструкции и данные для них).

Да, именно. Инженеры прагматичные люди, и когда академики наморщив лоб предлагают какую-нибудь классификацию процессоров, инженеры следуют ей только тогда, когда это удобно. И подтираются ею, когда прагматичнее сделать иначе. Все классификации академиков чем-то напоминают закон Мура: они работают, пока они работают, а потом они перестают работать. Есть некоторые фундаментальные, скажем периодическая таблица Менделеева: её пришлось немного допилить, когда выяснилось что тупо по массе сортировать нестоит, потому что у атомов одного элемента может быть разная масса. Но таблица пережила перепиливание, и пока выглядит так, что она _фундаментальна_, она описывает фундаментальный закон Вселенной. Но большинство классификаций не фундаментальны, а просто кто-то очень умничал, пытался набить себе публикаций, получить PhD, или профессуру.

> А современные шустрые zerocopy интерфейсы и оптимизации про это в курсе?

Это и на i386 можно было. Создать отмапить память процесса на память ядра, и вот ядро может читать. Но оно не меняет того, что тебе приходится проводить кучу манипуляций для того, чтобы добраться до какого-то куска памяти.

Вот если проц на гарвардской архитектуре будет позволять, совершая определённые ритуалы, писать в программную память или читать оттуда -- будет ли это нарушением гарвардской архитектуры? Реально существуют MCU на гарвардской архитектуре которые могут перепрошивать сами себя, но для этого их распаять надо специальным образом (те о которых я знаю, по-крайней мере требуют специальной распайки). Насколько простыми должны быть эти ритуалы перепрошивки себя, чтобы они делали бы из гарвардской архитектуры фон-неймановскую?

> Более того mmap() в лине даже можно конкретный регион физической памяти отмаппить

И что? Если бы у тебя все адреса были бы равноценны, тебе бы не пришлось сношаться с mmap'ом.

> Обращение к физическому адресу 0x100500 это именно оно, и только так.

Когда ты в последний раз обращался к физическому адресу 0x100500? Ты можешь привести реалистичный пример программки на C, которая будет делать что-то типа *(unsigned char*)0x100500, и при этом обращаться именно к физическому адресу 0x100500?

Никто не обращается к физическим адресам, все давным-давно работают с виртуальными. Только mm в ядре парится о физических адресах, чтобы таблицы страниц правильно заполнять.

> Однако это лишь настройки MMU

И что? Если ты упомянул "умную" аббревиатуру, то "это" перестало существовать?

Я ещё раз говорю, только самые позорные прикладники, которые не парятся оптимизацией от слова совсем, могут пребывать в иллюзии фон-неймановскости. Наверное, это можно сформулировать и так, как ты это формулируешь:

> Вообще это довольно нормальная абстракция, если не лезть в очень сильные дебри.

Все кроме этих позорных прикладников вынуждены думать о стопке всё более медленных слоёв памяти в цепочке регистры-L1-...-LN-RAM-SSD/HDD/TAPE. Им приходится учитывать нюансы работы этих слоёв, хотя бы с точностью до порядка представлять себе объёмы этих слоёв. Им приходится думать о том, как быстро прокидывать данные между процессами, между юзерспейсом и ядром. Они никуда не денутся от всех этих проблем. А раз так, то какой смысл называть эту мешанину фон-Нейманом? Или я могу поставить этот вопрос иначе: насколько надо ещё эту мешанину усложнить, чтобы наконец признать, что это уже не фон-Нейман?

У меня складывается ощущение, что ты считаешь, что ежели ядерный MM отлить в железе, то тогда это будет уже не фон-Нейман. Но ты понимаешь ведь, что никто в здравом уме годов с 70/80 такую сложность не отливает в железе? Такие сложности делаются софтварно. 8086 содержал микрокод, то есть множество программок, на каждую инструкцию по программке. В 8086 микрокод был прошит навсегда, но в более поздних процессорах его можно менять. Почему? Потомучто: а) слишком сложно в железе это делать, б) никаких транзисторов не хватит, и в) софтварное решение проблем гораздо гибче, настраиваемее.

Ответить | Правка | Наверх | Cообщить модератору

245. "Прогресс в разработке компилятора для языка Rust на базе GCC"  +1 +/–
Сообщение от Аноним (-), 02-Июл-22, 01:19 
> Естественно, совместные усилия процессора и софта. Так конфигурабельнее,
> чем железно прошивать что-то неизменяемое.

Ну да. А гарвард в классическом его понимании как раз полный брейнфак. Кто сомневается, может попробовать AVR прогать на сях, повозиться с указателями и познать масштаб грабель. Вот именно чистый гарвард, когда он настолько полный что и в программную модель вылез, это булшит все же. Си, да и сабж наверное не заточены на такое сами по себе.

> Да, на одних и тех же физических законах работают. Или ты про
> то, что они сделаны на транзисторах?

Я про то что поход на адрес 100500 это поход на адрес 100500, и будет ли он I-bus или D-bus сделан в принципе не проблема програмера, в 99.9(9)% даже может не задумываться над этим. В этом смысле современные железки чаще "логический нейман". А то что физически оно гарвард... прогеру обычно не видно. Только в каких-то глубоко системных операциях. Ну там early init когда I-cache и/или D-cache хотим как SRAM использовать за отсутствием DRAM, тут может начать интересовать.

Более детально в Cortex M видно: Cortex M0 нейман целиком (1 шина на все, 1 адреса). А M3 и жирнее уже нейман в логике, но I-bus и D-bus уже разные в физике, и так ессно быстрее при прочих равных. Но программная модель - нейман и от M0 в этом аспекте вообще отличия найти сложно.

> Если ты задашься вопросом зачем придумали такие абстракции как "нейман" и "гарвард",
> а потом это "зачем" применишь к современности, то ты увидишь, что
> они сегодня элементарно не работают, не выполняют своих функций.

Я их условно разделил на "логический" и "физический" уровни. Так вроде катит. Ну то-есть если есть I-bus и D-bus, то физически гарвард, но логически может нейманом выглядеть, чтобы не делать мозг пространствами.

> классификацию процессоров, инженеры следуют ей только тогда, когда это удобно.

В случае RISC vs CISC все еще интереснее.

> Но таблица пережила перепиливание, и пока выглядит так, что она _фундаментальна_,

А вон вам для гарвард vs нейман "с дополнениями". Разделим логику и физику, так вроде недурно классифицирует все что на глаза попадалось.

> она описывает фундаментальный закон Вселенной. Но большинство классификаций
> не фундаментальны,

Вообще, 1 шина на все vs I-Bus + D-Bus достаточно фундаментальное деление вроде. Во что это трансформируется в софте - отдельный вопрос.

> что тебе приходится проводить кучу манипуляций для того, чтобы добраться до
> какого-то куска памяти.

Сейчас штуки типа линуха сделали подобные вещи достаточно lightweight. Конечно переключение контекста при желании отдать что-то ядру будет, и это не совсем халява. Но именно копиривания все же нету, потому и zerocopy. И сишные указатели за что-то такое все любят.

> Вот если проц на гарвардской архитектуре будет позволять, совершая определённые ритуалы,
> писать в программную память или читать оттуда -- будет ли это
> нарушением гарвардской архитектуры?

Ну, посмотрите на AVR. На си это мапится ушлепански. В gcc ведет к указателям которые как бы выглядят одинаково но не эквивалентны. Реально SRAM и FLASH натурально 2 разные пространства. В чем трабл? А в том что они не взаимозаменяемы и много нестандартных особенностей.

> Реально существуют MCU на гарвардской архитектуре которые могут перепрошивать сами себя,

Ну вот конкретно в AVR это отливается в то что оно не может извне вгрузить модуль в RAM. То-есть налить то код туда можно, но выполнить его - болт. В этом месте кортексы имеют нефиговый плюс. Даже если оно M3, вот так к SRAM bus matrix цепляет I, а вот так D, так что можно и код и данные.

> распайки). Насколько простыми должны быть эти ритуалы перепрошивки себя, чтобы они
> делали бы из гарвардской архитектуры фон-неймановскую?

Ну вон для "истинного гарварда" AVR подобное временами ведет к брейнфаку. Фокус в том что при записи флеш "временно недоступен" и в лучшем случае его контроллер держит шину и исполнение паузится на весьма ощутимое время в течение которого чип совершенно недееспособен. Хуже если не паузится :). А ежели код в SRAM выполняется, он при записи флеша живой и веселый, если не сунется в занятый флеш сдуру.

> И что? Если бы у тебя все адреса были бы равноценны, тебе
> бы не пришлось сношаться с mmap'ом.

Это требуется в основном из-за многозадачности. Каждому процессу кажут свое адресное пространство, полного размера. Он по нему может как правило целиком шариться (получит SIGSEGV за некоторые вещи). Очевидно физический лэйаут памяти не может совпадать 1 в 1 с этим. Иначе все процессы будут видеть всех, и внутренности ядра, отстой по безопасности. Но это другая абстракция, не особо связаная с гарвардом и нейманом, это "виртуальная память". В системе с VM и paging имеет смысл операция "memory mapping". Она отображает физические адреса в логические. Если бы мне не пришлось сношаться с mmap, я мог бы полностью перехватить контроль над системой, ибо некоторые физические регионы памяти это вообще железо. И я ммапал чтобы в регистры железки сходить "бех драйвера ядра" так то. Это вообще делать не стоит без понимания почему это может прокатить: прямой доступ таким манером рушит допущения многозадачки, при этом нет никакого арбитража доступа разных процессов и ядра и можно на этом нехило налететь.

> Когда ты в последний раз обращался к физическому адресу 0x100500?

Не так уж давно, а что?

> Ты можешь привести реалистичный пример программки на C, которая будет делать что-то типа
> *(unsigned char*)0x100500, и при этом обращаться именно к физическому адресу 0x100500?

Бутром из STM сдампил, характерной фичой "dumpblock(addr, len)" берущей на вход - только подумайте - лобовой адрес "чего дампим". Любой из 2^32 (оно 32-битное).

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

> Никто не обращается к физическим адресам, все давным-давно работают с виртуальными. Только
> mm в ядре парится о физических адресах, чтобы таблицы страниц правильно заполнять.

Ок, так круто за всех сишников говорить... только вот вся работа с железом например это работа с конкретными физическими адресами. Оно за mem-mapped, потому что это просто, быстро, хорошо работает, удобно сям.

> И что? Если ты упомянул "умную" аббревиатуру, то "это" перестало существовать?

Я лишь имел в виду что к гарварду MMU вообще ортогонален. И по логике вещей у "полного" гарвардца должно быть их минимум два: на I-адресацию и D-адресацию. Так то еще IOMMU бывает, но он про чуть иное: постановку железок в стойло. DMA так то тоже оперирует лобовыми адресами, физическими. И это не только позволяет железке полностью отыметь систему, но и к тому же ведет к очень интересным эффектам если железку в виртуалку пробросить. Там у драйвера свои идеи насчет адресов, только вот с хостом это не совпадает и когда железка запроганая драйвером в guest сделает именно вот туда DMA... :)))

> сформулировать и так, как ты это формулируешь:
>> Вообще это довольно нормальная абстракция, если не лезть в очень сильные дебри.

Я разделяю как минимум логическое представление и физическую реализацию. И да, вы верно заметили что возможны гибриды когда в логике нейман, а в физике гарвард.

> Все кроме этих позорных прикладников вынуждены думать о стопке всё более медленных
> слоёв памяти в цепочке регистры-L1-...-LN-RAM-SSD/HDD/TAPE.

HDD и TAPE как правило не адресуемы как адреса памяти. Хотя mmaped файлы в случае HDD как частный случай могут немного поспорить с этим.

> насколько надо ещё эту мешанину усложнить, чтобы наконец признать, что это
> уже не фон-Нейман?

Со своей стороны я считаю логическим нейманом ежели все адреса в адресном пространстве дереференсятся одинаково. А если надо адресные пространства учитывать, это уже логический гарвард. Заметьте, физическая реализация тут не фигурирует.

> У меня складывается ощущение, что ты считаешь, что ежели ядерный MM отлить
> в железе, то тогда это будет уже не фон-Нейман.

Для меня ответ на этот вопрос в контексте "логический нейман vs логический гарвард" будет зависеть от того греет ли програмер мозг отдельными адресными пространствами.

> сложность не отливает в железе? Такие сложности делаются софтварно.

Вообще-то программно-аппаратно. Совсем софтварно это малореализуемо и тормозно и требует очень явной поддержки именно железом. Как то paging и MMU. И вот этот паттерн многие собезьянили.

> микрокод, то есть множество программок, на каждую инструкцию по программке.

Не на каждую IIRC. Только на сложные. Это такой способ компрессии потока команд а потом и некая абстракция логического апи наружу от физической реализации. Внутри современнй x86 совсем не то что снаружи.

> можно менять. Почему? Потомучто: а) слишком сложно в железе это делать,

Вообще-то там в проце дефолтный uCode ROM защит. Просто его можно оверрайдить загружаемым, это после ряда увесистых багов в процах подгорело. Но uCode ROM это специфика махровых CISC. У большей части RISC его вообще нет, это одна из довольно четких границ водораздела RISC vs CISC.

> б) никаких транзисторов не хватит, и в) софтварное решение проблем гораздо
> гибче, настраиваемее.

Оно таки не полностью софтварное. Да и вообще uCode ROM заменили на uCode SRAM. И некие дефолты там есть, без него CISC вообще свой набор команд не могет выполнять по идее. Как минимум сложные операции, разбиваемые на микрооперации. RISC на самом базовом уровне отличается тем что операции простые и не бьются на более мелкие микрооперации секвенмируемые uCode ROM. И таки это делает процессорное ядро проще и меньше при прочих равных.

Ответить | Правка | Наверх | Cообщить модератору

251. "Прогресс в разработке компилятора для языка Rust на базе GCC"  +/–
Сообщение от Аноним (-), 02-Июл-22, 08:38 
>> Если ты задашься вопросом зачем придумали такие абстракции как "нейман" и "гарвард",
>> а потом это "зачем" применишь к современности, то ты увидишь, что
>> они сегодня элементарно не работают, не выполняют своих функций.
> Я их условно разделил на "логический" и "физический" уровни. Так вроде катит. Ну то-есть если есть I-bus и D-bus, то физически гарвард, но логически может нейманом выглядеть, чтобы не делать мозг пространствами.

Как ты интересно проигнорировал вопрос. Если глянуть на https://en.wikipedia.org/wiki/Von_Neumann_architecture#Desig... то там показано, что современная архитектура нихрена не фон-нейман, даже схемка нарисована, для сравнения с той, что в начале статьи. Но если бы ты не игнорировал вопрос, а вот в той же статье на википедии почитал бы раздел History, то увидел бы, что фон Нейман рассуждал о том, как было бы хорошо, если бы компьютеры не прошивались бы один раз и навсегда, а могли бы модифицировать код, и в этом смысле современные процессоры можно рассматривать как развитие архитектуры -- идея та же, но дополненная многими другими.

Правда вопрос о том, зачем сегодня могут быть нужны абстракции "фон нейман" и "гарвард", остаётся висеть в воздухе. А это ведь ключевой вопрос, так? Ты как инженер (ты ведь инженер?) должен понимать это? Это же базовое мышление инженера, которое прививается ему на первом курсе. Мы сначала берём задачу (то самое "зачем"), затем формулируем требования к решению (в данном случае, этими требованиями будут критерии принадлежности двух архитектур к одному или разным классам), после этого создаём решение этой задачи (в данном случае классификацию архитектур). Если у тебя нет задачи, и ты классифицируешь ради классификации, то это болезнь.

> Да и вообще uCode ROM заменили на uCode SRAM. И некие дефолты там есть, без него CISC вообще свой набор команд не могет выполнять по идее. Как минимум сложные операции, разбиваемые на микрооперации. RISC на самом базовом уровне отличается тем что операции простые и не бьются на более мелкие микрооперации секвенмируемые uCode ROM. И таки это делает процессорное ядро проще и меньше при прочих равных.

Садись, пять.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру