Что не хватает Форту?

 
1 9 10 11 12 13 14 15
+
-
edit
 

Veden12

втянувшийся
Gudleifr> А, с другой стороны, вот все плохо и кончилось... Любой прорыв заканчивался переуступкой прав и закрытием проекта в пользу маркетоидов. Где Canon Cat, NeXT, Радио-86РК..?
Наверное, в это трудно поверить, но идеи Раскина живут и побеждают. А Радио-86РК просто стал 64-битным :)
Gudleifr> ИМХО, нужно не просто что-то делать, но и вовремя отрезать труднореализуемые в домашних условиях фичи, регулярно выкладывая остальное на всеобщее обозрение.
Создал страничку. Заготовку Форт-системы выложу позже. Интерпретатор для авто-генерации. Пока не реализованы KEY и EMIT, но их всегда можно взять из UEFI. Я же пока мучаю железо :)
 33.0.1750.14633.0.1750.146
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Создал страничку...
Здорово! Но надо добавить немножко мотивационной инфы. Чтобы сначала слюнки потекли, а уже потом - голая правда жизни. Не картинок, и не блогов, но интима и доверительности. (Раньше классики вводили, например, вымышленных персонажей и вели диалоги. Я тоже пытался, но, поскольку не Платон, это было слишком похоже на шизофрению).
 27.027.0
+
-
edit
 

Veden12

втянувшийся
Veden12>> Создал страничку...
Gudleifr> Здорово! Но надо добавить немножко мотивационной инфы. Чтобы сначала слюнки потекли, а уже потом - голая правда жизни. Не картинок, и не блогов, но интима и доверительности.
Подумаю над этим. Беда в том, что я не представляю себе всю целевую аудиторию. Тех, кто помнит К580, я понимаю. Но Форт сегодня? Робототехника?...
Gudleifr> (Раньше классики вводили, например, вымышленных персонажей и вели диалоги. Я тоже пытался, но, поскольку не Платон, это было слишком похоже на шизофрению).
Форт в диалогах? Интересная идея. Спасибо. Жаль, нет опыта преподавания Форт-концепции. Кроме того, как я убедился, для меня наиболее значимы одни стороны Форта, для Вас – другие, для кого-то – третьи... Собрать всё в вводной будет непросто. Но попробую.
 33.0.1750.14633.0.1750.146
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Кроме того, как я убедился, для меня наиболее значимы одни стороны Форта, для Вас - другие, для кого-то - третьи...
Отсюда и диалоги.

Например, для меня FORTH - звено в цепочке A-F-P. И поэтому мне кажется, что начинать работу без надобности в P бессмысленно. А Вас подкупила простота реализации участка A-F? Тогда, наверное, надо отделить, что откуда:
1. Что в Вашем FORTH от "универсального стандарта", без которого "не поймут-с"?
2. Что от возможностей-потребностей железа?
3. Что зависит только от предпочтений программиста?

Например, фраза: "Долой сегменты!",- от (1), (2) или (3)?

P.S. Нашел раздел "Монитор", часть вопросов отпала. В том же стиле надо, наверное, и остальные.
 27.027.0
Это сообщение редактировалось 15.03.2014 в 01:14

Kopa

новичок

Veden12> Форт в диалогах? Интересная идея. Спасибо. Жаль, нет опыта преподавания Форт-концепции.
Может что то в подобном варианте Дневник изучения Форта
Правда у новичка и "опытного" пользователя Форт "грабли" свои.
 
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Например, для меня FORTH - звено в цепочке A-F-P.
Для меня Форт – конструктор подходящего языка, необходимый при отсутствии такового. Похоже, это как раз общий момент.
Gudleifr> И поэтому мне кажется, что начинать работу без надобности в P бессмысленно.
Одно из двух ключевых отличий: я считаю, что Форт-система должна расширяться исключительно во время разработки, но никак не во время эксплуатации; кроме того, Форт должен быть написан на ассемблере (вовсе не исключая при этом расширения набора базовых слов в процессе разработки), но сам его при этом не поддерживать.
Gudleifr> А Вас подкупила простота реализации участка A-F?
Второе ключевое отличие – важность оптимизации. Человеческой, а ни в коем случае не автоматической. Как я понимаю, Форт (или язык, порождаемый им) может быть более быстрым, компактным и понятным, чем ассемблер – во всяком случае, пока программы пишут люди. Просто надо всегда представлять себе, во что это выльется при выполнении, хотя бы ориентировочно. И при необходимости не откладывая расширять лексиконы кодовыми, а не шитыми словами. Не злоупотребляя, впрочем.

