Конференция Radeon.ru
| Страница 1 из 4 [ Сообщений: 142 ] Версия для печати [+] | На страницу 1, 2, 3, 4 След. |
|
Предлагается всем присоединится к обсуждению возможностей будующих Pentium M и возможно К9. Для затравки привожу начало моего разговора с matik-ом
Fury 13.05.20 12:50 Привет Как думаешь. если Прескотт будет последним NetBurst , а будущие десктопы будут на ядре PentiumM, означает ли это что в PentiumM будет (а возможно уже? ) внедрён x86-64? matador 13.05.20 12:53 думаю, да.... в П-М гораздо проще встроить х86-64 Fury 13.05.20 12:54 Ага как в К7. Ну что ж. Это хорошо, что мы опять вернёмся к баллансу микропроцессоров, без ярко выраженного преимущества того или другого в конкретном приложении  matador 13.05.20 12:56 Согласен )matador 13.05.20 12:56 Впрочем, все же П-М чуток слабоват с К8 сражаться... Думаю, его будут усиливать... Fury 13.05.20 12:57 Да, наверное 800 Мгц FSB дадут. matador 13.05.20 12:57 не только... matador 13.05.20 12:57 думаю, блоков доклеят... matador 13.05.20 12:57 например, SSE2... Fury 13.05.20 13:00 М.. А разве в Pentium M не было SSE2? Чес слово не знаю, как то до него руки не доходили matador 13.05.20 13:01 было Но, учитывая малую (по сравнению с П4частоту), придется делать этот блок шире, чтобы перегнать НетБерст Логично?Fury 13.05.20 13:01 Второй FPU ? Согласен matador 13.05.20 13:02 думаю, сделают... И, возможно, улучшат ситуацию с АЛУ (хотя она вроде и так неплоха)... matador 13.05.20 13:02 Ассоциативность кэша второго уровня стоит поднять... Fury 13.05.20 13:03 Интересно, а в К9 второй FPU делать не собирались? matador 13.05.20 13:03 не знаю Честно Fury 13.05.20 13:05 Вот я смотрел как-то на Спеки. Итаниум 2 у Оптерона в плавучке выиигрывает в основном потому что у него 2 FPU. Думаю, что если Оптерону второй FPU дать, он на своей более высокой частоте Itanium забить должен matador 13.05.20 13:07 весь вопрос в том, сумеет ли он тогда достичь своей высокой частоты ) Согласен? Два ФПУ —это более сложный декодер, и так далее... Fury 13.05.20 13:07 Декодер, нет, планировщик — да. Вообще согласен конечно matador 13.05.20 13:08 Почему декодер нет? А кормить ты чем будешьдва ФПУ? Тебе, значит, надо не 3МОПа за такт делать, а хотя бы 4... Fury 13.05.20 13:10 Я так не думаю. Чтобы кормить 2 FPU каждый такт, достаточно каждый такт декодировать 1 SSE[2] команду (сейчас же 2 половинки исполняются со сдигом в такт). А у нас полторы, так что запас matador 13.05.20 13:11 а весь остальной процессор пойдет рыбу удить? )Адреса обрабатывать, условные переходы, данных дожидаться... )matador 13.05.20 13:11 Не-е-е-е, был бы четкий стимул расширять до 4 МОПов... Конечно, и три тоже ничего — но, ИМХО, в данном случае есть прямой смысл уширять весь тракт... Fury 13.05.20 13:14 >а весь остальной процессор пойдет рыбу удить? ):—) хорошо сказал. И да и нет. "Нет" потому что в плотных циклах, FPU команды преобладают. Но если расшить до 4-х без потери в тактовой частоте смогли, было бы великолепно matador 13.05.20 13:15 именно: 1. Было бы место для 2ССЕ за такт 2. Можно было бы обрабатывать достаточно продвинутую целочисленную логику... Не-е-е-е, если уж связываться с увеличением количества ФПУ, то попутно расширяя конвейер Тем паче, что именно ФПУ, думаю, один из самых греющихся блоков... Fury 13.05.20 13:16 Да, уж. |
|
Не, им МС надо тоже интегрировать
 |
