реклама на сайте
подробности

 
 
12 страниц V  « < 3 4 5 6 7 > »   
Reply to this topicStart new topic
> ASM: приказали долго жить?, Сколько еще продержится
upc2
сообщение Jun 26 2006, 05:48
Сообщение #61


Знающий
****

Группа: Свой
Сообщений: 506
Регистрация: 29-09-05
Из: Донецк
Пользователь №: 9 063



Думаю, что ассемблер "умрет".При всех своих достоинствах,он тормозит написанию программ.
Будет увеличиваться быстродействие МК.обьем памяти,совершенствоваться его архитектура,
улучьшаться компиляторы и про ассеиблер забудут.Наша жизнь-это еще не вечность.
Go to the top of the page
 
+Quote Post
dxp
сообщение Jun 26 2006, 05:55
Сообщение #62


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(vet @ Jun 24 2006, 04:37) *
Цитата(dxp @ Jun 23 2006, 07:32) *

Мы здесь, напомню, не архитектуру процов обсуждаем (хотя асм на нее тоже "завязан"), мне 51-й на фоне AVR'а тоже претит, но это очень древняя архитектура, что с нее взять на сегодняшний день. А если отвечать на Ваше вышеотквоченное замечание, то возьмите опять же тот же MSP430 - AVR "нервно курит в уголке". smile.gif И по скорости, и по размеру кода. И по удобству кодирования на ассемблере. Мне довелось плотно поработать и с тем, и с другим, поверьте разница по всем параметрам значительная и не в пользу AVR.

а что, MSP действительно шустрее? у него ведь, кажется, и команды не однотактовые, и частоты пониже, да и бенчмарки на Сахаре говорят в пользу AVR.
впрочем, удобства его асма налицо.

Насчет частот, я при равных тактовых сравнивал, чтобы выявить именно плюсы и минусы архитектуры. С самого начала мне казалось, что если данные 8-разрядные, то AVR должен быть быстрее, т.к. он гарвард, в память шустрее лазит - фон неймановский MSP430 за опкодами и данными лазит по тем же шинам, поэтому должен быть медленнее по определению. Его выигрыш состоит в большей разрядности шины данных, поэтому на 16-ти и более разрядных данных он может вполне составить конкуренцию и даже обогнать. Таково было предположение.

Далее стал сравнивать. Для сравнения использовал не какие-то непонятные тесты, а прямо свои рабочие проекты. Надо сказать, что код там вполне обычный, контроллерный - проверка флагов, вызов функций (прямо и по адресу (индексу) из массива указателей), работа с одиночными переменными 8-, 16-, 32-бит, работа с агрегатными типами вроде структур и массивов, и, конечно, работа с объектами классов. Компиляторы в обоих случаях были от IAR. Ожидал увидеть одно, а на деле увидел другое.

Оказалось, что и на 8-битных данных AVR не блещет, а показывает даже немного худший результат. Анализ причин показал следующее (как раз то, что в голову не приходило, пока не увидел это на сравнении): у AVR неортогональный регистровый файл, очень мало аппаратных указателей. Это первая причина, которая и сводит на нет преимущества гарварда по доступу в память. Вторая причина - это отсутствие нормального указателя стека - это усугубляет предыдущий момент - отъедает одну полноценную регистровую пару (указатель стека - Y). В итоге при реальной работе в программе приходится гонять адреса через Z-указатель, получается своего рода "бутылочное горлышко". Например, зашли в функцию, надо обратиться к объекту по адресу - грузим его адрес в Z (две инструкции), обратились; теперь надо обратиться к другому объекту, а с предыдущим работа еще не закончена - в него в конце будет помещен результат; но как быть с адресом? Либо забить на него и в конце еще раз грузить, либо сохранить куда-то временно - т.е. копирование, накладные расходы в том и другом случае примерно одинаковы. И вся программа буквально изобилует такими примерами, когда надо адреса гонять через Z-pointer. Для сравнения - у MSP430 такой проблемы вообще нет - берем и адресуемся с любого из 12 РОН. Надо один объект - адресуемся с одного регистра, надо другой - с другого, а предыдущий никуда не делся, хранится до момента своего следующего использования. Если бы у AVR был бы еще хоть один указатель типа Y или Z, а еще лучше два - то это была бы совсем другая картина. И разрядность данных тут не много значит - адресная арифметика все равно в подавляющем количестве случаев 16-битная.

Из простых тестов могу привести следующее. Вернее, это не тест в самом деле, а просто сравнение эффективности одного и того же куска кода из аналогичных проектов. Там в том и другом было вычисление полинома (от двух переменных) вида:

