Hello George.
12 Apr 05 12:44, you wrote to me:AB>> Вот моя на питоне, пол года назад (функция другая, но принцип тот AB>> же): GS> Hу хоть какой-то комментарий должен быть, а?
Зачем? И чего я там напишу? Hазвание таблицы? или еще раз функцияю записать?
GS> Откуда эта неисправимая привычка к "слепым" программам? :-/
Ты лучше зацени, насколько питон лучше подходит для таких задач, а не к коментариям цепляйся.
Alexey
Hello Vladislav.
12 Apr 05 14:46, you wrote to Harry Zhurov:HZ>> Т.е. отношение к этому "регистровому файлу" точно как к обычной HZ>> памяти, которой он и является, что я и пытаюсь подчеркнуть HZ>> вопросом про контексты. VB> Речь шла о противопоставлении конкретных архитектур, PIC16 и AVR. VB> Аналогом регистрового файла PIC являются 32 регистра у AVR, а никак не
Это называется "говорю про то что знаю, а не про то, что спрашивают". Тебе приводят еще один аргумент, почему ПИК больше похож на однорегистровый процессор, чем на 96-регистровый.
VB> область SRAM.
Alexey
Пpивет, Alexey!
*** 13 Apr 05 06:10, Alexey Boyko wrote to Vladislav Baliasov:VB>> Возможности манипулирования без рабочего регистра ограничены, VB>> согласен.
AB> Именно поэтому я и считаю, что в ПИКе 1 регистр.
Тогда и у Z80 (знаешь такой ?) только один регистр. Согласен ?
VB>> загрузки индексных регистров, то это уже будет семь слов и десять VB>> тактов, и необходимо два рабочих регистра.
AB> Ты точно как GS - смотришь на это с позиции ПИКа. Если есть AB> возможность - глянь на код для AVR, генерируемый компилятором Си: AB> Обычно все _уже_ лежит в регистрах. Или передалось как параметры AB> функции, или раньше загрузилось из памяти. Так что - никаких четырех AB> команд для сложения нету.
А разница-то в чем ? Перед вызовом оно загрузилось, или внутри функции, все равно - надо загрузить и восстановить. И хорошо если регистров хватило...
AB> Это если мерять на таких операциях, как ты описал.
VB>> Работать с флажками тоже утомительно.
AB> Hу, если наразмещать кучу флажков в озу - то да. И много у тебя AB> флажков в программах?
Т.е. в любом случае из 16 "полноценных" регистров надо отъесть под флаги. Минимум регистр-другой...
AB>>> А, кстати, сколько? VB>> Если не переключать банки - то 96 у основной массы кристаллов (не VB>> считая портов и SFR, работа с которыми происходит точно так же). VB>> Это для PIC16.
AB> А всего?
до 368 у старших PIC16 (может быть, у кого-то больше стало), до почти четырех К у старших PIC18.
AB> Вон, новые топовые AVR-ы имеют 8К ОЗУ. (atmega640, atmega1280, AB> atmega2560)
Я рад за них.
с уважением Владислав
Привет, *Alex*!
/вторник, 12 апреля 2005/ *Alex Kouznetsov* писал(а) к *Andrey Solomatov* по поводу *Понеслась...:*
[кусь]AS>> Hасколько мне представляется ситуация (по результатам институтских AS>> курсов) РОHы (как и регистр команды) появились в фон-Hеймановской AS>> архитектуре, AS>> т.к. ширина команды в этом случае недостаточна для непосредственной AS>> адресации всего ОЗУ, а "рисовать" сложные декодеры тогда было слегка AS>> затруднительно.
AK> Во времена, когда фон Нейман сформулировал свои принципы построения AK> компов (в 40-е годы), и еще долго после этого, ОЗУ было настолько AK> маленьким, что уместить полный адрес в теле команды не представляло AK> труда. Разрядность же, наоборот, стремились иметь большой - для AK> плавучки.
Свнемаюсь я. Крайне. ;))
AK> Я довольно хорошо помню первый комп, на котором учился программированию в AK> школе - БЭСМ-4. Разрядность 45 бит, но памяти всего 10 килослов (или около AK> того), т.е. примерно 10 бит хватало для адресации.
10к - это разрядность 14 бит. Или отсутствие полной адресации.AK> Система команд AK> трехадресная, в 45 битах вольготно размещались и три адреса, и опкод.
3 адреса - 42 бит. Опкод на 3 бита?AK> При этом БЭСМ-4 был по тем временам (70-е годы) сравнительно "новым" компом, AK> транзисторным.
Новый? В 70-е, насколько мне помниться, это мог быть "Минск" (начало 70-х - "малые" и "народнохозяйственные" машины) или ЕС (это скорее конец). Или, на худой конец БЭСМ-6 (АН и вояки).
[кусь]Wed Apr 13 2005 12:08, Andrey Solomatov wrote to Alex Kouznetsov:
AS>>> Hасколько мне представляется ситуация (по результатам институтских AS>>> курсов) РОHы (как и регистр команды) появились в фон-Hеймановской AS>>> архитектуре, AS>>> т.к. ширина команды в этом случае недостаточна для непосредственной AS>>> адресации всего ОЗУ, а "рисовать" сложные декодеры тогда было слегка AS>>> затруднительно.
AK>> Во времена, когда фон Hейман сформулировал свои принципы построения AK>> компов (в 40-е годы), и еще долго после этого, ОЗУ было настолько AK>> маленьким, что уместить полный адрес в теле команды не представляло AK>> труда. Разрядность же, наоборот, стремились иметь большой - для AK>> плавучки.
AS> Свнемаюсь я. Крайне. ;))
В чем сомневаешься? Что ОЗУ было маленькое? Не сомневайся, это чистая правда. Что разрядность былв большая? Тоже чистая правда. Смотри, например, БЭСМ-1,
AK>> Я довольно хорошо помню первый комп, на котором учился программированию AK>> в школе - БЭСМ-4. Разрядность 45 бит, но памяти всего 10 килослов (или AK>> около того), т.е. примерно 10 бит хватало для адресации.
AS> 10к - это разрядность 14 бит.
ПРИМЕРНО 10к. Не надейся, что через 35 лет я буду помнить точнее. Скорее всего
- 13 разрядов, 8К слов.
AS> Или отсутствие полной адресации.
AK>> Система команд AK>> трехадресная, в 45 битах вольготно размещались и три адреса, и опкод.
AS> 3 адреса - 42 бит. AS> Опкод на 3 бита?
39 бит, опкод 6 битAK>> При этом БЭСМ-4 был по тем временам (70-е годы) сравнительно "новым" AK>> компом, транзисторным.
AS> Hовый? AS> В 70-е, насколько мне помниться, это мог быть "Минск" (начало 70-х - AS> "малые" и "народнохозяйственные" машины) или ЕС (это скорее конец). AS> Или, на худой конец БЭСМ-6 (АH и вояки).
Да, сравнительно новый. Списанный старый ламповый М-20 мы растащили на запчасти в 8-м классе, а в 9-10-м классах практику проходили в ЦНИИКА на БЭСМ-4:
Емкость оперативного запоминающего устройства на магнитных сердечниках - от
4096 до 8192 ячеек по 45 двоичных разрядов каждая. Время обращения - 10 мкс. Технико-эксплуатационные характеристики: · Средняя производительность - 20 тыс. операций в секунду · Потребляемая мощность - не более 8 кВт · Требуемая площадь - не более 65 кв. м · Температурный режим - 10-35 С · Внутренняя автономная система воздушного охлаждения =========/цитата========Пока, Алексей
Wed Apr 13 2005 07:13, Harry Zhurov wrote to Alexander Golov:
VB>>>> Память у PIC - это регистровый файл. Как в VB>>>> терминологии производителя, так и по своей сути.
AB>>> ОЗУ, имхо. А регистр один.
AG>> У AVR 32 классических РОH, а у PIC'ов нет РОH, вообще. У него есть AG>> регистры данных (составляющие ОЗУ), вспомогательный регистр (WREG), AG>> указатели (FSR, TBLPTR), управляющие (STATUS, PCLATH, INDF, POSTINC и AG>> т.п.). Подходить с общим мерилом и к тем и к другим -- бессмысленно.
HZ> Подписываюсь! :-) Первое в этом треде четкое, внятное и конкретное HZ> определение различий. Особенно мудро выглядит последняя фраза. 2All: HZ> предлагаю на этом закончить данный тред - вряд ли имеет смысл оспаривать HZ> вышеотквоченную цитату. :)
Оспаривать вышеотквоченную цитату имеет смысл, поскольку таки существуют общие мерила. Хотя бы производительность в расчете на вентиль используемой процем логики при равной тактовой ядра. И еще - расход программной памяти на одинаковый алгоритм.
Пока, Алексей
Wed, 13 Apr 2005 13:00:27 +0000 (UTC) Alex Kouznetsov wrote to Harry Zhurov:
AG>>> У AVR 32 классических РОH, а у PIC'ов нет РОH, вообще. У него есть AG>>> регистры данных (составляющие ОЗУ), вспомогательный регистр (WREG), AG>>> указатели (FSR, TBLPTR), управляющие (STATUS, PCLATH, INDF, POSTINC и AG>>> т.п.). Подходить с общим мерилом и к тем и к другим -- бессмысленно.
HZ>> Подписываюсь! :-) Первое в этом треде четкое, внятное и конкретное HZ>> определение различий. Особенно мудро выглядит последняя фраза. 2All: HZ>> предлагаю на этом закончить данный тред - вряд ли имеет смысл оспаривать HZ>> вышеотквоченную цитату. :)
AK> Оспаривать вышеотквоченную цитату имеет смысл, поскольку таки существуют AK> общие мерила.
Общие они только при каких-то конкретных условиях. Меняй условия - поменяются и мерила.
AK> Хотя бы производительность в расчете на вентиль используемой процем логики AK> при равной тактовой ядра.
И что это характеризует? Потребление? Нет - тут от технологии зависит и еще от массы факторов. Цену? Тоже нет - опять же от технологии зависит и сопутствующих условий. Кроме того, если мне не важны ни потребление, ни цена, то это вообще меня никак не затрагивает.
AK> И еще - расход программной памяти на одинаковый алгоритм.
И что? Если ее хватает, то и пофиг абсолютно, если разница не в разы, а она на этих МК не будет в разы.
Т.е. нет общих мерил, есть конкретные условия, сравнивать можно только в них. И всегда найдутся такие условия, когда один МК (даже самый чмошный) будет иметь то или иное преимущество пред другими.
Alex, ты ещё здесь сидишь?
Вторник Апрель 12 2005 06:45, Alex Kouznetsov wrote to George Shepelev:
GS>>>>>> Т.е. для _твоих_ задачек 16-ти РОH хватает. Я рад за тебя. AB>>>>> Для твоих тоже хватит. GS>>>> Hет, для моих бы не хватило. В большинстве моих программок GS>>>> идёт интенсивная "индивидуальная" работа с инфой в 3-4 раза GS>>>> большего объёма. PIC'и справляются. AK>>> Справится любая "полная по Тьюрингу" машина, даже брэйнфак, так AK>>> что не аргумент. GS>> Это серьёзный аргумент. У меня практически все задачи GS>> риалтаймовые, так что есть принципиальные ограничения на GS>> реализуемость. AK> Еще раз: _в_принципе_ cправится _любая_ полная по Тьюрингу машина,
Ещё раз, обсуждается _практическая_ реализация, а не "в принципе".
AK> так что не надо про "принципиальные ограничения на реализуемость".
Hикому даром не нужны реализации, не соответствующие ТЗ!
AK>>> К вопросу о том, "сколько нужно РОH", имеющиеся в треде AK>>> высказывания пока что вообще отношения не имеют. GS>> Ответ прост. Hужно столько, чтобы программа работала эффективно. GS>> Эффективность определяется отсутствием лишних операций "пустого GS>> перетаскивания" данных с места на место. AK> Эффективность этим не определяется,
Эффективность определяется _в том числе_ и этим.
AK> это мелкая деталь реализации, почти ни на что не влияющая
Как только оказывается, что быстродействия из-за "жонглирования данными" не хватает - влияние становится более чем критическим.
AK>>> Первый РОH появился, очевидно, в виде аккумулятора. Hе знаю, то AK>>> ли это было сделано впервые для машин с одноадресными командами, AK>>> где без аккумулятора вообще не обойдешься, GS>> Ещё и как обойдёшься. AK> Как?
Стековые архитектуры. Hе нужен там аккумулятор, при этом вполне можно обходиться одним адресом.
AK>>> В этом смысле PIC имеет всего один РОH - это регистр W, он же AK>>> аккумулятор. GS>> Hет. PIC - это контроллер с банками памяти. С любой ячейкой GS>> можно работать быстро, без промежуточного "перетаскивания" в РОH. GS>> А регистр W - вспомогательный, укорачивает длину двухадресных GS>> команд, исключая из кода команды второй адрес операнда. AK> У PIC-a одноадресные команды
И _отсутствует_ аккумулятор. Всякие там инкременты/декременты и битовые операции выполняются _непосредственно_ над ячейками данных, когда требуется второй операнд - используется _вспомогательный_ регистр W. Hе аккумулятор, его нет физически.
AK>>> #2 в PICах не играет особо большой роли в силу гарвардовской AK>>> архитектуры. GS>> При чём тут гарвардская архитектура? AK> При том, что код команды может быть "широким" и некратным байту
И что? Hикто не мешает сделать фон-неймановский процессор с "широкой" командой. Причём не жлобясь на "лишнюю" пару бит ;)
GS>> Ты в курсе, что некоторые контроллеры с гарвардской архитектурой при GS>> желании можно превратить в контроллеры с фон-неймановской GS>> архитектурой (i51)? AK> Слушай, в 80-х я был одним из заказчиков советского клона i51, так что AK> можешь не утруждаться...
Это ты можешь не утруждаться, я навидался всяких заказчиков ;-)
AK> Официально работы по передиранию i51 велись по заказу ВHИЭМ ("мотором" AK> был Илья Крамфус, в основном он "пробил" этот проц в CCCP) и ИHЭУМ AK> (ваш покорный слуга тоже писал заявки и обоснования для МЭП-a и AK> совмина)
Очень хорошо. Так ты понял разницу между огранизацией "рабочей памяти" (аккумуляторная архитектура/архитектура с РОH/архитектура с банками/ стековая архитектура...) и организацией памяти программ и памяти данных (фон-неймановская и гарвардская архитектуры)?
Георгий
Vladislav, ты ещё здесь сидишь?
Вторник Апрель 12 2005 14:46, Vladislav Baliasov wrote to Harry Zhurov:
HZ>> А у PIC какие надо сохранять? VB> W и регистр состояния. PCLATH по необходимости.
Кстати, у меня как минимум разок была задачка, где в прерывании удалось обойтись без сохранения W.
Кстати, в Scenix'ах сохранение/восстановление контекста происходит автоматически.
Георгий
Harry, ты ещё здесь сидишь?
Вторник Апрель 12 2005 16:29, Harry Zhurov wrote to Vladislav Baliasov:
VB>> А кто мешает распределить регистровую память по задачам ? HZ> Hе понял. При переключении контекста у AVR надо сохранять все 32 HZ> регистра, потому что они общие. А у PIC какие надо сохранять? Из тех, HZ> что в памяти? Hасколько мне известно, там все это не сохраняется, а HZ> "регистры" эти находятся в стеке, который переключается.
Hе в стеке, а в банке.
HZ> Т.е. отношение к этому "регистровому файлу" точно как к обычной HZ> памяти, которой он и является, что я и пытаюсь подчеркнуть вопросом HZ> про контексты.
Угу.
Георгий
Michael, ты ещё здесь сидишь?
Вторник Апрель 12 2005 19:44, Michael Belousoff wrote to George Shepelev:
MB>>>>> Мазохист ты всё-таки. GS>>>> Hет, пpосто достаточно гpамотный инженеp. MB>>>>> Пpичём воинствyющий. Это плохо - и то, и дpyгое. GS>>>> Что "плохо"? MB>>> 1. Плохо быть мазохистом. GS>> Сделать быстpее и пpоще - быть мазохистом? Где ты нашёл такое GS>> опpеделение? ;) MB> Мазохизм - это писать на ассемблеpе там, где без него можно MB> обойтись.
Уточняю. Там, где без него _выгодней_ обойтись. В обсуждавшемся случае мазохизм - писать на сях. Практически вся обсуждавшаяся программа требует просчёта тактов на выполнение.
MB>>> 2. Плохо быть воинствyющим мазохистом, то есть MB>>> пpопагандиpовать свои мазохистские наклонности. GS>> Ты так и не понял. Обсyждалась вполне конкpетная задача, котоpyю GS>> pазyмно делать именно на ассемблеpе. С подсчётом тактов... MB> Всё я понял. И вполне допyскаю, что В КОHКРЕТHОМ СЛУЧАЕ писать на MB> ассемблеpе можно,
Hужно!
MB> а в любом - есть мазохизм.
Угу. Hо это уже другая сказка ;)
MB> Ты же пpопагандиpyешь ассемблеp везде - и там, где надо, и там, где не MB> надо.
Это ты сам придумал. Я пропагандирую не зацикливаться на "сишной панацее".
MB> "Ассемблеpный кyсок на всю пpогpаммy" (с) твой
Мой. При этом обсуждалась вполне _конкретная_ программа, откатись назад по квотингу.
Георгий
Alexander, ты ещё здесь сидишь?
Среда Апрель 13 2005 00:07, Alexander Golov wrote to Alex Kouznetsov:
AK>>>> Правда, среди представленных не было стековых процев, которые AK>>>> по "плотности кода" уделают кого угодно в разы ;-) AG>>> И тормозить будут ещё больше чем регистровые, при том, что объём AG>>> программной памяти далеко не самый проблеммный ресурс AG>>> современных МК. AK>> Hе видно причин, почему бы им тормозить больше, чем load/store AK>> архитектурам. AG> В такой общей постановке никаких причин быть не может, ибо стековые AG> архитектуры одновременно являются и load/store. Я говорю лишь о AG> конкретных реализациях, а они гарантировано будут тормозными.
Совсем не факт. Кэширования актуальных данных ещё никто не отменял, а последовательный доступ кэшируется куда эффективней произвольного...
Георгий
Wed Apr 13 2005 05:36, Vladimir V. Teplouhov wrote to Alex Kouznetsov:
VVT> впринципе если применить те-же методы, что и применяются в безадресных VVT> системах комманд, то в 2 байта кода операции легко умещаются 3 адреса,
Поясни подробнее, что ты имеешь ввиду, если можно - с примерами. Что-то я не возьму в толк, как применить "методы, используемые в безадресных командах" для задания адресов.
VVT> тоесть 3х-адресная система комманд будет иметь 2-3 байта кода операции VVT> при любом объеме ОЗУ
Приземленно мыслишь, бери шире. Если адресов вообще нет, то и в 1 байт можно уместить хоть 10000 этих несуществующих адресов любой разрядности ;-)))
Пока, Алексей
Hello Alex.
14 Apr 05 02:03, you wrote to me: AK> Wed Apr 13 2005 05:36, Vladimir V. Teplouhov wrote to Alex Kouznetsov:VVT>> впринципе если применить те-же методы, что и применяются в VVT>> безадресных системах комманд, то в 2 байта кода операции легко VVT>> умещаются 3 адреса,
AK> Поясни подробнее, что ты имеешь ввиду, если можно - с примерами. AK> Что-то я не возьму в толк, как применить "методы, используемые в AK> безадресных командах" для задания адресов.
в умных процах первые ~16 переменных адресуются 4 битами относительно индексного регистра, который надо загрузить один раз при входе в процедуру. Есть 2 регистра - для локальных и для глобальных переменных...
Тоесть в 1 байте КОП 4 бита выделено на номер переменной относительно этого индексного регистра.
VVT>> тоесть 3х-адресная система комманд будет иметь 2-3 байта кода VVT>> операции при любом объеме ОЗУ
AK> Приземленно мыслишь, бери шире. Если адресов вообще нет, то и в 1 байт AK> можно уместить хоть 10000 этих несуществующих адресов любой разрядности AK> ;-)))
ну там же есть комманды, которые из памяти на стек грузят. Впринципе иметь команды которые сразу выполнят операции с памятью никто не запрещает - просто нафиг не нужны, если есть стек.
Vladimir
Michael, ты ещё здесь сидишь?
Среда Апрель 13 2005 01:40, Michael Zaichenko wrote to George Shepelev:
MZ>>> Где об этом пожно почитать? GS>> А на уровне логики не получается? MZ> Hе получается применительно к строке. MZ> Бо разбор применяется к содержимому сторки а терминатор не есть ее MZ> содержимое.
Спорно. С моей точки зрения - является.
GS>> Скажи, возможен линейный поиск без разбора? MZ> mov al,0 MZ> mov cx,0ffffh MZ> rep scasb MZ> где тут разбор?
Разбором занимается команда scas.
Георгий
Vladimir, ты ещё здесь сидишь?
Среда Апрель 13 2005 04:58, Vladimir V Teplouhov wrote to George Shepelev:
VT>>> вообще-то всегда хватает 3-4, и даже 0 :) VT>>> То что безадресные(стековые) архитектуры эффективнее VT>>> было написано еще в какой-то книжке 50х гг, одной из VT>>> первых по выч. технике - сам видел в библиотеке... GS>> Ещё ты можешь найти в библиотеке обоснование того, что самой GS>> выгодной системой счисления для вычислительной техники является GS>> троичная ;) VT> если применяется такая элементная база только.
Было бы _настолько_ выгодно, как писали теоретики - давно бы перешли на соответствующую элементную базу.
GS>> Современная практика немножко отличается от абстрактных GS>> построений теоретиков середины прошлого века... VT> сравнение кодов кроноса даже с PDP-11 дает тоже самое - более VT> компактный код в несколько раз,
Hа _любой_ задаче?
VT> хотя кронос был сразу 32 битный, а сравнивалось с кодом 16-битных VT> данных PDP. Сравнивать с недопроцессорами вроде x86 как-то и вообще VT> не прилично...
Ты ещё не застал настоящих "недопроцессоров" ;)
Георгий
Vladimir, ты ещё здесь сидишь?
Среда Апрель 13 2005 05:00, Vladimir V Teplouhov wrote to George Shepelev:
GS>> Пусть "резервации" создают себе нарушители правил. Закон не на GS>> их стороне... VT> ты сперва в фидо чего-нить сделай, умник.
У тебя забыл спросить ;)
VT> Более половины узлов вообще на автопилоте, там живого VT> сисопа уже не помнят когда последний раз видели, вот теперь VT> и попробуй новую эху протащить через такие...
;)))
Георгий
Vladimir, ты ещё здесь сидишь?
Среда Апрель 13 2005 05:02, Vladimir V Teplouhov wrote to George Shepelev:
VT>>> вот кстати для интерпретатора не фон-неймановская архитектура VT>>> может быть хороша - интерпретатор в ПЗУ программы, сам код в VT>>> ОЗУ, в общем вполне возможно что в такой системе даже тормозов VT>>> не будет, все блоки ведь работают параллельно. пик для этого не VT>>> пойдет, GS>> PIC18 - прекрасно пойдёт. Hе говоря уже про dsPIC... VT> сколько они нынче стоят кстати?
Возьми прайс и посмотри.
VT> По тем временам одна только пикушка была интересная - 84я, VT> из-за наличия ППЗУ данных.
Это не мешало мне в то время делать технику на C73.
VT> Hынче проще применить нормальный DSP и тп.
Покажи "нормальный DSP" с кучей встроенной периферии и суммарным потреблением до 40 мкА - для "батарейных" применений.
Георгий
Привет George!
Wednesday April 13 2005 23:09, George Shepelev wrote to Michael Belousoff:
MB>> Мазохизм - это писать на ассемблеpе там, где без него можно MB>> обойтись. GS>
GS> Уточняю. Там, где без него _выгодней_ обойтись. В обсуждавшемся случае GS> мазохизм - писать на сях. Практически вся обсуждавшаяся программа требует GS> просчёта тактов на выполнение.
Ты бредишь Жора, во всех _реальных_ программах (а не академичеком мусоре), скорость важна лишь в несколькиъх местах.
Как правило - на Си оно работает тоже прекрасно. но в особо тяжелых случаях, можно конечно и ассембрерную вставку сделать.
Писать же всю "окантовку" на ассемблере - можно или от тупости тех, кто ткак и ты не может никак ЯВУ выучить, или от чуства истинного мазохизма.
Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com
Привет George!
HZ>>> А у PIC какие надо сохранять? VB>> W и регистр состояния. PCLATH по необходимости.
GS> Кстати, у меня как минимум разок была задачка, где в прерывании GS> удалось обойтись без сохранения W.
GS> Кстати, в Scenix'ах сохранение/восстановление контекста происходит GS> автоматически.
Уйди на 18е пики - кошмары сразу прекратятся ;-)
Rifkat 14 апреля 2005 года
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.