Придумай инструкцию x86!

Я бы очень хотел инструкцию div34subt которая делит eax на 34, результат помещает в eax, остаток в edx и вычитает из eax edx при взведенном TF

 

Я на полном серъёзе!
Вот например, словари-переводчики работают как? Берут одно слово, ищут его в базе корней, например. А это - сотня тысяч слов! И каждый раз при несовпадении производят "откат" искомого. В итоге, чтобы пропахать весь словарь, требуется выполнить как минимум в десятки раз больше циклов, чем в случае с Ассоциативными ЗУ (АЗУ).
Регулярные выражения - примерно те же АЗУ. И в 80-ых, в номенклатуру некоторых процессорных серий входили АЗУ.

А вы, честно говоря, говорие откровенную чушь и зря смеётесь...

Например, при движении мышью, чтобы узнать, над каким объектом она находится, требуется прогуляться по всем деревьям "родитель-дитя", а это требует тоже ресурсов.
АЗУ лежит в основе многих серъёзных (читай Военных) процессорных комплексов.
А в Пентиумах - лишь в недоступном программно кэше...

 

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

 

Это вы о чём? Это вы к чему?
Если про аппаратные сложности реализации регулярных выражений, то вот XML-язык аппаратно давно поддерживается.
И к чему такой консерватизм?
Если мыслить по вашему, то зачем контроллер клавиатуры - однокристалльный? Ведь его не сложно реализовать дискретными чипами! :-D
Помните ПДУ в советское время уже делали на однокристалльной ХЛ помоему?
На мой взгляд, всё, что делается часто и не имеет постоянного развития (как DivX вон, развивается, но всё же аппаратно поддерживается), подлежит аппаратизации.
Для серверов сетевых регулярки - претедент на аппаратизацию. В графике - функция вычисления точки пересечения прямых. В звуке - ...

Друзья, вы узко мыслите. Вам нельзя при таком мышлении даже при возможности идти в разработчики Atari, Yamaha, Amigo, C64. Именно эти машины многое изменили в своё время и их критиковали, говорили "что-то здесь слишком много микросхем..." или типо того.
Однако сейчас видеопроцессоры умеют в тысячи раз больше, чем тогда достаточно смелые достижения.
И не надо тут мне читать нотации, сколько сложностей во всём этом. Я и так понимаю, смотря на программные реализации. Но это же работа инженеров! Не так ли?
Или...

Консерватизм рулит?

 

Oднозначно было бы хорошо иметь умножение двоичных полиномов и умножение полиномов с приведением по модулю. Схемотехнически это гораздо легче чем уже имеющееся обычное умножение (XOR вместо сложения).

 

Paguo_86PK

у меня есть хт из первых. так там микрух куда как больше. и что?

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

 

Я бы добавил =)
1) Выполнение invalid opcode (сделать обработчик инвалидных инструкций , расширить процессорные возможности)
2) сброс всех регистров общего назначение в НУЛ стэнд позишн(вместо того чтобы все их чистить )
3) Прочитать и при ошибки чтения самоочиститсься , для мемори чтения команд
4) Перейти в МикроВыборочный режим , смена режима работы микро кода
5) Не выполнять команду по условию , это избавит от прыжков , а просто по условию отменит выполнение следующей команды или нескольких


)))))))))))) юмор есть везде а в юморе есть правда

DWIM Do What I Mean
DWIT Do What I'm Thinking
EA Enable Anything
EPP Eject Printer Paper
GREM Generate Random Error Message
JFM Jump on Full Moon
JBS Jump and Blow Stack
JOM Jump Over Moon
JPA Jump when Pizza Arrives
LMYB Logical MaYBe
RJE Return Jump and Explode
SFP Send for Pizza
ULDA UnLoaD Accumulator

 

Хы. Сталкивался и с этим. Разрабатывал "эзотирический процессор". Одну всего инструкцию выбросил, как алгоритмы под него стало невозможно писать! Друг тогда ещё спросил, знаю ли я о пределе простоты?

У меня две XT-мамки. И что? Не сравнивайте XT с C64/Amigo/Atari/Apple... XT разработали тяп-ляп(читайте историю), остальные же - тщательно продумывали. Графика была цветной и звук с FM-синтезом и сэмлированием. А XT тогда могла лишь пищать по крысячи, да монохромно выводить текст в MDA...

Нафиг я буду разрабатывать схему разбора регулярок Это задача тех, кто придумал сам язык регулярок. Ведь XML аппаратно поддерживается, и EBML есть...
Я просто удивился, что нет упоминания о аппаратном разборе регулярок. А ведь они...
Короче...

 