Код
float math::Pxy(__flash PxyCOEFFS a, const float x, const float y)
{
    float X_2 = x*x;
    float Y_2 = y*y;

    return a[9]*X_2*x + a[8]*Y_2*y +
           a[7]*X_2*y + a[6]*x*Y_2 +
           a[5]*X_2   + a[4]*Y_2   +
           a[3]*x*y   + a[2]*x     + a[1]*y + a[0];
}


Результат:
MSP430F149 : 5197 тактов
ATmega163 : 11941 такт

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

В целом MSP430 за счет более прямого ядра оказывается быстрее AVR'а даже несмотря на свою неймановость. Кстати, обращение в память у AVR - 2 такта, - тоже не впечатляет, медленно это. Должен за такт лазить, принципиально этому ничего не мешает. Этот момент я тоже уже озвучивал здесь на форуме, вступал в дискуссию с некоторыми уважаемыми коллегами, просьба к ним не поднимать тут в очередной раз спор не эту тему. smile.gif

Надеюсь, я ответил на Ваш вопрос удовлетворительно. smile.gif

Чтобы не подумали, что лажаю AVR, скажу, что ядро ядром, но есть и другие факторы - корпус, наличие флеши и ЕЕПРОМ, диапазон напряжений питания, цена и многое другое - по совокупности характеристик AVR выплядит очень даже неплохо! И хотя по многим (большинству) параметров он уступает тому же MSP430, есть несколько позиций, где MSP430 не предлагает адекватную замену. Прежде всего это диапазон питаний - MSP430 имеют диапазон 1.8-3.6 В, если надо 5-вольтовость, то AVR рулит. Второе - наличие поддержки аппаратной внешней шины в некоторых чипах (мега8515, мега128), у MSP430 этого нет вообще. Третье - наличие байтовоадресуемой, стираемой и записываемой энергонезависимой памяти - EEPROM. В MSP430 такого нет, там только флешь, стереть можно только блоком. Правда, при такой организации есть свои преимущества - блоков много и можно произвольно их стирать/записывать прямо на рантайме. Ну, и у AVR есть чипы с большим объемом флеши (ТИ, правда, тоже обещал в MSP430 нового поколения расширения адресного пространства и многих других фич, но это пока обещания). Вот если какие-то из этих моментов актуальны, то AVR вполне рулит. В общем, нету ничего белого или черного - все серое. laugh.gif


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
vet
сообщение Jun 26 2006, 06:37
Сообщение #63


Знающий
****

Группа: Свой
Сообщений: 550
Регистрация: 16-06-04
Из: Казань
Пользователь №: 32



dxp, спасибо за подробный ответ.


--------------------
Главная линия этого опуса ясна мне насквозь!
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Jun 26 2006, 06:40
Сообщение #64


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



dxp, насколько я знаю применение аппаратного умножителя AVR в операциях с float IAR реализовал только в версии 4.20а.
Если Ваш тест с полиномом делался в предыдущей версии, то он слегка некорректен.
Go to the top of the page
 
+Quote Post
dxp
сообщение Jun 26 2006, 06:52
Сообщение #65


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(IgorKossak @ Jun 26 2006, 13:40) *
dxp, насколько я знаю применение аппаратного умножителя AVR в операциях с float IAR реализовал только в версии 4.20а.
Если Ваш тест с полиномом делался в предыдущей версии, то он слегка некорректен.

Я честно написал, что при выключенном умножителе в MSP430 будет проигрыш в полтора раза, т.е. порядка 7.5 тыс. тактов. Что все равно гораздо быстрее AVR'а. И также упомянул, что пример этот полную картину не характеризует, т.к. плавучка - это только полавучка, она больше в реализацию библиотеки упирается. Но поверьте, во всем остальном картина именно такая, как я описал - ядро MSP430 действительно лучше и дает этому МК преимущество как по скорости, так и по размеру кода. И все это при меньшем потреблении.


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
CD_Eater
сообщение Jun 26 2006, 13:20
Сообщение #66


Частый гость
**

Группа: Новичок
Сообщений: 173
Регистрация: 3-09-04
Из: Moscow
Пользователь №: 595



dxp, тест очень неудачный
Сравнение вычислительных операций всегда будет в пользу проца с большей разрядностью регистров.
Простой пример - умножение чисел двойной разрядности потребует в 4 раза больше времени (используя карацубу - в три раза, но выигрыш от этого получается только при очень большой разрядности). Даже больше, чем в 4 раза (надо ещё прибавить сложения промежуточных результатов)Поэтому 16-битный аналог АВР опережал бы в 4 с лишним раза, а МСП - только в 2. Хы-хы.