Gudleifr> Тогда, наверное, надо отделить, что откуда:
Gudleifr> 1. Что в Вашем FORTH от "универсального стандарта", без которого "не поймут-с"?
Основа FORTH-83, арифметика и ещё несколько слов FORTH-94.
Gudleifr> 2. Что от возможностей-потребностей железа?
Почти всё остальное.
Gudleifr> 3. Что зависит только от предпочтений программиста?
Операции со строками – точно сюда. Плюс общая неинтерактивность.
Gudleifr> Например, фраза: "Долой сегменты!",- от (1), (2) или (3)?
У сегментов есть два аспекта: с одной стороны, они появились в x86 из-за проблем с адресацией и в этом качестве – лишний тормоз для любой программы; с другой стороны, они ссылаются на дескрипторы, обеспечивающие аппаратную защиту участков памяти и вот эту защиту памяти я считаю совершенно не нужной по причине отказа от расширения целевого языка иначе чем на нём самом (мой выбор).

P.S. Добавил исходники.
 33.0.1750.14633.0.1750.146

Veden12

втянувшийся
Kopa> Может что то в подобном варианте Дневник изучения Форта
Очень хорошо и доходчиво написано. О там как "помогает" знание Си в освоении Форта. Проклятие ассоцативной памяти... :)

Мне ничуть не хочется сравнивать разные языки программирования. Я сознаю, что каждый из них, помимо очевидного технологического набора достоинств и недостатков, неразравно связан с рядом исторических и психологических (нередко социальных) причин, вызвавших их появление. Считаю, что все они имеют своё право на существование и, безусловно, полезны.

Есть ряд задач, при решении которых я не колеб** буду использовать Java или Visual Basic. Для игры Жизнь я подходящего языка не знаю, поэтому, как мне кажется, наиболее правильно тут построить на Форте (тут он как нельзя кстати) соответствующий лаконичный язык и организовать Жизнь уже на нём.

Такого рода примеры были бы полезны, но их детальная проработка – дело долгое и непростое. Со временем попробую прикрутить форум, но пока, признаться, не до этого.
 33.0.1750.14633.0.1750.146
Это сообщение редактировалось 15.03.2014 в 15:23
+
-
edit
 

Gudleifr

втянувшийся

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

Veden12> У сегментов есть два аспекта
О втором пока замнем - пока к Вам не пришли суровые дядьки в погонах с предписанием мандатности и дискреционности...
А первый аспект дает целых два удобства:
1. 16-разрядность настолько компактна, что 64К кода хватает для любого нормального процесса.
2. Автоматом получаем перемещаемость кода и удобство его разбиения-организации.
Но, это так, между делом...
 27.027.0
Это сообщение редактировалось 15.03.2014 в 16:43

Kopa

новичок

Veden12>Basic. Для игры Жизнь я подходящего языка не знаю, поэтому, как мне кажется, наиболее правильно тут построить на Форте (тут он как нельзя кстати) соответствующий лаконичный язык и организовать Жизнь уже на нём.
А так почти и поступили когда потребовался язык для "игры" жизнь. :)
В проекте Cam-8Машина клеточных автоматов с Форто-подобным языком и своей спецификой.
 

Gudleifr

втянувшийся