Paguo_86PK

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

вод так всегда. как задания выдумывать, так все герои, а как сделать чтото, так

а кто его придумал? и когда? вы, наверно, думаете, что регулярные обработчики для перла, питона, авка, ви, ед, греп.. и прочей кучи писал один человек, которому делать нефик только писать их каждому, кто скажет, что "он должен"?

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

 

Разве не Вы это написали в соседней моей теме?
Зачем я буду разрабатывать то, что уже наверно где-то и кем-то разрабатывается!?

А я читал обратное. Мол коллектив энтузиастов в IBM решил собрать машину на базе i8086, а само управление компании даже и не подозревало. И с лёгкой руки кинули на конвейер -> продажу.
Потому в PC так много просчётов, которые сейчас очень хорошо дают о себе знать...
Та же история, что и с MS-DOS, которую писали "впопыхах"...
Я этих историй начитался. Удивительно что Вы не знаете

Так не я же придумал регулярки. За то читаю, что некоторые сильно загружают проц и подумал "а как же аппаратно?"...

Ничего я не думаю. Просто регулярки - одна из серъёзных основ.
Пусть хоть ИИ, криптография, распознавание и перевод текста или антивирусы

Хм... Я сейчас пишу парсер в JS. Вначале листинг он разбирал сам, дискретным текстом JS. Но потом я вспомнил про регулярные выражения и попытался их задействовать. Из парсера своего выкинул целых 50 строк! Упростился значительно короче.
Но вот в доке про регулярки всё пишут "требует значительных ресурсов" и подумал: А неужели аппаратно не поддерживается?

А вы заладили: Пробуйте сами!
Мне это не надо. Просто праздный интерес. Почему когда-то серверы оснащали Itanium-процами, но они не имели аппаратных механизмов разбора регулярок?
Типо Реклама "Серверы на базе процессора РегОнФлай, с аппаратной поддержкой регулярок"!

Ведь некогда MMX и 3D-Now! появились для облегчения мультимедиа - игровой индустрии. Цацки-пуцки-игрушки. Ради них ввели набор спец инструкций.
А ради серверов не вводят даже микрокодовое расширение для разбора регулярок. Но это куда серъёзнее шейдеров в видяхах под тупые игры.
Не справидливо же!
Вот о чём я!

А вы опять пытаетесь меня застукать за очередным гвоздём в кинескоп

 

Вот я о том же. Только на данный момент позволил ограничиться тем, что существует давно! Но поддержки не имеет...

 

Paguo_86PK

И сколько у вас осталось инструкций? Может там было много лишних, поэтому программу сложно было писать? А вы знаете что существуют наборы команд всего из одной инструкции?

 

Тебе уже доходчиво объяснили: сначала напиши простейший компилятор "строка" -> "скомпилированное регулярное выражение" БЕЗ динамического выделения памяти, а потом посмотри, чего ты хочешь от проца. Регулярное выражение - это тебе не структура постоянной длины, его размер не определён.

 

Судите сами, я его представлял на суд.

Дык, зачем? Готовые библиотеки есть!
Разрабатывал я уже алгоритмы флуда геометрических фигур без стека... Когда 17 лет было...

 

Ну ОК, уговорил: возьми исходники этих библиотек и переведи на verilog ну или транзисторную логику. Да так, чтобы без всяких переполнений буферов и ограничений было!

Всё равно для реализации флуда требуется какая-то память для сохранения состояний, так как это не stateless-алгоритмы.

 

Заставка 3D-Лабиринт Windows: Напоровшишь на стенку, всё время поворачивай в одну сторону - обойдёшь весь лабиринт.
У меня флуд-алгоритм работал примерно также: Флудил линию до границы, оставляя один-два пиксела не залитыми, чтобы обойти и залить тот участок, а через "коридор" в один-два пиксела вернуться, заливая его. Принцип лабиринта и нужно помнить лишь координаты X,Y текущие и направление.
Я его разрабатывал для аппаратной реализации 12 лет назад... Ещё на К531ИЕ17...

 

зависит.

 

Предлагаете данную фигуру попробовать залить моим алгоритмом?
Хорошо, будет время, переделаю его под javascript и средствами canvas-графики залью на глазах...

 

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

 

А с такой фигурой он справится (заливка жёлтой области)?
А если сравнить по скорости работы со stateful-алгоритмом?