Возьми задачку, где разрядность выше 8 бит почти не требуется, и сравни такты. (Типичные задачки МК уровня АВР именно таковы).
Go to the top of the page
 
+Quote Post
dxp
сообщение Jun 26 2006, 13:59
Сообщение #67


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(CD_Eater @ Jun 26 2006, 20:20) *
dxp, тест очень неудачный
Сравнение вычислительных операций всегда будет в пользу проца с большей разрядностью регистров.
Простой пример - умножение чисел двойной разрядности потребует в 4 раза больше времени (используя карацубу - в три раза, но выигрыш от этого получается только при очень большой разрядности). Даже больше, чем в 4 раза (надо ещё прибавить сложения промежуточных результатов)Поэтому 16-битный аналог АВР опережал бы в 4 с лишним раза, а МСП - только в 2. Хы-хы.

"Бы да бы, да бы мешает" (с) пословица. "Если б бабушка была дедушкой..." (с) Если бы у AVR было 8 регистровых пар - аппаратных указателей типа Z, если бы на уровне этих регистровых пар поддерживалась арифметика, если бы AVR имел нормальный указатель стека, если бы AVR имел доступ в память в один такт, если бы он вообще был 16-разрядным, а еще лучше - 32-разрядным... и еще много-много всяких если. Однако текущий факт, что MSP430 быстрее (в тактах), код у него меньше, ассемблер приятнее. Это первое.

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

И кстати, 32-разрядный Blackfin что-то не опережает MSP430 в 4 (!) раза. А уж у него-то все в наличие - и шины, и регистры, и все остальное.

Цитата(CD_Eater @ Jun 26 2006, 20:20) *
Возьми задачку, где разрядность выше 8 бит почти не требуется, и сравни такты. (Типичные задачки МК уровня АВР именно таковы).

Вы, очевидно, невнимательно читали. Я подробно описал, что и сам так думал до сравнения. А когда сравнил, то и удивился, почему оно не так. И когда стал разбираться с причинами, то выяснил, что главная проблема с тормозами у AVR - бедные возможности по адресации, когда почти все адреса идут через один аппаратный указатель. И адреса 16-битные и от разрядности данных это не зависит. Перечитайте внимательнее предыдущие посты и подумайте над этим хорошенько. Если это Вас не убеждает, спорить все равно не буду - я уже один раз это прошел, у меня нет ни времени, ни желания, ни сил повторять эксперименты. Возьмите AVR и MSP430, возьмите какую-нибудь задачу, прогоните, сравните. Только не надо брать рекламные примеры, возьмите рабочую программу. В готовом виде есть примеры почти одного и того же кода тут. Код обычный - функции, условия, ветвления. Скомпилируйте и сравните. И посмотрите листинги - все сразу станет понятным.


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
SpiritDance
сообщение Jun 26 2006, 17:41
Сообщение #68


Дух погибшего транзистора
****

Группа: Свой
Сообщений: 877
Регистрация: 6-09-05
Из: Москва
Пользователь №: 8 288



dxp
Поддерживаю Вас. В MSP430 ядро несравнено лучше. Хоть сам я до реальных задач на MSP не добрался, однако в АЛУ влюбился сразу, грамотно все сделано, даже АРМ мне меньше понравился. (PDP11 rules wink.gif )
Вот только ядро, как верно было подмечено - это еще не все, батарейные они mspшки эти, такими видно и останутся. Особенно удручило отсутсвие толерантности к 5V. Ну и еще неудобного есть по мелочи. И дорогие они, в основном.


--------------------
Yes, there are two paths you can go by But in the long run Theres still time to change the road youre on.
Go to the top of the page
 
+Quote Post
CD_Eater
сообщение Jun 26 2006, 20:30
Сообщение #69


Частый гость
**

Группа: Новичок
Сообщений: 173
Регистрация: 3-09-04
Из: Moscow
Пользователь №: 595



dxp
Я не говорю, что AVR существенно мощнее smile.gif)))))))
Однако был приведён всего единственный тест, результат которого мог быть предсказан заранее и не мог отражать реального соотношения производительностей на характерных задачах МК.
Моя критика направлена не на утверждение о соотношении производительностей этих МК, а на метод доказательства этого утверждения.