Veden12>>В Cam-8 Машина клеточных автоматов с Форто-подобным языком и своей спецификой.
Это Вы про Тоффоли, Маргулис "Машины клеточных автоматов"? Там никакого "языка" нет и в помине. Аппаратная реализация универсального клеточного автомата и FORTH-затычка (последняя именно в силу того, что никакого "клеточного языка" придумать не удалось). Правда, в книге описан Cam-6. Может, Cam-8 умнее?
И, разумеется, к языкам, порождаемым многочисленными попытками оптимизировать Конвея, это отношения не имеет.
 27.027.0
Это сообщение редактировалось 15.03.2014 в 18:59
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Отмечу только, что, исторически, одна из важнейших составляющих FORTH - его "мониторность". Т.е. способность работатать в нем без "выхода наружу".
Я не отказываюсь от этого. Более того, отладчик ‐ ближайшая задача. С демонстрацией стека в реальном времени, как положено. Я лишь считаю, что этому совершенно не место в законченном приложении. А в процессе разработки ‐ да, обязательно. Более того, я не исключаю существование приложений, разработка которых никогда не заканчивается. Почему бы и нет? То, что я не хочу их создавать, не мешает их создавать другим.
Gudleifr> С этой точки зрения возможность что-то "доассемблировать по месту" в течение сеанса достаточно удобна (и проще для освоения неофитами).
Я считаю, что разработка кодовых слов должна быть завершена до запуска приложения (но не до начала разработки). Конечно же, это требование лишь для моей разработки. Не более того.

Gudleifr> 1. 16-разрядность настолько компактна, что 64К кода хватает для любого нормального процесса.
Процессор x86-64 в 64-битном режиме помимо обычных имеет ещё восемь регистров общего назначения (R8..R15), недоступных в 16-битном и 32-битных режимах. От этого трудно отказаться. Не случайно UEFI работает в этом режиме и в этом же режиме выполняет свои (или Ваши) приложения.
Gudleifr> 2. Автоматом получаем перемещаемость кода и удобство его разбиения-организации.
Мне кажется, что в задачах, где это могло быть удобно, накладные расходы, связанные с использование сегментов, делает это неудобным. И в первую очередь благодаря тому, что сегодня практически вся адресация в программе – относительная. Так что под перемещаемостью кода остаётся лишь понимать перемещаемость данных. Но в 64-битном режиме абсолютная адресация не поддерживается вовсе.

P.S. Разместил на страничке ссылку на обычную, в общем-то, историю необычного человека. Иначе и правда непонятно выходит.
 33.0.1750.14633.0.1750.146
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Но в 64-битном режиме абсолютная адресация не поддерживается вовсе.
Меня давно терзают смутные сомнения: что с переходом на 64-бита, FORTH, рассматриваемый как упрощенная практическая реализация Муром теоретической машины Дейкстры, устарел. И надо начинать думать заново.
 27.027.0
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Меня давно терзают смутные сомнения: что с переходом на 64-бита, FORTH, рассматриваемый как упрощенная практическая реализация Муром теоретической машины Дейкстры, устарел.
Я думаю, переход на 64 бита ничего не меняет. А вот матричные процессоры – это уже серьёзно.
Gudleifr> И надо начинать думать заново.
Альтернатива Форту – вера в божественный компилятор, всё решающий за нас.
 33.0.1750.14633.0.1750.146
Это сообщение редактировалось 15.03.2014 в 23:47
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Я думаю, переход на 64 бита ничего не меняет.
Требуется пересмотреть роль стека (он, естественно, должен сохранить свою FORTH-роль входного буфера, но для вычислений уже не нужен) ввиду наличия большого количества регистров. Адресная арифметика выглядит совершенно по другому из-за перехода на относительную адресацию. Обмен мусором (только 1/4 слова несет полезную нагрузку) напрягает. По-моему, достаточно, чтобы вместо заплаток перейти к переосмыслению.

