Почему даже в википедии запрос на АЗУ бросает на кухню!? Хотя ещё в отцовских книгах справочниках по БИС Запоминающих Устройств за 80-е я читал про загадочное Ассоциативное Запоминающее Устройство. Знаю, есть серии микропроцессоров КР18-каких-то, где есть микросхемы АЗУ. А про современные известно лишь что используются в кэшах процессоров. Неужели они такие дорогие и имеют узкое направление применений, что в обиходе все думают, что АЗУ - моя фантазия? Налево и направо доказываю их существование и объясняю принцип работы. А википедия по сих пор скудна на эту тему. Имеется страница Ассоциативная память однако, но это не прямая ссылка от АЗУ.
а что это по вашему если копнуть глубже красивого имени? простой адресный вектор или матрица проще, дешевле, технологичнее. и емчее. а на них уже може делать се то азу, какое хотите. например, хэш таблицы - тоже вариант ассоциативности. пакеры используют то что можно назвать ассоц. для сокращения объема итд. слово "ассоц." не имеет точного определения
АЗУ - для меня прежде всего вызывает ассоциацию на перцептрон. Просто удивляет, насколько некоторые технологии всё ещё дороги! АЗУ, прежде всего, полезны в словарях для переводчиков. Помнится ещё в Visual Basic 4 я симулировал терминал 78x30 символов графикой. И каждое знакоместо было не просто графикой, а отдельной кнопкой! Перемещения над ними курсора сильно тормозило всю систему. Ладно, потом я исправил всё на блиттинг. Но это заставило задуматься: Система тупо пробегает по всем кнопочкам и ищет, куда указывает мышь! До этого я предполагал комплексный алгоритм группировки кнопок в отдельные кластеры и субкластеры! ) А Вы говорите! Достижения программной стороны облегчают труд инженеров аппаратной. Иначе бы может быть и сигнатуры вирусов сейчас выявлялись на уровне процессора в тех же АЗУ! :-p
у вас интересно мозги работают. вы почемуто всегда выбираете самый замороченный путь нафига вам эти перцептроны? есть разные технологии поиска. для разных случаев разные по подходящести. вот их и разбирайте. там вы найдете столько ассоциативности и скорости сколько надо. а все эти перцептроны - пока только слышно как пытаются сунуть их кругом, но толку от них по сравнению с другими путями пока не заметно.
Думал, погорячился. Однако, если использовать в механизме выявления мусорного кода, то вполне реалистичная теория...
Видать слишком дорогое удовольствие. Возможно разработчикам проще и дешевле реализовать требуемые функции с помощью хэша. На своем опыте знаю пример - производители чипсетов, используемых в недорогих, но производительных коммутаторах некоторых популярных марок, избрали именно такой путь вместо кошерной коммутационной фабрики на ассоциативной памяти.
Я так и не понял, а в чём смысл вашей АЗУ если она реализуется программно на обычном ОЗУ+хэш таблица?
Судя по никам Вашим, которые я таки знаю давно, Вас интересует моё личное отношение? Ладно. Во-первых, отсутствие процессорного кода. Во-вторых, отсутствие специального контроллера. В-третьих, XXI век. Некоторые технологии, так или иначе, обязаны выйти из тени. А главное, мне нравятся такие технологии. Или Вы забыли мои темы: Активная симуляция пассивных элементов, Reversi, Жизнь, Amazing Mechanic, КМОП/ТТЛ, Пассивный и классика - "гвозди"! И зная это, продолжаете хэшировать мои мозги!? ))
Pavia, бывают (хоть и очень редко) задачи, где отказы или задержки из-за хэш-коллизий принципиально недопустимы. Другое дело, что Paguo_86PK ни одной такой задачи не указал. Ассоциативная память никогда не будет сама по себе. Обязательно в составе комплекса, управляемого обычным процессором/контроллером. Раз уж процессор/контроллер есть, в большинстве применений оказывается дешевле сделать все именно на нем. Технологии что для изготовления обычных контроллеров и памяти, что для ассоциативной памяти - одни и те же. Но для последних стоимость чипов будет на порядки выше, не из-за сложности, а всего лишь из-за маленького размера выпускаемой партии чипов. Техноромантик, блин. Оглянитесь вокруг - волчий капитализм на дворе повсюду. Рулит не высокое качество. Рулит приемлемое качество по приемлемой цене. Это ответ на ваш вопрос "ПОЧЕМУ" в первом посте.
Dmitry_Milk таких задач не так мало. и придуманы уже достаточные ответы но в принципе эта задача неразрешима. причина простая - невозможно свести бесконечное к конечному те, коллизии будут и при апаратном исполнении да и если так уперлось, то дешевле и проще будет сделать на многих банках быстрой памяти подключенных параллельно к плис в качестве параллельного обработчика
Paguo_86PK Так или иначе, уже некоторое время некоторые технологиикниги становятся запрещённымизабытыми. Вероятно, исчезают в глубинах корпорации Амбрелла. Принимая во внимание qqwe, становится немного понятнее как оно устроено, но не понятнее для чего и как этим пользоваться, а тем более где используется. Dmitry_Milk Не надо обманываться... Мегакорпорации давно захватили эту планету. В общем всё уже есть, вот только не паблик.
Кстати, зря Вы так про необходимость в контроллере к АЗУ! В справочнике читал, что АЗУ бывают тактируемыми и безтактовыми. Иначе говоря, синхронными и асинхронными, если хотите. В синхронных используется пробег по всем ячейкам с поиском совпадений. В асинхронных - каждая ячейка снабжена схемой сравнения. Они, естественно, дороже. Сейчас завтракал и подумал. Интересно, в АЗУ обычно данные ищутся не побитно, а словами от 8 до 32 и выше бит. А что если организовать АЗУ с произвольным заданием ширины шага в поиске и ширины слова в сравнении? Ещё плюс ко всему, биты маски непроверяемых разрядов! Насколько усложнится вся система поиска в синхронном и асинхронном вариантах? Короче, меня больше всего интересует количественно-качественное соотношение. На сколько ёмкое АЗУ можно построить, используя самые масштабные из доступных ПЛИС!? Вот это - чудовищно интересный вопрос! :-p Известно, что у военных компьютеров архитектуры включают и ПЛИС и АЗУ. Тут сами писали тоже. Однако, задачи, решаемые в тех архитектурах, лишь точечно пересекаются изредка с задачами в бытовых условиях. В основном, это хэши Java и SQL, и т.д. Сейчас вот подумал. Видеокарте куда легче было бы найти кнопку, куда указывает мышь, чем самому процессору пробегать. О чём я выше и писал. При частоте картинки 75Гц получится задержка 13мс, когда процессор мог бы заниматься иными задачами. Пусть программно поиск шёл бы в тысячу раз быстрее, но всё-таки это не та задача, которая обязательно должна влиять на производительность. Видеокарты с аппаратной поддержкой курсора появились относительно недавно. Спрашивается (мною), почему контроллер мыши не сообщается с графической системой непосредственно? Чтобы при перемещении мыши по коврику с перемещением её по экрану не тратился бы и байт программного кода, включая обработчик прерывания! И это включая тень, отбрасываемую указателем, и анимацию песочных часов. А в лучшем варианте, переключение на стрелки при попадании курсора на границу окон! Идиотизм? Нет. Это ... Идеология! Как в UNIX: Делай одну вещь, но делай хорошо! Стоп. Следуя ей, видеокарта должна тупо отображать массив растра в видео сигнал. Верно? Однако. Расширяя горизонт идеологии, следует внести поправку: Делай одну вещь так хорошо, чтобы не грузить своими обязанностями других даже на 1%! Иначе говоря, мышь и видеокарта - переферия, без которой (в серверах) можно обойтись в 99%. А значит, должна быть сеть пересекающихся переферийных устройств с их сообщением непосредственно. Т.е. видеокарта аппаратно связана с мышью не только для перемещения указателя по экрану, но и сам процессор считывает координаты мыши из видеоадаптера, а не с PS/2 / USB! Причём, получая исчерпывающую информацию: В каком окне находится указатель? К какому элементу относятся координаты? и т.д. Индустриально это не задача, как поддержка шейдеров. Я уже говорил, что даже аппаратно, хотя и ограниченно, может поддерживаться. Иными словами, в современной системе центральный процессор должен отдыхать от дурацких задач! В идеале даже при копировании DVD->HDD и прожиге HDD->DVD двум устройствам процессор посылает карту, по которой они сами сообщаются, пересылая нужные кластеры в нужном порядке к DVD или заполняя нужные кластеры потоком данных с DVD. Забегая вперёд, сам скажу, что может быть и клавиатуру к видеоадаптеру подключить, чтобы печаталось быстрее!? ) Понимаю Ваш смех. Однако, всё началось (в этой теме) с АЗУ и я говорю, что меня возмущает то, что огромный потенциал просто незадействован! У меня Radeon 7000, хоть и слаб по нынешным временам. Но для регулярной игры в "Сапёра" и "Реверси" вполне годится! И мне жаль, что некоторую работу выполняет центральный процессор, а не Radeon! Ведь у меня второй используется процентов на 5!
Paguo_86PK Круть! Мы тоже за распределённую многозадачность, но увы, приходиться как-то синхронизировать доступ к данным. и чем большей порцией одна железяка читает данные, тем к большей порции не могут получить доступ другие железяки.
Paguo_86PK объясняю как работает хэш таблица, тк вы тоже ленитесь читать перед тем как писать. самый простейший случай Data* hash_table[MAX_ADDR] = {0}; unsigned Hash(char* k, int len){ unsigned r = 0; for(; len > 0 && *k; len--, k++) r ^= (unigned)*k << (len % (sizeof(unsigned) - sizeof(char))); return r % MAX_ADDR; } void write_data(Key* k, int klen, Data* d){ unsigned addr = Hash(k, klen); hash_table[addr] = d; } Data* read_data(Key* k, int klen){ unsigned addr = Hash(k, klen); return hash_table[addr]; } вот и вся ваша ассоциативная память. зачем ради этого железо мучить? есть и другие системы поиска. почитайте. это интересно.
Что Вы этим хотели сказать? Могли бы поступить ещё проще и не надрываться с Copy-Paste Код (Text): ; ebx = адрес массива ; al = искомый символ xlatb Простейщий алгоритм перекодировки хэша. Или Вы надо мной издеваетесь, либо не понимаете всей тонкости. В Dendy видеоадаптер ограничен количеством спрайтов из-за очень примитивной оссоциативности. Я, по роду хобби, ассоциативностью занимался если не всегда, то тогда, когда в задачах она всплывала. Например: 1) Имеется схема растровой развёртки. Необходимо имитировать векторную графику на лету. Т.е. брать из буфера координаты 1024 векторов и искать те, которым принадлежит очередной пиксел развёртки. 1> Здесь каждая ячейка памяти X1Y1X2Y2 - целая схема арифметических устройств-делителей. Если входящий XY-пиксел лежит на XY1XY2-линии, ячейка отзывается. Причём арифметика устройства - бестактовая! 1. Даже реализация одного ассоциативного вектора (здесь ассоциативность себя с пикселем) имеет значительные затраты аппаратных средств! 2) Ещё в детстве я [o]мечтал[/o] придумать ассоциативные телефонные аппараты, которые включены параллельно и сами различают свой номер. 2> Типичный пример того, что ещё с детства я начинал искать сложные пути! Каждый ТА ассоциирует себя с номером, который набирает вызывающий. Если ассоциация удачна, вызываемый ТА сам звонит и отсылает вызывающему ТА гудки. 2. Пример "честной" (т.к. предпологается, что абонент не перестраивает заводские настройки аппарата для подслушивания) связи без АТС коммутирования. По сути, современный BlueTooth так и работает. Так-как дорабатывая ТА "детства", я бы разложил телефонный вектор по частотам как матрёшку (самая первая цифра - самая высшая поднесущая, вторая - одна из десяти следующей поднесущей, и т.д.). 3) HALT... Вам же лень читать мегапосты ))
Кстати. Года четыре назад пытался придумать процессорное устройство, обрабатывающее не машииный код, а машинный текст. Т.е. дешифратор команд брал 128 бит кода, по первому байту определал класс операции. Все последующие байты должны содержать такой же класс. Искался байт, где цепочка разрывалась. И 128 бит сдвигались влево до места разрыва для следующей дешифрации Код (Text): __INIT; // Init the processor __R13=0xED; // Init system register TestRAM(); // Find the "TestRAM" label, push it for all next calls as associative cell and call __R0="Please wait..."; // Store register as pointer to string Display(__R0); // Find, push and call this function 1__R0=0; // Equal MOV BYTE PTR[R0],0 __R0=1;__R9=15-__R0; // ... __HALT; // End Тем самым, машинный код близок к Си-подобному листингу. Причём одна операция требует от 3-х тактов. Так, R0++ требует один такт на дешифрацию имени и один на дешифрацию инкрементора. А 4R0=0 требует такт на дешифрацию 4R0 (здесь DWORD PTR R0), два такта на "=0" и такт на запись 0 по адресу из R0... В общем, я очень серъёзно тогда этим занимался. Требовалось для начала 16 ПЗУ с прошивкой для дешифрации цепочки. Где каждое ПЗУn+1 несколькими адресными входами подключается к выходам данных ПЗУn для поддержки/разрыва связки символов с одним классом. Получается тот же персер, но безтактовый. Если усложнить до нескольких дешифраторов, можно R0++ дешифровать за один такт. Потребуется увеличения ПЗУ до 32 + 2 сдвигателя до 120 битов влевом с точностью 8 бит. Как ни крути, схема выходила занятная. Требовался ещё механизм предварительной трассировки для построения иерархии программы и расстановки меток в ассоциативной таблице. И всё ради того, чтобы забыть и забить на машинный код. А программировать чисто в Си! Хоть задача и безперспективная. Но занятная, как перцептрон! Интересно, ведутся ли подобные параллельные разработки? P.S.: Потом проект преобрёл новую ветвь развития, когда имена команд сжимались, быстрее и легче дешифровывались, а также легко отображались в редакторе текстом. Например: 41 42 02 41 11 или эквивалент 41 42 41 02 11 означает читать 2 байта (41 42) как число 0x4142 и читать один байт 41 как команду "A".