Несчёт "узкого горлышка", которое Вы обнаружили в малом количестве указателей у AVR и в неполноценном указателе стека. Это действительно нехорошо с точки зрения общепринятого способа компиляции с ЯВУ, но при программировании на АСМе это не вызывает каких-либо затруднений. У меня сложилась практика использовать в качестве указателей только X и Y, а регистр Z - для "временных" целей (то есть, не ассоциировать его с каким-то значением, постоянным по ходу выполнения всей программы). Если обрабатываем два массива - X и Y. Если работаем со структурой - Y+displacement. Если нужно прочитать из флеша (или временно нужен дополнительный указатель) - используем Z. В частности, я никогда не использовал Z для обращений вида Z+displacement, и в этом вижу даже некоторую избыточность. Трёх указателей всегда хватало.

По поводу стека - при правильном распределении регистров использование стека минимально. Пихать в него параметры функций и создавать там локальные переменные - дурная привычка компиляторов с ЯВУ.
Кстати, раньше, как Вы, наверное, помните, в x86 был тот же подход - кроме указателя стека (SP, относительно которого нельзя адресоваться к данным в стеке) для стековых операций резервировался ещё один регистр (BP, полноценный), полную аналогию чему наблюдаем в компиляторах под AVR. Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ? smile.gif)
Стек хорош для алгоритмов, когда размер данных, помещаемых в стек, предсказать сложно. Например, рекурсий. Для МК это непозволительная роскошь (по крайней мере, пока размер стека исчисляется сотнями байт). И подход к использованию стека в МК должен отличаться от принятого в софте настольных компьютеров.

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

К чему это я ? Просто все "узкие горлышки" куда-то исчезают, как только забываешь про Си и начинаешь писать на ассемблере - под это дело AVR заточен вполне пристойно, и в плане компактности кода, и в плане быстроты выполнения инструкций, и в плане удобства программирования (не идеал, но близко).
Go to the top of the page
 
+Quote Post
haker_fox
сообщение Jun 27 2006, 01:29
Сообщение #70


Познающий...
******

Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125



Цитата(CD_Eater @ Jun 27 2006, 05:30) *
Моё мнение - насаживание ЯВУ (напр., Си) на МК по своей природе противоестественно, но выполняется для благой цели - чтобы программисты, знакомые с ЯВУ, смогли писать прошивки. Ведь Атмелу, например, хочется продать побольше чипов, а ЯВУ - это хороший маркетинговый ход. л, но близко).

Знание асма для программиста ЯВУ никто не отменял. Язык Си - это инструмент, которы позволяет лишь ускорить разработку программы, сделать ее более наглядной, обеспечить переносимость на другие платформы.
И не могли бы Вы пояснить, почему насаживание ЯВУ (напр., Си) на МК по своей природе противоестественно? В принципе МК - компьютер (ИМХО) и стандарт на язык Си не огаваривает аппаратную платформу.

Цитата(CD_Eater @ Jun 27 2006, 05:30) *
В результате компьютерами пользуются секретарши, а на МК программируют не знающие ассемблера прогеры.

Голословное утверждение (ИМХО).

Цитата(CD_Eater @ Jun 27 2006, 05:30) *
К чему это я ? Просто все "узкие горлышки" куда-то исчезают, как только забываешь про Си и начинаешь писать на ассемблере - под это дело AVR заточен вполне пристойно, и в плане компактности кода, и в плане быстроты выполнения инструкций, и в плане удобства программирования (не идеал, но близко).

Нет, еще понятно, если человек просто пишет), т.е. не заглядывает в листинг. Не интересуется возможностями МК, его ограничениями и проч. Такие люди просто ламеры и все.


--------------------
Выбор.
Go to the top of the page
 
+Quote Post
spf
сообщение Jun 27 2006, 03:47
Сообщение #71


Странник
****

Группа: Свой
Сообщений: 766
Регистрация: 29-08-05
Из: Екатеринбург
Пользователь №: 8 051



Цитата(CD_Eater @ Jun 27 2006, 02:30) *
Трёх указателей всегда хватало.

Видимо задачи большего не требовали или желание всегда ограничивалось на корню. wink.gif
Цитата
По поводу стека - при правильном распределении регистров использование стека минимально.

Опишите методику правильного распределения, причем безотносительно конкретного проца.
Цитата
Пихать в него параметры функций и создавать там локальные переменные - дурная привычка компиляторов с ЯВУ.

ИМХО. Подобные мысли можно обосновать только плохой реализацией в проце работы со стеком.
Цитата
Кстати, раньше, как Вы, наверное, помните, в x86 был тот же подход - кроме указателя стека (SP, относительно которого нельзя адресоваться к данным в стеке) для стековых операций резервировался ещё один регистр (BP, полноценный), полную аналогию чему наблюдаем в компиляторах под AVR.