Veden12> Альтернатива Форту - вера в божественный компилятор, всё решающий за нас.
Критерий сложности программ нам как раз и говорит: в момент написания какого-либо фрагмента мы верим, что остальные фрагменты делают то, что надо. Какая разница, верить в компилятор или в ядро FORTH? Чисто количественная - посмотреть листинг ядра проще, чем код Си-программы на промежуточном языке ассемблера. FORTH только отодвигает границу сложности, но не решает проблему веры.
 27.027.0
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Требуется пересмотреть роль стека (он, естественно, должен сохранить свою FORTH-роль входного буфера, но для вычислений уже не нужен) ввиду наличия большого количества регистров.
Сделав этот первый шаг мы окажемся перед необходимостью сделать и второй шаг – программно реализовать механизм предсказания ветвлений. Ядра обычного потокового процессора слошком инертны для параллельной предвыборки, придётся использовать матричный процессор.
Gudleifr> Адресная арифметика выглядит совершенно по другому из-за перехода на относительную адресацию.
Похоже, я неудачно выразился. Не поддерживается прямая адресация, нет команд MOV RAX,[адрес64бита]. Но можно этот адрес сперва загрузить в регистр (косвенная адресация): MOV RAX,[RBX] работает по-прежнему. Можно и MOV RAX,[адрес32бита] или MOV RAX,[RBX ± смещение32бита]. Это что-то меняет?
Gudleifr> Обмен мусором (только 1/4 слова несет полезную нагрузку) напрягает. По-моему, достаточно, чтобы вместо заплаток перейти к переосмыслению.
Байт-код?
Мне кажется, оптимизация по скорости намного важнее оптимизации по объёму. Сейчас у меня размер полученного шитого кода примерно равен объёму полезного исходного текста. Массивы данных (не учитывал) могут быть очень компактными.
Veden12>> Альтернатива Форту - вера в божественный компилятор, всё решающий за нас.
Gudleifr> Критерий сложности программ нам как раз и говорит: в момент написания какого-либо фрагмента мы верим, что остальные фрагменты делают то, что надо.
Верим или знаем?
Gudleifr> Какая разница, верить в компилятор или в ядро FORTH?
Зачем мне верить в ядро, если я совершенно точно знаю, что инструкция или набор инструкций A при таких-то исходных данных работает намного быстрее, чем инструкция или набор инструкций B, а при других исходных данных – всё наоборот и это ещё слабо сказано?
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Сделав этот первый шаг... Это что-то меняет?
Если мы идем поперек ожиданий процессора, то какая выгода от нашей оптимизации? Ведь скорость железа растет и будет расти для "основного" набора команд, а мы все ищем "альтернативные" лазейки.

Veden12> Верим или знаем?.. я совершенно точно знаю...
"Знать" можно только для несложных (т.е. обозримых человеком) программ. Я, например, неоднократно сталкивался с тем, что какая-то работа делалась еще раз потому, что за прошедшее время все забывали, что уже сделали ее раньше.

P.S. К слову, не убежден, что Раскин во всем был прав в интерфейсах. Мои предъявы Раскину (там в середине).
 27.027.0
Это сообщение редактировалось 16.03.2014 в 19:05
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Если мы идем поперек ожиданий процессора, то какая выгода от нашей оптимизации?
Бесспорно, никакой. Я лишь пытаюсь понять, как такая адресация скажется на Форте. Пока не получается.

Gudleifr> "Знать" можно только для несложных (т.е. обозримых человеком) программ.
Прав был Лем: "плоды веры непредсказуемы".
Форт – штучная работа. Стандартные компиляторы, библиотеки, драйверы от производителя – серийное производство. Вопрос личной ответственности, на который история давно дала свой ответ.