|
ISA_user
Думаю, это они оставят на крайний случай... Потому что одна из сильных сторон Интеловских чипсетов — контроллер памяти. Если его интегрировать в процессор, сильно снизится привлекательность Интеловских чипсетов — они и дороже конкурентов, и, как правило, функционально беднее... Зачем себе бизнес подрезать? |
|
ISA_user
К тому же котнролер памяти IMO не даст того преимущества, котое дал бы, например, второй FPU. |
|
matik
Потому что одна из сильных сторон Интеловских чипсетов — контроллер памяти. но шина! она в раз имеет большую латентность, т.к и сама она и буфера на стороне ЦПУ и МС работают на "малых" частотах. Зачем себе бизнес подрезать? ну только из-за этого? хотя они ведь могут и кривую построить чт выгоднее — уж свою маржу они знают Yury_Malich К тому же котнролер памяти IMO не даст того преимущества, котое дал бы, например, второй FPU. зато это можно сделать быстрее, т.к. это вопрос технологии а не разработки... |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>ISA_user:
зато это можно сделать быстрее, т.к. это вопрос технологии а не разработки...</SPAN><HR size=22></SPAN></BLOCKQUOTE> Не думаю что интегрировать котроллер памяти намного проще чем второй FPU. Хотя утвержать или опровергать что-то здесь не рискну. |
|
matik
<I>сильно снизится привлекательность Интеловских чипсетов — они и дороже конкурентов, и, как правило, функционально беднее... Зачем себе бизнес подрезать?</I> Напротив, они весь бизнес контроллеров памяти себе забирают, попутно забирая эти деньги у конкурентов. Плюс если ставить вопрос "проигрывать по производительности и делать много денег на чипсетах" против "делать на чипсетах меньше, но иметь топовую производительность", то ответ очевиден. |
|
Yury_Malich
Не думаю что интегрировать котроллер памяти намного проще чем второй FPU. намного |
|
Yury_Malich, matik: По поводу "второго" FPU в K8+ (да и P-M, видимо, тоже):
речь идет в основном об ускорении векторных SSE2 операций (а не скалярных или x87), так что ни декодер, ни планировщик это существенно не затронет. То есть, конечно, видимо, надо некоторые новые mop-ы, будет ввести, но и только. Более того, собственно, речь не об "удвоении" блоков, а об уширении одного блока с 80бит до 128 (ну или для мантиссы с 64 до ~100), то есть сложность блока FPU возрастает "всего лишь" в ~1.5 раза. Много хуже (точнее, лучше, но сложнее) то, что это автоматически потребует расширения всех внутренних шин данных с 64 до 128битов. По поводу P-M надо у C@t спросить. Он вроде считает, что там "удвоение" просто сделать не получится. Я еще раз посмотрел OptManual на Pentium's. Вроде бы по простым FPU операциям K8 и P-M потактово-идентичны, по сложным K8 много лучше. Однако в низкоуровневых внутрикэшевых тестах P-M проигрывает даже на простых операциях. Вероятно, дело еще в доступе в L1 кэш. В общем, с FPU в P-M делать что-то в любом случае надо. А в K8+ (всвязи с отменой Tejas), может, и не обязательно --- он и так конкурентноспособный (а жаль). |
|
KSP
Напротив, они весь бизнес контроллеров памяти себе забирают Сомневаюсь, что есть некий отдельный "бизнес контроллеров памяти"... Есть рынок чипсетов. Привлекательность чипсетов именно от Интел — в их производительности, поскольку функциональность у конкурентов шире. Соответственно, убрав производительность — подрежем привлекательность. Зачем? <I>Плюс если ставить вопрос "проигрывать по производительности и делать много денег на чипсетах" против "делать на чипсетах меньше, но иметь топовую производительность", то ответ очевиден. </I> А вот это действительно сложный выбор. Только я бы его чуток по-другому рассмотрел... 1. Если процессоры будут безусловно и сильно проигрывать по производительности, то это будет вынужденный шаг — тогда не до жиру. 2. Если будут примерно равны (или не сильно проигрывать), тогда можно и не делать. И, соответственно, не снижать свои прибыли... VLev он и так конкурентноспособный (а жаль). Я понял идею, но КАК это звучит!  |
|
VLev
речь идет в основном об ускорении векторных SSE2 операций Кстати, подумалось вот чего — а почему бы не сделать второй блок? Тогда вырастет скорость ВСЕХ операций, а не только векторных. Явно выгоднее. Правда, может оказаться заметно более сложным. |
|
matik
убрав производительность Убрав отличие/преимущество в производительности подрежем привлекательность. Зачем? Но при этом себестоимость/прибыль контроллера памяти они будут забирать себе с каждого проца, а не с каждого чипсета. Если будут примерно равны (или не сильно проигрывать), тогда можно и не делать. Согласен. Хотя тенденция к интеграции всего в проц налицо. VLev А в K8+ Вряд-ли все недавние новости столь фундаментально повлияют на разработку К8+. Кстати, когда он намечается к выходу? |
|
KSP
Но при этом себестоимость/прибыль контроллера памяти они будут забирать себе с каждого проца, а не с каждого чипсета. Дык как бы и так процентов 80% рынка чипсетов у ИНтел... Так что принципиально разница невелика. И еще одно... Брать деньги за встроенный в процессор контроллер сложно. Как Вы себе это представляете? Вы же за ФПУ не доплачиваете, не так ли? Соответственно, напрямую денег не снять — разве что косвенно, за увеличенную скорость системы. |
|
matik
разве что косвенно, за увеличенную скорость системы. Примерно так. При этом снизив цену и себестоимость чипсета, на что будут вынуждены пойти и конкуренты. И сколько вообще составляет чипсетный бизнес против ЦПУшного в деньгах? |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik:
Явно выгоднее. Правда, может оказаться заметно более сложным.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Сложнее --- несоизмеримо. Что выгоднее --- спорно, т.к. пропадет сбалансированность потоков кода, данных и "мощности" FPU. Кстати, не факт что будет даже просто быстрее. В смысле будет примерно одинаково на неоптимизированном коде и на оптимизированном векторном. Так что остается только оптимизированный чисто скалярный... IMHO, "убиваться" за это бессмысленно. |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>KSP:
Вряд-ли все недавние новости столь фундаментально повлияют на разработку К8+. Кстати, когда он намечается к выходу?</SPAN><HR size=22></SPAN></BLOCKQUOTE> Не знаю... Хотя лично я бы многие шины данных до 128бит расширил бы уже в 90nm K8. Ну и FPU за одно... |
|
Yury_Malich
а будущие десктопы будут на ядре PentiumM В ближайшие годы Прескотт будет в десктопах. Интел подтвердил это вчера. KSP И сколько вообще составляет чипсетный бизнес против ЦПУшного в деньгах? За 1 кв 2004: Microprocessor = $5,980 (In millions), Chipset + mb = $1,045 (In millions) Зачем ломать то, что приносит неслабый доход? |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>U2:
Зачем ломать то, что приносит неслабый доход? </SPAN><HR size=22></SPAN></BLOCKQUOTE> Да, я тоже думаю, что это и есть основной аргумент почему не будет встроенного MC у Intel в ближайшее время. Но еще есть и технический: Надо разрабатывать шину общения процессора с внешним миром. Так как она д.б. стандартизирована (я тут надеюсь, что совсем закрытых архитектур Intel делать не будет), то, насколько я понимаю, о ее параметрах сообщают задолго до выпуска. Но но о чем подобном Intel вроде бы пока не сообщала. Или же это будет HyperTransport ™ Technology |
|
VLev
Или PCI Express 16-32x. Why not? Её вполне достаточно для десктопов. Правда что делать в многопроцессорных архитектурах — неясно. На худой конец можно ту же QPB немного переделать. |
|
U2
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote> В ближайшие годы Прескотт будет в десктопах. Интел подтвердил это вчера. </SPAN><HR size=22></SPAN></BLOCKQUOTE> Я бы уточнил "в ближайшие год ". До второго квартала 2005 не намного больше года . Но это не мешает нам сейчас обсуждать. Не так ли? |
|
VLev
Что выгоднее --- спорно, т.к. пропадет сбалансированность потоков кода, данных и "мощности" FPU. Если делать второй FPU, то делать и 4МОПа за такт, это понятно... лично я бы многие шины данных до 128бит расширил бы уже в 90nm K8. Ну и FPU за одно... Очень может быть, что этим сейчас инженеры АМД и заняты — в конце концов, сдерживающая сила явно технологи, а не разработчики... |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik:
Если делать второй FPU, то делать и 4МОПа за такт, это понятно...</SPAN><HR size=22></SPAN></BLOCKQUOTE> Только 4х MOP-ов IMHO, не достаточно. Если мы за такт в FPU будем получать 2 независимых результата из 4х аргументов систематически (4 из 8 в пике), то существующее LSU (2load+1store за такт) просто не справится с такой нагрузкой. Короче, я просто не понимаю как с существующему ядру прикрутить второй FPU. |
|
Мои 2 копейки:
1. EM64T в P-M будет. Отеллини подтвердил (см, например, http://www.theinquirer.net/?article=15915 в конце заметки) 2. Насчет 2-го FPU. В раннем tape-out Willamette было 2 полноценных FP execution units. Потом для экономии площади, 2-й unit урезали (что сыграло одну из роковых ролей в судьбе P-4). Сейчас Intel, скорей всего, не повторит ту же ошибку. 3. НТ и memory controller будут — по слухам — в Conroe [Исправлено: BEKTOP : 15-05-2004 02:06] |
|
BEKTOP
В раннем tape-out Willamette было 2 полноценных FP execution units Я тоже читал это в давней iXBT-шной статье про П4, но так и не понял, а откуда взялась эта идея? Очень как-то странно выглядит... |
|
Давайте попробуем составить список фич Post-P6 (aka Pentium M c двумя ядрами) который позволит ему догнать и обогнать очень быстрый Оптерон? Причём чтобы это было с заделом на несколько лет вперёд
|
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik:
BEKTOP В раннем tape-out Willamette было 2 полноценных FP execution units Я тоже читал это в давней iXBT-шной статье про П4, но так и не понял, а откуда взялась эта идея? Очень как-то странно выглядит...</SPAN><HR size=22></SPAN></BLOCKQUOTE> Идея добавить или убрать? Вообще-то 2 execution units там есть и сейчас. В первоначальном дизайне они оба были полноценными, но потом 2-й юнит урезали, оставив только функции move(load)/store. |
|
VLev
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>По поводу "второго" FPU в K8+ (да и P-M, видимо, тоже): речь идет в основном об ускорении векторных SSE2 операций (а не скалярных или x87), так что ни декодер, ни планировщик это существенно не затронет. То есть, конечно, видимо, надо некоторые новые mop-ы, будет ввести, но и только. Более того, собственно, речь не об "удвоении" блоков, а об уширении одного блока с 80бит до 128 (ну или для мантиссы с 64 до ~100), то есть сложность блока FPU возрастает "всего лишь" в ~1.5 раза.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Не согласен. Я так полагаю, что как раз в случае уширения придёться переделывать и декодер и планирощик. Декодер:, потому что во всех случаях для каждой команды вместо двух мопов SSE[2] придётся делать новый один МОП, а для планировщика появятся новые типы данных (128 -разрядные), который тоже нужно учитывать. А в случае добавления второго FPU декодер переделывать в принципе не надо вообще: два SSE[2] МОПа будут уходить на два независимых FPU , может немного доделать декодер.
Ну внутренние шины данных естественно придётся расширить в любом случае: ущирения FPU или удвоения. Что мы будем иметь: декодеры выдают не менее трёх МОПов за такт, 2 FPU смогут за такт проглатывать 2 из трёх МОПов, данные для которых смогут поступать по шинам удвоенный ширины. Где же дизбалланс?
А какая нам в принципе разница скалярный или векторый? Нам шашечки или ехать? Главное чтобы с конвейеров могли сходить 2 FPU МОПа за такт а из каких x86 команд эти МОПы добывать скалярных x87, SSE или векторных SSE по-моему для планировщика и 2-х FPU не важно. У векторных преимущество: надо меньше x86 команд на то же количество МОПов.
Не понял, что значит "остается ", почему он вдруг сам по себе? BEKTOP
Имеется ввиду He said the EM64T technology will also be put into dual core systems. ? Ой как не скоро это. Прескотт получается в ближайшее время единственный x86-64 процессор Интел.
Не верю я что в Pentium M будет HT. Не к селу он там IMO |
|
Ещё у меня есть одна мысль: интересно появится ли когда нибудь в системе команд SSE команда muladd (умножение с накоплением) которая есть в PowerPC и Itanium. Правда её придётся делать 3-х операндной, что для синтаксиса x86 может представить трудность, но не преодолимую , если отказатся от ссылок в память в синтаксисе команды.
|
|
BEKTOP
Вообще-то 2 execution units там есть и сейчас. В первоначальном дизайне они оба были полноценными, но потом 2-й юнит урезали, оставив только функции move(load)/store. Да, слышал. Только вот непонятно, откуда же все-таки растут ноги у этой идеи... Yury_Malich Не согласен  Ты сумел оформить то, что я хотел промычать Ещё у меня есть одна мысль Когда-нибудь — может быть. Вот как раз в АМД64 ее бы ввести, все равно расширяли систему команд... А теперь разве что на SSE4 какое-нибудь придется надеяться... |
|
Yury_Malich:
... во всех случаях для каждой команды вместо двух мопов SSE[2] придётся делать новый один МОП, С этим я согласен. Я и писал: > То есть, конечно, видимо, надо некоторые новые mop-ы, будет ввести, но и только. Но это IMHO будет даже некоторым упрощением настоящей ситуации при одновременном общем улучшении, так как несколько разгружает весь тракт от декодера до буферов команд FPU, позволяя другим mop-ам "двигаться" по нему свободнее. В общем, эти mop-ы становятся еще более макро-, что лежит в русле идеологии конвейера K7/8. а для планировщика появятся новые типы данных (128 -разрядные), который тоже нужно учитывать. Ну и слава Богу. Я тут вообще никакого усложнения не вижу (именно для планировщика). Шины данных и физ. регистры --- да, должны измениться. А в случае добавления второго FPU декодер переделывать в принципе не надо вообще: два SSE[2] МОПа будут уходить на два независимых FPU , "В принципе", действительно не надо. Но что тогда, со старым декодером, нам дает-то второй FPU? Максимальная скорость наполнения декодером очередей: 1.5 SSE2 инстр/такт, а скорость разгрузки у "существенной части" двойного FPU --- 2 (add+mul). Соотношение наполнение/разгрузка д.б. минимум обратное, т.к. на каждую FPU операцию приходится еще сколько-то вспомогательных (скажем, 1.1: одна операция загрузки и еще кусочек операций сохранения и изменения базового адреса. может немного доделать декодер. Тут даже 4 mop/такт мало. Так что IMHO, лучше изменить сами mop-ы Ну внутренние шины данных естественно придётся расширить в любом случае: ущирения FPU или удвоения. Но --- совершенно по-разному. В случае уширения просто увеличить разрядность с 64бит до 128, а в случае удвоения --- делать вторую независимую 64бит шину и как-то решать проблемы разделения ими доступа в L1 кэш и к регистрам. Что мы будем иметь: декодеры выдают не менее трёх МОПов за такт, 2 FPU смогут за такт проглатывать 2 из трёх МОПов, 4 (add+mul) не считая load/store (сейчас +2). Итого минимум 6 из 3 возможных. данные для которых смогут поступать по шинам удвоенный ширины. По удвоенному количесту шин той же ширины. А какая нам в принципе разница скалярный или векторый? Нам шашечки или ехать? Главное чтобы с конвейеров могли сходить 2 FPU МОПа за такт Они и так сходят, и даже 3 (1add+1mul+1ld/store). Лично я борюсь за [содержательных] 6 "rop"-ов, а не за 3 mop-а (как сейчас). Именно потому, что мне "ехать", а не шашечки. А так мне конечно все равно как это будет называться и из чего они будут набираться. Не понял, что значит "остается ", почему он вдруг сам по себе? Потому что, раз уж оптимизация под SSE2 делается, то можно и векторизовать заодно. Мне вообще кажется использование SSE2 в чисто скалярном режиме (как реально сейчас в оптимизации под AMD64) чем-то искусственным. |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Yury_Malich:
Ещё у меня есть одна мысль: интересно появится ли когда нибудь в системе команд SSE команда muladd (умножение с накоплением) которая есть в PowerPC и Itanium.</SPAN><HR size=22></SPAN></BLOCKQUOTE> IMHO, не нужна. |
|
VLev
Ок, мысль понятна, я ещё обдумаю. Интересно ещё C@t-а послушать
Почему? Зависимое сложение после умножение это 4+4=8 тактов. muladd Выпоняет эту же пару за 4 такта. Очень мощная команда. |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Yury_Malich:
Почему? Зависимое сложение после умножение это 4+4=8 тактов. muladd Выпоняет эту же пару за 4 такта. Очень мощная команда.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Ну, это как реализовать... Вообще, самым простым улучшением FPU я считаю добавку функции fadd умножителю. Тогда FPU сможет выполнять не только 1add+1mul, но и 2add за такт --- более универсально, и не требует никаких других изменений. Ну и соответственно, тогда можно подумать и о muladd. Но пока сумматор и умножитель отдельные блоки --- muladd IMHO не нужен. |
|
VLev
О да, совершенно согласен, для muladd нужен Fmuladd. Я кстати и подразумевал, что так должно быть, когда писал о muladd. Кстати и два FPU , о которых я рассуждал представляются мне как два устройства Fmuladd и два Fload, a не как 6: Fmul, Fadd, Fload, Fmul, Fadd, Fload [Исправлено: Yury_Malich : 16-05-2004 00:57] |
|
Tejas отменили — а что будет c TNI (SSE4)? Дебютирует с Post-P6 или на него забили вместе с NetBurst?
|
|
Ivan Andreevich
Скорее всего сделают когда-нибудь. Кстати насколько я понимаю в Dothan пока даже SSE3 нет. |
|
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik:
BEKTOP Вообще-то 2 execution units там есть и сейчас. В первоначальном дизайне они оба были полноценными, но потом 2-й юнит урезали, оставив только функции move(load)/store. Да, слышал. Только вот непонятно, откуда же все-таки растут ноги у этой идеи... </SPAN><HR size=22></SPAN></BLOCKQUOTE> Скорей всего, идеологи NetBurst предполагали скомпенсировать длинный конвейер. Отсюда и идея 2 ALU и 2 FPU. Согласен, что производительность П(2 FPU) <= П(FPU) + П(FPU). Но все же прирост был бы. |
|
Yury_Malich
Насколько я понимаю, из-за смены архитектуры набор SIMD комманд нужно перерабатывать. Всё же там многие комманды были ориентированы на NetBurst и её слабые места. |
|
Ivan Andreevich
Да нет, с набором команд всё в порядке. Он логичен и строен и вполне универсален, если не считать команд для HT (это наверное единственные команды ориентированные на NetBurst). Под NetBurst ориентирована оптимизация потока команд. А вот что касается самой оптимизации, это да, доработать под Pentium M придётся. |
|
matik
Почему, скажем, не 5? Или 6, как подсчитал VLev? VLev
Микро WLIV? BEKTOP
1) откуда эти данные? меня тоже давно интересует их источник 2) даже если и хотели, то просто передумали, потому что ни в Норсвуде, ни в прескотте ничего не изменилось — а ведь могли запросто. Yury_Malich
IMHO HT везде "к селу", если ядро способно переваривать много операций одновременно.
Есть же уже трёхоперандные. |
| Новая тема Ответить | Страница 1 из 4 |
[ Сообщений: 142 ] | На страницу 1, 2, 3, 4 След. |
Кто сейчас на конференции |
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1 |
| Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