Аналогия с x86 не впользу AVR, x86 разрабатывали 40 лет назад а AVR 10 и далеко не ушли...
Цитата
Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ? smile.gif

Есть и такое, например у всей линейки МК от Fujitsu, начиная с 8-ми битников.
Цитата
Стек хорош для алгоритмов, когда размер данных, помещаемых в стек, предсказать сложно. Например, рекурсий. Для МК это непозволительная роскошь (по крайней мере, пока размер стека исчисляется сотнями байт). И подход к использованию стека в МК должен отличаться от принятого в софте настольных компьютеров.

Чаще необходима реентерабильность, которая без полноценногог стека нереализуема. Эта самая вещь позволяет экономить память и не ломать голову по ручному распределению памяти - экономия времени/нервов и крохотных ресурсов RAM МК.

ИМХО: Тащиться от асма в в век когда межпланетные корабли бороздят просторы вселенной как то не серьезно...


--------------------
"Как много есть на свете вещей, которые мне не нужны!" Сократ
Go to the top of the page
 
+Quote Post
Kopa
сообщение Jun 27 2006, 04:39
Сообщение #72


Знающий
****

Группа: Участник
Сообщений: 598
Регистрация: 22-08-05
Пользователь №: 7 861



Цитата(spf @ Jun 27 2006, 06:47) *
ИМХО: Тащиться от асма в в век когда межпланетные корабли бороздят просторы вселенной как то не серьезно...

Отчасти согласен, но в альтернативе кроме Си использую Forth ( при всей его непопулярностиsmile.gif
Что гораздо ближе к внутренностям контроллеров.
Есть мнение, что Си это высокоуровневый ассемблер заметно
удалившийся от прародителя.

P.S. MSP не было бы без PDP11. Жаль что урезали от способов адресации больше чем нужно.
На асме есть любители писать ОС для PC.
Если бы не переносимость, то это было бы оправдано.
А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)
Go to the top of the page
 
+Quote Post
SpiritDance
сообщение Jun 27 2006, 04:51
Сообщение #73


Дух погибшего транзистора
****

Группа: Свой
Сообщений: 877
Регистрация: 6-09-05
Из: Москва
Пользователь №: 8 288



Цитата(Kopa @ Jun 27 2006, 08:39) *
А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

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


--------------------
Yes, there are two paths you can go by But in the long run Theres still time to change the road youre on.
Go to the top of the page
 
+Quote Post
Kopa
сообщение Jun 27 2006, 05:04
Сообщение #74


Знающий
****

Группа: Участник
Сообщений: 598
Регистрация: 22-08-05
Пользователь №: 7 861



Цитата(SpiritDance @ Jun 27 2006, 07:51) *
Цитата(Kopa @ Jun 27 2006, 08:39) *

А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

Все изобретено до нас. IL из .NET вполне годится под определение универсального ассемблера. Универсальность просто как проавило достигается за счет уменьшения эффективности кода, то есть его заточенности под конкретную архитектуру.


Согласен, если не считать что он, как Java байт-код, заточен под стековую архитектуру
и остается проблема оптимальной генерации кода на регистровую архитектуру.
Плюс остается специфика системы команд контроллера, которую тоже непросто учесть.smile.gif

P.S. Встречный вопрос.
Подходит ли Форт под понятие универсального ассемблера из сравнения с IL:)
( промежуточного языка )
Go to the top of the page
 
+Quote Post
spf
сообщение Jun 27 2006, 06:10
Сообщение #75


Странник
****

Группа: Свой
Сообщений: 766
Регистрация: 29-08-05
Из: Екатеринбург
Пользователь №: 8 051



Цитата(CD_Eater @ Jun 27 2006, 02:30) *
Трёх указателей всегда хватало.

Вспомнилось, в загрузщике по UART от Fujitsu кода на 800 байт написанном на асме изпользуется аж 6 (шесть) указателей. Хотя код как сами понимаете простейший.


--------------------
"Как много есть на свете вещей, которые мне не нужны!" Сократ
Go to the top of the page
 
+Quote Post

12 страниц V  « < 3 4 5 6 7 > » 
Reply to this topicStart new topic
4 чел. читают эту тему (гостей: 4, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st July 2025 - 00:31
Рейтинг@Mail.ru


Страница сгенерированна за 0.01501 секунд с 7
ELECTRONIX ©2004-2016