Gudleifr> P.S. К слову, не убежден, что Раскин во всем был прав в интерфейсах.
Согласен. Идея фрактально-географического размещение информации на мониторе ставит приоритет подачи данных выше приоритета потребностей (и удобства) пользователей. Давно убедился: по эффективности обобщённым интерфейсам до частных – как до луны.
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Форт - штучная работа. Стандартные компиляторы, библиотеки, драйверы от производителя - серийное производство.
Ну, не только серийное, но и общественное. История давно дала свой ответ о роли кустарей в производстве.
Я даже считаю, что в мире Linux FORTH, понимаемый только как средство сделать все самому, нафиг не нужен. 'nix-средства позволяют создать свой прикладной язык быстрее и удобнее. С любой степенью ручной оптимизации.
 3.63.6
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Я даже считаю, что в мире Linux FORTH, понимаемый только как средство сделать все самому, нафиг не нужен.
Думаю, в том мире, что мы знаем, нет места Форту. Разве что отдельные ниши, где оптимизация роли не играет. Мне интересно вот что. Если под BIOS были бы драйверы для любого железа и далеко не начального уровня, кто бы стал связываться с существующими ОС? А если бы вскоре появилось что-то вроде сегодняшних конструкторов игр, интегрирующих это хозяйство? У меня совсем другие задачи. Но всё же?
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Если под BIOS были бы драйверы для любого железа и далеко не начального уровня, кто бы стал связываться с существующими ОС?
Ответ может дать старая книжка по Visual Basic. Там, насколько помню, было писано: т.к. работать с MS Office способен только человек, имеющий высшее инженерное образование, то задача VB-программиста - создавать программы для всех.
... или социальные сети...

Veden12> ... сегодняшних конструкторов игр...
За игры не скажу. По-моему, они свернули не туда еще в конце 80-х.
 3.63.6
+
-
edit
 

Veden12

втянувшийся
Gudleifr> задача VB-программиста - создавать программы для всех.
Всё верно. Но Game Maker (например) вовсе не требует знания множества малопонятных и ассоциативно не связанных сущностей. Мне кажется, на фоне продвинутых драйверов со встроенной синхронизацией и достаточно большого числа ядер процессора, это способно превратить ОС в простенькое нерезидентное приложение.
Gudleifr> За игры не скажу. По-моему, они свернули не туда еще в конце 80-х.
В технологическом плане?
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Мне кажется, на фоне продвинутых драйверов со встроенной синхронизацией и достаточно большого числа ядер процессора, это способно превратить ОС в простенькое нерезидентное приложение.
Ну, как бы, задача ОС не только в коллекционировании драйверов, предоставлении программам API, а пользователям - Office.
Основная задача ОС - распределение ресурсов. А для этого необходимо иметь стандарт - описание единиц запроса и уточнение понятия запрашивающего. Приходим к понятию процессов и их взаимодействия... Можно ли ограничиться записью этих соглашений на бумажке и заставить программистов их соблюдать без написания "общего кода системы"? Опыт FORTH показывает, что программный механизм проще реализовать, чем формализовать... Тем, более, что куски кода "взаимодействия" будут повторяться из процесса в процесс. Так, может, вынести их в отдельное место и назвать API?
С другой стороны, хочется иметь ОС, которая "уже помнит" то, что ты (другие) делал раньше и не заставляет выполнять работу по второму разу... Но это фантастика.

Veden12> В технологическом плане [игры пошли не туда]?
Прежде всего в идеологическом. Компьютерные игры отмежевались от "игр вообще" и стали вещью в себе.
Допустим, у нас есть мяч. Его можно пинать, бить об стену, кидать через сетку... Можно придумать много игр, где эти свойства работают.
А компьютер? Он может имитировать игрока-человека, создавать интерактивную среду, подстраивать игру под игрока, управлять суперсложным игровым оборудованием... Но, нет, имеем перенос на компьютер простейших спортивных/настольных игр, которые "почти как всамделишные" и "почти не хуже"...

Но, Вы сами напросились. Еще [не]много цитат "из меня":
... вспомнилась полемика, имевшая место на ФАИ: как бы выглядели современные советские компьютерные игры, если бы СССР не развалился?
Понятно, народ сразу начал оригинальничать по-Гаррису: заменим коммуняк на буржуинов и обратно, фермы меняем на колхозы, Гарри Поттера на Павлика Морозова и т.д. и т.п.
А, ведь, были в СССР и возможности, о которых никогда не слышали на Западе.
И вполне возможно, что какие-нибудь из них могли проявится в создании чего-то, чему в настоящей реальности места не нашлось.
Вот такие вот "forgotten futures"...
Для примера:
  • Военные игры? Безусловно. Как иначе, если пионэры участвуют в игре "Зарница", издаются "Книги будущих командиров", октябрята встречаются с ветеранами..? Были бы это тупые стрелялки или реал-тайм-стратегии? Нет, конечно. Компьютер, как способ восполнить недостающий реализм той же "Зарнице" путем моделирования действий противника, электронные имитаторы боевой техники, обучаловки...
  • Экономические симуляторы? Нет. Только в качестве исторических пособий. Класс управленцев не почете. Учись быть колхозником не за компьютером, а на подсобном хозяйстве.
  • Аркады? Только в игровых автоматах. Чтобы не пасьянс в одиночку раскладывать, а в клубе перед девушками сноровку демонстрировать.
  • Приключенческие? Скорее, в виде конструкторов, сам делаю - сам играю, а заодно программирование изучаю, сделал головоломку - пусть приятель пройдет...
  • Физико-математические? Сколько угодно. Начиная от посадки на Луну, до проведения районных чемпионатов по Core Wars.
  • Обучающие? Не с упором на иллюстрации, а реагирующие на скорость усвоения материала, с гибкой настройкой на обучаемого, с обратной связью на педагога.
  • Спортивные? Футбол - во дворе... Такие программы нам не нужны. Компьютерные Шахматы, наоборот, - в каждый дом! Не только сильно играющие, но и с продвинутым курсом игры.

 
 27.027.0
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Основная задача ОС - распределение ресурсов.
В условиях дефицита – да. Но вычислительная мощность (+MIMD) намного больше, чем требуется, память не ограничивает. В условиях избытка пусть каждый ест сколько влезет. Распределять нужно только время доступа к диску (даже не к самому диску, а к огромному кэшу под управлением его контроллера) и сетевые пакеты. Это совсем уж примитивные задачи. Решаются семафорами. Что делать ОС?

Gudleifr> Так, может, вынести их в отдельное место и назвать API?
Мур призывал решать конкретные задачи, а не пытаться осчастливить человечество. Да, история с ним не согласилась. Сегодня наиболее дорогое ПО – средства разработки. Это товар. И им не нужны стандарты. Они сами хотят диктовать стандарты тем, кто ими пользуется. Графический API намного привлекательнее программного.

Veden12>> В технологическом плане [игры пошли не туда]?
Gudleifr> Прежде всего в идеологическом.
Я думаю, что "тупые стрелялки" и упомянутые Вами развивающие игры имеют одну общую доминанту: и там, и там ключевой является способность выделения наиболее значимых элементов в ворохе получаемой информации (дифференциальный подход). Ни одна игра не направлена на формирование общей картины (м.б. поведенческой) из имеющихся факторов – как сделать так, чтобы результат понравился. Одному, всем. А только такие (интегральные) игры в принципе способны сбалансировать то, что не нравится Вам. И мне тоже.
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> В условиях дефицита - да.
Ну, делить всегда будет что. Монитор, клавиатура, мышь, принтер, выход в сеть... Да и то, чего много, тоже распределять надо, чтобы случайно никто не пересекся (например, один документ понадобится двоим)...

Veden12> Мур призывал решать конкретные задачи, а не пытаться осчастливить человечество.
Заранее писать и бережно относится к написанному - разные вещи.
 27.027.0
+
-
edit
 

Veden12

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

Мне кажется, что рост возможностей железа привёл к тому, что вся концепция ПО устарела. Форт? Может да, может нет. Буду ждать чем кино кончится :)
 33.0.1750.15433.0.1750.154
1 9 10 11 12 13 14 15

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru