_Loader_

Hello, Ilia Tarasov !

üÔÏ ×ÏÏÂÝÅ ÎÅ ÅÇÏ ÚÁÄÁÞÁ. ðÏÄÁ×ÌÑÀÝÅÅ ÂÏÌØÛÉÎÓÔ×Ï ÒÁÚÒÁÂÏÔÞÉËÏ× × ÏÄÉÎ ÄÅÎØ ÏËÁÖÅÔÓÑ ÎÁ ÕÌÉÃÅ, ÅÓÌÉ ÒÕËÏ×ÏÄÓÔ×Ï ÕÚÎÁÅÔ ÞÔÏ ×ÍÅÓÔÏ ÒÅÛÅÎÉÑ Ó×ÏÉÈ ÚÁÄÁÞ ÏÎ ÓÁÍÏÄÅÌØÎÙÅ ËÏÍÐÉÌÑÔÏÒÙ ÐÉÛÅÔ.

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Sun Oct 05 2003 09:05, Roman Khvatov wrote to Ilia Tarasov:

IT>>>> Представим, что действительно все (ну или почти все) команды в IT>>>> исходном алгоритме зависимы по данным. RK>>> Так практически не бывает. IT>> y=sin(sqrt(abs(2*x))) Что здесь независимого?

RK> И это вся программа? Или в ней есть еще что-то? Вот это 'что-то' и будет RK> 'независимым'

Формально согласен. Добавлю, развивая тему, что данное вычисление занимает большую часть времени... Тогда какая, по большому счету, разница, на сколько процентов медленнее будут выполняться куски, и так занимающие малую часть кода?

IT>> Hапример, алгоритмы цифровой обработки часто сводятся к умножению с IT>> накоплением. Представим, что перемножитель один, и является, IT>> соответственно, узким местом. Что в этом случае можно распараллелить?

RK> Можно разделить умножаемый массив на 2 подмассива (с четными и нечетными RK> индексами), и умножать с накоплением эти половины отдельно, потом RK> результаты сложить, тогда 2 этих цикла умножений можно параллелить.

Не понял... Устройство умножения всего одно, что можно параллелить? Допустим, что накладные расходы на подготовку операндов равны нулю, они могут подаваться на вход АЛУ каждый такт (с автоинкрементом адресов). Что здесь можно еще запараллелить, если за такт может появиться только один результат умножения?

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

RK> Все вышеизложенное относится _именно_ к таким процессорам. Для обычных RK> процессоров (не суперскаляров) Форт процессор не будет уступать по RK> производительности.

Fixed. А Форт-процессор с запараллеленными стеками?

IT>> Когда есть надобность параллелить - таки фатально. Hо скажи, зачем мы IT>> пойдем направо, если знаем, что надо налево?

RK> Еще раз повторяю - когда нужно добится топовых скоростей, тогда и нужно RK> параллелить.

Fixed.

Кстати, я предпочитаю в таких случаях параллельный КА, и Форт-процессор, выполняющий настройку перед блочной конвейеризованной обработкой....

IT>> Кстати, завести именно пару стеков - не самоцель. А один стек IT>> возвратов и несколько стеков данных, работающих в параллель? (Идея, IT>> кстати!)

RK> Интересно, если объединить в один 3 плохих процессора, то получится один RK> хороший? Или все таки лучше объединять 3 хороших процессора :)

Конечно, 3 хороших :) Например, стековая архитектура на FPGA Xilinx дает ровно в 16 раз больший объем стековой памяти на тех же ресурсах... ;)))

RK>>> А это дело компилятора, обычно они неплохо справляются не только RK>>> со стековыми машинами :) IT>> А компилятор - это такая программка, которая ставится с IT>> компакт-диска?

RK> Угу.

Ну, кому как. Согласен, для подавляющего большинства разработчиков разработка собственного компилятора - далеко не первоочередная задача.

IT>> :) И она безглючна, бесплатна, осваивается в момент доставания диска IT>> из коробочки?

RK> Тебе шашечки или ехать? Хочешь получить производительность - покупай RK> компилятор (или пиши на асме, если в запасе есть неограниченное время :)

Мне - ехать с шашечками... :) Вот я обычно начинаю на асме, но использую ряд приемов кодирования, позволяющие писать слова "второго слоя" в стиле постфиксной стековой машины. Можно заводить переменные, можно пытаться упихать все в регистры... можно имитировать стиль процедурных языков - готовить стековый кадр, а потом снимать результат. Мне вот нравится на асме писать в стиле ЯВУ, и стиль Форта реализуется с наименьшими временными затратами...

RK> Что касается глюков - как ты думаешь, в чем проще исправить глюки, в RK> компиляторе или в процессоре? Или ты думаешь, что процессоры рождаются RK> сами по себе и абсолютно безглючные? И как ты думаешь, в каком процессоре RK> будет больше глюков - в том, который сложнее, или в том, который проще?

Проще исправить глюки в более простой системе. Форт-процессор (как и любой другой) представляет собой разновидность конечного автомата, и проектируется по соответствующим методикам.

RK> (А я уже писал, что Форт процессор будет сложнее аналогичного RISC RK> процессора)

Гораздо проще суперскаляра, и практически эквивалентен обычному регистровому (я пробовал в ПЛИС разные подходы). Удобство стекового процессора с командами, эквивалентными словам Форта, гораздо выше удобства регистрового процессора с тем же объемом ресурсов - для стековой архитектуры сразу готовы все алгоритмы, а для регистровой надо долго думать, как все туда упихать, и не завести ли еще регистр, а то что-то места мало и в память лезть приходится...

IT>>>> Для сравнения рассмотрим 4 симметричных регистра, и добавим к IT>>>> ним пятый. RK>>> Такой же симметричный? IT>> Такой же, или не такой же... не столь важно.

RK> Это важно. Если набор регистров не нимметричный (как в x86), то RK> распределение регистров усложняется (но не фатально)

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

RK>>> Если для задачи хватало 4х регистров - то повышения RK>>> производительности не будет вообще, а если не хватало - то быдет RK>>> весьма значительная.

IT>> Как понять "хватало"?

RK> Это когда компилятору хватало 4х регистров для хранения промежуточных RK> результатов.

(*)

IT>> Это когда в программе только 4 переменные,

RK> Hет

Очевидно. Это была одна крайность.

IT>> или когда зависимость по данным не вызывает простоев конвейера?

RK> Hет.

А как это соотносится с (*)? А вот держи примерчик:

a = b + c + d (1) b = a + d - с (2) c = a + b + 3 (3) d = a + b + c (4)

Налицо WAR при подстановке любой из строк 2-4 после 1.

IT>> Стоит ли делать новый процессор с дополнительным регистром,

RK> Если такая задача только одна, то очевидно не стоит, а если почти все RK> задачи такие - то стоит.

Так будет ли выигрыш - это ведь еще не решено....

IT>> будет ли он иметь лучшее соотношение цена/производительность?

RK> Это надо оценивать. В любом случае для ответа на такие вопросы надо знать RK> примерный круг задач, для которого используют процессор.

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

IT>> И главное, не съестся ли эта добавка общим снижением рабочей частоты IT>> кристалла из-за усложнения схемы?

RK> Опять же надо оценивать реальный процессор, откуда я знаю, как в него RK> врезали 5й регистр?

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

RK>>> Hикак, просто исправить константу в распределении регистров в RK>>> компиляторе. IT>> Hеужели так просто? :)

RK> Если регистры равноправные - то да. Если нет - то степень изменений будет RK> варьироваться от изменения константы до полного переписывания RK> распределения регистров.

Не удержусь от цитатки: "Поиск оптимального назначения регистров переменным представляет собой сложную задачу, с точки зрения математики являющуюся NP-полной. Проблема усложняется ЕЩЕ И ТЕМ [выделено мной, IT], что аппаратное обеспечение и/или операционная система могут накладывать дополнительные ограничения по использованию регистров" (Ахо, Сети, Ульман "Компиляторы. Принципы, технологии, инструменты)

IT>> Hапример, надо в 80x86 сложить что-нибудь с AX. IT>> В какой регистр будем грузить второй операнд: BX, CX, DX?

RK> Тут скорее всего понадобится алгоритм с привлечением динамического RK> программирования.

Skipped & Fixed, ибо мы, имхо, поняли друг друга в этом вопросе...

RK> Я не утверждаю, что Форт никуда не годится. Есть приложения, где он RK> категорически не подходит, а есть, где он имеет преимущество:

RK> Форт процессор категорически не подходит для: RK> 1) Изготовления на его базе top-preformance процессора

В целом соглашусь, и придерживаюсь той же позиции. Стековое ядро мне сейчас очень нравится для реализации embedded-процессоров в ПЛИС, где оно занимает мало места, позволяя при этом писать на ЯВУ для 16-32 разрядов и 20-40 МГц.

RK> Форт процессор подходит для: RK> 1) Применения в качестве процессора для которого ассемблером является ЯВУ RK> (если Форт таковым можно назвать :), при этом имеет значение компактность RK> кода и не имеет значение производительность. (Весьма умозрительный пример RK> :)

Да. Кстати, производительность все же не так плоха, регистровая архитектура не дает существенного выигрыша... если вообще дает его в ПЛИС.

RK> Форт, как система програмирования, подходит для: RK> 1) Платформ, типа OpenBoot (Форт зашит в ПЗУ и служит для загрузки RK> системы). При этом драйвера различных карт (сеть, диск и др.), с которых RK> производится загрузка, написаны на этом самом Форте и зашиты в ПЗУ на RK> этих картах. (Кстати, в спецификации PCI есть перечисление платформ, для RK> которых на PCI картах могут находится драйвера ввода-вывода, это x86 - RK> расширения BIOS'а, и OpenBoot) 2) Платформ, где необходимо иметь RK> интерпретатор для исполнения кода из большой внешней памяти (процессор, RK> типа PIC и AVR плюс большой внешний EEPROM). И то, в этом случае Форт как RK> язык програмирования для этих платформ мало пригоден (из за его RK> необычности), а вот Форт VM вполне пригодна.

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

Sun Oct 05 2003 09:56, Roman Khvatov wrote to Ilia Tarasov:

IT>> Суперскаляр, кстати, не самая эффективная архитектура на сегодняшний IT>> день.

RK> Да, VLIW эффективнее.

Corporaal предлагает еще и TTA. VLIW действительно эффективнее.

IT>> И регистровый либо стековый подход к понятию "суперскаляр" IT>> несколько ортогональны. Стековый процессор тоже может быть IT>> суперскаляром.

RK> Может, но не стековый суперскаляр будет гораздо проще, а преимуществ у RK> стекового процессора перед не стековым (в плане производительности) нет.

ASIC - проще. Софт-ядро в ПЛИС - такое же.

IT>>

Там описание стекового процессора в ПЛИС. IT>> Форт-процессора, если угодно. Что интересно, все операции, которые ты IT>> перечислил, почему-то делаются за 1 такт... :)

RK> Hу и что. RISC тоже все это делает за один такт. Вопрос в том, сколько RK> надо на это аппаратуры. Для RISC понадобится меньше.

Видишь ли, это тоже RISC. Есть классификация CISC/RISC. А есть ряд "суперскаляр - DataFlow - Multithreading - Independence Architectire - VLIW - TTA" (последнее как раз рассматривает Corporaal). Вот эти вещи друг другу несколько ортогональны, но естественно, что сначала нужно от CISC уйти к RISC. Приведенный ряд соответствует разному распределению нагрузки между железом и компилятором по подготовке инструкций к выполнению. Условно говоря, для суперскаляра достаточно написать, из какого регистра в какой передаются данные, а определение зависимостей, переупорядочивание, распределение транспортов по магистралям и привязка к тактам выполняется самим процессором. VLIW не делает почти ничего, кроме распределения транспортов - все остальное надо указать в коде. TTA вообще ничего не делает, позволяя задать в коде все вплоть до порядка соединения внутренних блоков на данном такте. Соответственно, это самая простая архитектура, но сильно нагружающая компилятор. Я как раз и пишу про RTSA - Reduced Set Transport Architecture, которая при сохранении простоты ограничивает все многообразие транспортов стековыми операциями. Хотя теоретически эта архитектура полностью аналогична КА (однако попробуй написать готовый КА на VHDL и сравни с подготовкой фирмвари на ЯВУ для него же унифицированного под набор команд).

RK> Hет. 2 процессора могут одновременно исполнять 2 разных задачи. А RK> суперскаляр с 2мя командами за такт может исполнять одну задачу в 2 раза RK> быстрее. Теперь представим, что в системе в данный момент работает только RK> одна задача - что будет делать 2й процессор на кристале?

Только в случае, когда операции в принципе параллелятся, но по каким-то непонятным причинам они не были распараллелены аппаратно. Вот только недавно ушла разработка со счетверенным вычислителем. Самый настоящий SIMD - стековое ядро формирует команду для счетверенного арифметического блока...

Кроме того, получается несколько другой вывод. Сначала шла речь о двух задачах на одном кристалле. Чем два независимых ядра хуже одного, в два раза большего за счет дополнительных схемотехнических решений, позволяющих параллелить операции? И как тогда понимать Hyper Threading?

IT>> А еще есть TTA (H.Corporaal серию работ написал), которая IT>> представляет IT>> собой дальнейшее развитие VLIW в сторону контроля над микрокодом

RK> Трудно контролировать то, чего нет - у VLIW нет микрокода, это набор RK> RISC'ов, у которых тоже нет микрокода, их для того и сделали из CISC'ов, RK> что бы от него избавится.

Я про микрокод очень условно написал - в каких-то архитектурах он есть, а в каких-то формально отсутствует. Кстати, для PII (по меньшей мере, я смотрю справочник в приложении к "Assembler" Зубкова С.В.) все-таки указывается количество _микроопераций_. У VLIW - да, микрокода уже нет. Однако там нет возможности задать, по какой именно шине будет производиться транспорт данных. Сразу замечу, что этого и не следует делать для нормальной работы, поскольку какая, в сущности, разница? TTA имеет все же больше академическую ценность, но вот для стековой архитектуры такой подход становится очень интересным.

Sun Oct 05 2003 21:42, Roman Khvatov wrote to Artem Kamburov:

RK> А стек на чем расположен? Или от того, что он стек он перестал состоять RK> из регистров?

На памяти вообще-то. Это проще, чем регистр...

5-Oct-03 13:56 Yuriy K wrote to Alex Kouznetsov:

YK>>>>>>> теряется та самая возможность запретить написание завешиваемых YK>>>>>>> программ, с которой все и началось.

AK>>>>>> Если в интерпретаторе нет операторов, которые позволят "завесить" AK>>>>>> программу, то завесить ее нельзя.

YK>>> Правда такой интерпретатор будет _очень_ медленным...

AK>> Представь, перед тобой два почти идентичных интерпретатора. Hо в первом AK>> есть операторы обслуживания WDT и запрещения прерываний, а во втором - AK>> нету. Ты будешь продолжать утверждать, что второй "будет _очень_ AK>> медленным"?

YK> Ты считаешь, что отсутсвие запрешения прерываний и работы с WDT достаточно YK> для написания незавешиваемых программ? YK> Ты крупно ошибаешься. Если я правильно понял -- речь не об этом. Да, если есть хоть какие-то возможности управления ходом выполнения -- можно написать нечто, сводимое к for(;;). Но если в выделенном для {"плугинов"|user code} наборе команд нет команды сброса WDT -- то такой бесконечный цикл сбросится и это будет повод для "системной" части ПО заняться вопросом "а что произошло". Если в пользовательском наборе команд отсутствует команда запрета прерываний, то этот код не сможет прерывания запретить. Если внешние пакеты обрабатываются (в прерываниях/системных потоках) и пользовательскому коду отдаются только "его" пакеты, то "альлё! перешиваем код пользовательской части" всегда дойдёт до системного кода. В процессорах с kernel/user состояниями для user code аппаратно недоступны некоторые команды. В форте можно "системные" солва вынести в отдельный словарь, который вырубать из списка словарей перед передачей управления на "пользовательский" код. На скорость выполнения это не повлияет.

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

И тут уже будет: YK>>> Эффективный "форт" - не более защищен, чем тот же С/С++/whatever. YK>>> Защищенный "форт" - страшно медленный и неэффективный, так же как и все YK>>> остальные способы защиты программ от ошибок.

[...] AK>>>> скажем, нет таких слов, которые могли бы запретить прерывания или AK>>>> обслужить WDT.

YK>>> Соболезную. Как будем работать с железом без запрета прерываний? Через "системные" вызовы. YK>>> Как пишутся обработчики прерываний? Драйвера - часть системы, выписаны и отлажены отдельно и предполагается, что они надёжнее "пользовательского" кода. Это не зависит от языка.

wbr,

5-Oct-03 10:40 Artem Kamburov wrote to Dima Orlov:

AK> Я пишу (иногда надо заставить Win нечто сделать, а вести позиционную AK> войну с AK> С++ - нет времени). Для МК использую асм (целевой Форт могу сделать, но AK> руки не доходят :-)). Вот именно!!! Отличный контраргумент на тему "им просто лень разобраться в форте, вот они и жуют свой С".

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

- недоходимость рук на освоение форта до состояния "могущести сделать целевой компилятор".

- право для всех однокристалок "безо всех этих хлопот" писать на С

Так что

AAR> From: "Alexandr A. Redchuck" snipped-for-privacy@real.kiev.ua>

AAR> Date: Sat, 12 Feb 2000 11:42:09 +0200 (UKR) AAR> Newsgroups: fido7.ru.algorithms AAR> Subject: Re: срочно!!!

AP>> Hарод, вот тyт такая задачка: нyжно определить вес байта (количество AP>> единичных битов)! AAR> Достаточно реальная задача. [...] AAR> === AAR> Украинский, Русский, С - свободно, Английский, Pascal - читаю и AAR> с трудом изъясняюсь, Forth -- читаю и перевожу СО СЛОВАРЕМ.

И так оно и будет. Тарасову проще напихать в ПЛИС кучку форт-процессоров (в том числе на правах программируемых автоматов) и загрузить каждого своей задачей, имея опыт построения целевых компиляторов ему проще и дешевле для MB90 или там чего ещё сделать целевой компилятор форта. Мне проще и дешевле поставить рядом с ПЛИС MCS51 или AVR-ку для общего управления, а внутри напихать обычных автоматов (даже микропрограммные пока не были нужны, жёстких хватает). Он кормится со своих решений, я -- со своих. Надеюсь (практически уверен), он никогда не скажет, что я "слишком туп или ленив, чтобы освоить форт" (а от фоРРРтеров такие фразы в адрес "обобщённого меня" я слышал, как и от c00l хацкеров про необходимость всё писать на ассемблере). Я никогда не скажу, что он маньяк с вывихнутыми мозгами или что ему нужен форт только для того, чтобы выделиться, иметь возможность считать себя "круче" остальных.

wbr,

4-Oct-03 15:37 Roman Khvatov wrote to Artem Kamburov:

RK> Кроме того, вместо "обычного" RISC SuperScalar уже засовывают много RK> маленьких RK> RISC процессоров - VLIW называется, что гораздо эффективнее 'многих Это немного не то. В одном VLI word натолкано несколько независимых команд из одного потока команд. Он их быстренько выполняет, при необходимости ОС переключает потоки, сохраняя контекст задачи. При ветвлении конвейер малость нарушается (если нет branch delay slot). Затолкать в одно длинное слово команды из разных потоков невозможно (и не нужно).

В случае "многопоточного" стекового процессора имеет смысл сделать его на столько потоков, сколько ступеней в конвейере и выполнять команды "по кругу" из каждого потока. Естественно, синхронно с ними переключать указатели стеков, которых должно быть столько же. При этом на разных стадиях конвейера находятся команды из разных потоков. Разрушения конвейера нет в принципе. Производительность ядра делится поровну между потоками, которые в настоящий момент выполняются, без расходов на переключение. Но если потоков меньше, чем таких "виртуальных процессоров", то часть производительнсоти теряется впустую. Впрочем, современным ОС такое малое число потоков не грозит, а embedded приложение можно сразу писать в рассчёте на то, что есть возможность задурачить несколько потоков (что и сделано в том Нейроне, бегает три задачи - системная, коммуникационная и пользовательская). Если потоков больше, то расходов на переключение не избежать, и если процессор "быстрый" (т.е. такой, для которого уже встают вопросы кеш-памяти), то расходы на переключение будут где-то те же, что и для процессоров с кучей РОН (так как из соображений производительности у каждого потока верхушки стеков должны быть выполнены на кристалле и перезагружаться при переключении задач).

Если я правильно понял, то в этом новом гипертрединговом PIV что-то отдалённо напоминающее и сделали.

wbr,

5-Oct-03 00:30 Arcady Schekochikhin wrote to Oleksandr Redchuk:

AS> Шитый код генерился DEC-овским Фортран-4 компилятором под RT-11 и Во-во. Без никакого форта рядом. Думаю, нормальному человеку достаточно хоть немного пописать на ассемблере, чтобы прийти к выводу о шитом коде как способе сокращения объёма программы. Даже не зная, что это называется "подпрограммный шитый код" и не слышавши о форте.

AS> RSX-11, AS> так что все серьезные ПДП-исты с ним были вполне себе знакомы. Да и AS> ФИГ-Форт на PDP-11 появился сильно до выхода Б-Н. Когда говорил про Б.-Н. -- я имел ввиду только то, что только в этой книжке я почитал про форт. Раньше только слышал, что такое в принципе существует.

wbr,

Sun Oct 05 2003 23:39, Oleksandr Redchuk wrote to "Artem Kamburov":

OR> Тарасову проще напихать в ПЛИС кучку форт-процессоров (в том числе OR> на правах программируемых автоматов) и загрузить каждого своей задачей, OR> имея опыт построения целевых компиляторов ему проще и дешевле для MB90 OR> или там чего ещё сделать целевой компилятор форта. OR> Мне проще и дешевле поставить рядом с ПЛИС MCS51 или AVR-ку для общего OR> управления, а внутри напихать обычных автоматов (даже микропрограммные OR> пока не были нужны, жёстких хватает). OR> Он кормится со своих решений, я -- со своих.

Абсолютно согласен с изложенным подходом. Если речь о задачах, ложащихся на 51 или AVR, то и применяемые средства должны соответствовать. И незачем возиться еще и с программным ядром, если задача настолько проста, что выписывается в один process на VHDL. MB90 (16 бит + 16 МГц + 256 кб флеша) для моих задач - система начального уровня... со всеми вытекающими. Я уже писал цифры: 16-32 разряда, 20-40 МГц, добавлю еще 25-50$ за ПЛИС. Вот сюда уже можно ставить программное ядро, а 8-16 битные контроллеры и так прекрасно справляются с возлагаемыми на них задачами, и писать можно хоть на асме, хоть на Си, хоть на Паскале (и даже лучше - быстрее получится результат на основе библиотек из стандартной поставки компилятора, с которым выпускается уже n-цатое изделие).

OR> Hадеюсь (практически уверен), он никогда не скажет, что я "слишком туп OR> или ленив, чтобы освоить форт" (а от фоРРРтеров такие фразы OR> в адрес "обобщённого меня" я слышал, как и от c00l хацкеров про OR> необходимость всё писать на ассемблере). Я никогда не скажу, что он OR> маньяк с вывихнутыми мозгами или что ему нужен форт только для того, OR> чтобы выделиться, иметь возможность считать себя "круче" остальных.

Разумеется, никогда не скажу. :) Каждому свое, и более того, умение выбрать для изучения подходящий предмет - очень хорошее качество. Т.е.: изучать, если надо... и не изучать, если не надо!

Жму руку... Редко попадается нормальная реакция.

÷ÓÅÍ ÐÒÉ×ÅÔ.

äÌÑ ÐÒÏÃÅÓÓÏÒÁ Ä×Å ÐÁÒÒÁÌÅÌØÎÏ ×ÙÐÏÌÎÑÅÍÙÅ ÚÁÄÁÞÉ É Ä×Á ÐÁÒÒÁÌÅÌØÎÏ ×ÙÐÏÌÎÑÅÍÙÈ ÐÏÔÏËÁ ÒÁÚÎÉÃÙ ÎÅ ÉÍÅÀÔ. òÁÚÎÉÃÁ ×ÏÚÎÉËÎÅÔ ÐÒÉ ÓÉÎÈÒÏÎÉÚÁÃÉÉ ÒÅÚÕÌØÔÁÔÏ×, ÎÏ ÜÔÏ ÕÖÅ ÞÉÓÔÏ ÐÒÏÇÒÁÍÍÎÁÑ ÐÒÏÂÌÅÍÁ ÐÒÉÞÅÍ ÄÁ×ÎÏ ÒÅÛÅÎÎÁÑ. þÔÏ ÚÎÁÞÉÔ "ÏÂÙÞÎÏÅ ÐÒÉÌÏÖÅÎÉÅ" - ÂÉÎÁÒÎÉË ÏÔ ÄÒÕÇÏÇÏ ÐÒÏÃÅÓÓÏÒÁ ÓËÏÒÅÅ ×ÓÅÇÏ ÅÍÕ ÎÅ ÐÏÄÓÕÎÅÛØ, Á ÐÒÉ ÐÅÒÅËÏÍÐÉÌÑÃÉÉ ÕÞÅÓÔØ ÎÁÌÉÞÉÅ Ä×ÕÈ ÐÒÏÃÅÓÓÏÒÏ× É ÚÁÐÕÓÔÉÔØ ÎÁ ÎÉÈ ÒÁÚÌÉÞÎÙÅ ÐÏÔÏËÉ ÔÒÕÄÁ ÎÅ ÓÏÓÔÁ×ÉÔ. îÅ ÐÏÎÑÌ, ÜÔÉ 'ÍÎÏÇÏ ÍÁÌÅÎØËÉÈ RISC ÐÒÏÃÅÓÓÏÒÏ×' ÍÏÇÕÔ ÎÅÚÁ×ÉÓÉÍÏ ×ÙÂÉÒÁÔØ ÏÄÉÎ ÐÏÔÏË ËÏÍÁÎÄ É ÎÅ ËÏÎÆÌÉËÔÏ×ÁÔØ? ôÏÇÄÁ ÞÅÍ ÜÔÏ ÏÔÌÉÞÁÅÔÓÑ ÏÔ ÓÕÐÅÒÓËÁÌÑÒÁ? áÒÔÅÍëáä

÷ÓÅÍ ÐÒÉ×ÅÔ.

îÅ ×ÅÒÎÏ. ðÏÓÍÏÔÒÉÔÅ ÎÁ MS WINWORD - ÜÔÏ ÐÒÉÌÏÖÅÎÉÅ ÚÁÎÉÍÁÅÔ × ÐÁÍÑÔÉ ÂÏÌØÛÅ 10 ÍÅÔÒÏ×. é ÇÄÅ ÔÁÍ ËÏÄ, ×ÙÐÏÌÎÑÀÝÉÊÓÑ ÍÎÏÇÏËÒÁÔÎÏ (ÎÅ ÄÕÍÁÀ, ÞÔÏ ÜÔÏ ÏÐÒÏÓ ËÌÁ×ÉÁÔÕÒÙ :)) ÉÚ-ÚÁ ËÏÔÏÒÏÇÏ ×ÓÅ ÐÒÉÌÏÖÅÎÉÅ ÔÏÒÍÏÚ? ôÁÍ ÅÓÔØ ÔÏÌØËÏ ÎÁÂÏÒ ÐÒÏÃÅÄÕÒ, ËÏÔÏÒÙÅ ×ÙÚÙ×ÁÀÔÓÑ ÏÄÉÎ ÒÁÚ (ÐÒÉ ÉÈ ÓÌÅÄÕÀÝÅÍ ×ÙÚÏ×Å ÉÈ × ËÅÛÅ, Á ÚÁÞÁÓÔÕÀ É × ÏÐÅÒÁÔÉ×ËÅ ÕÖÅ ÎÅÔ). é ÜÔÏ ÏÔÎÏÓÉÔÓÑ ÎÅ ÔÏÌØËÏ Ë ÷ÏÒÄÕ, Á É ËÏ ×ÓÅÊ Win ×ÃÅÌÏÍ. ÷ÏÏÂÝÅ-ÔÏ ÔÕÔ ×ÁÖÅÎ ÔÏÌØËÏ ÏÂßÅÍ, ÐÒÉ ÍÎÏÇÏËÒÁÔÎÏÓÔÉ ÐÏ×ÔÏÒÅÎÉÑ ÏÂßÅÍ ÚÁÎÉÍÁÅÍÙÊ × ËÅÛÅ ÎÅ Õ×ÅÌÉÞÉ×ÁÅÔÓÑ :). ëÒÏÍÅ ÔÏÇÏ, ÓÏ×ÒÅÍÅÎÎÙÅ ÐÒÉÌÏÖÅÎÉÑ ÓÔÒÏÑÔÓÑ ËÁË ÒÅÁËÃÉÉ ÎÁ ÓÏÂÙÔÉÑ, ÞÔÏ ÅÝÅ ÕÈÕÄÛÁÅÔ ÓÉÔÕÁÃÉÀ Ó ÐÏ×ÔÏÒÑÅÍÏÓÔØÀ ËÏÄÁ. ëÓÔÁÔÉ, ÅÓÌÉ Õ ÷ÁÓ ÓÌÁÂÁÑ ÍÁÛÉÎÁ É ÓÔÏÉÔ Win ÐÏÐÒÏÂÕÊÔÅ × Explorer-e ×ÙÚ×ÁÔØ ËÏÎÔÅËÓÔÎÏÅ ÍÅÎÀ (ÐÒÁ×ÁÑ ËÌÁ×ÉÛÁ) - ÐÒÉ ÐÅÒ×ÏÍ ×ÙÚÏ×Å ÜÔÏ ÚÁÊÍÅÔ ÓÅËÕÎÄÁ-Ä×Å, Á ÐÒÉ ÐÏÓÌÅÄÕÀÝÉÈ ÎÁÍÎÏÇÏ ÂÙÓÔÒÅÅ, ÎÏ ÐÏÓÌÅÄÕÀÝÉÅ-ÔÏ ÕÖÅ ÷ÁÍ ÎÅ ÎÕÖÎÙ :(. åÓÌÉ ÂÙ ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÉ ÂÙÌÏ-ÂÙ ÄÏÓÔÁÔÏÞÎÏ, Ñ ÂÙ ×ÏÏÂÝÅ ÄÌÑ ðë ÎÅ ÐÉÓÁÌ. ðÉÓÁÔØ ÐÒÉÈÏÄÉÔÓÑ ÐÒÉ Á×ÔÏÍÁÔÉÚÁÃÉÉ ÒÁÂÏÞÅÇÏ ÍÅÓÔÁ ÄÌÑ ÐÏÌÎÏÇÏ ÞÁÊÎÉËÁ × ü÷í (ÏÔ ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÉ Õ ÎÅÇÏ ÇÌÁÚÁ ÎÁ ÌÏ ÌÅÚÕÔ 8-D). áÒÔÅÍëáä

Hi Roman,

Sun Oct 05 2003 21:23, Roman Khvatov wrote to Alex Kouznetsov:

AK>> Предположим, на определенном кол-ве вентилей можно сделать проц, AK>> реализующий тот или иной подход. Одна реализация - ПикоЖаба, другая - AK>> суперскалярный RISC. Померяли производительность, оказалось что AK>> ПикоЖаба отстает. Возникает законный вопрос - а лучше суперскалярного AK>> РИСКа ничего нельзя сделать на этих же вентилях?

RK> Можно - VLIW. ..

Не все с тобой согласятся. Есть много людей, которые продолжают считать Форт-процессор наиболее эффективным по соотношению (производительность/вентиль). Посмотри

этот проц сделан на основе патента, взятого Чаком Муром, "отцом-основателем" Форта. Эти ребята бросают вызов всем: PTSC's 32-bit IGNITE processor cores outperform every rival RISC processor core available todaybar none. But we all know that the only real proof of any processor's performance is when it is running in your system with your code В каком-то смысле, возможно, он тоже VLIW, т.к. в одном 32-битном слове у него укладывается 5 команд. И в каком-то смысле он RISC, т.к., как понимаешь, в

6-битный код много команд просто не влезет. Только заход был сделан с другой стороны, со стороны Форта, а патенту скоро будет два десятка лет ;-) STМ уже "переоткрыла" для себя прелести стековой архитектуры, Сан тоже. Правда, с шишками, набитыми на ровном месте, чем изобретать велосипед - могли бы использовать IGNITE. Будем ждать, пока "дойдет" до остальных ;-)

AK>> Второй вопрос - если AK>> вместо того чтобы пытаться сделать "суперскалярный стековый проц", я AK>> эти вентили потрачу на много маленьких Форт-процессоров, как это AK>> сделал Чак Мур в своем х25, проиграю я суперскалярному РИСКу, или AK>> наоборот?

RK> Hа задачах общего назначения - да (ты просто не сможешь загрузить работой RK> _все_ эти 'маленькие Форт процессоры')

Чак Мур для этого предлагает использовать один из этих процессоров. Надо подождать, через десяток-другой лет эта идея, возможно, "дойдет" до Sun ;-)

AK>>>> Есть такие чипы Hейрон, выпускаемые уже десятка полтора лет. Они

RK>>> Ага. И за эти полтора десятка лет они не изменились? Или прогресс RK>>> уже остановился?

AK>> Как ни удивительно, не изменились.

RK> Это плохо. Это значит, что они так и остались на уровне того, что было 10 RK> лет назад.

AK>> По крайней мере, я не в курсе AK>> изменений, по-моему сейчас они выпускаются Сайпрессом и Тошибой точно AK>> такими, какими выпускались когда-то Моторолой. Для меня это хороший AK>> знак: значит, они настолько добротно были сделаны изначально, что AK>> продолжают оставаться конкурентноспособными.

RK> Скорее это знак, что они никому не нужны, поэтому их и не стали RK> развивать. А выпускают исключительно для существующих пользователей, RK> которых они вполне устраивают вот уже 10 лет. Или это знак, что их RK> невозможно улучшить. Для процессора с 10ти летнем стажем это уже приговор RK> :)

Компания, которая владеет этим процем, коммерчески очень успешная. У нее прочные рыночные позиции, а конкурентам до ее технологии пока что так и не удалось "допрыгать". Примерно то же, что Эшелон второй десяток лет делает на

8-битном проце с небольшой памятью, Сан сейчас предлагает делать при помощи "маленькой встроенной Жабы" на 32-битном проце с сотнями К памяти.

Пока, Алексей

âÙÌÏ ÄÅÌÏ,Artem Kamburov ÐÉÓÁÌ × ÜÈÅ "RU.EMBEDDED"ÐÉÓØÍÏ ÄÌÑ Dima Orlov[2:461/43.27], ÔÅÍÁ ÂÙÌÁ "Re: _Loader_"Á ÂÙÌÏ ÜÔÏ:01-Oct-2003, 21:22:15 [...]

AK> äÌÑ ÏÄÎÏËÒÉÓÔÁÌÏË ÜÔÏ ×ÅÒÎÏ (ÅÓÌÉ ÜÔÏ ÎÅ æÏÒÔ-ÐÒÏÃÅÓÓÏÒ), Á ÄÌÑ AK> ÓÏ×ÒÅÍÅÎÎÙÈ È86 (Ó ËÏÎ×ÅÊÅÒÏÍ, ËÅÛÁÍÉ, ÏÐÅÒÁÔÉ×ËÏÊ É ×ÉÒÔÕÁÌØÎÏÊ AK> ÐÁÍÑÔØÀ) ÎÅ ÏÂÑÚÁÔÅÌØÎÏ. üÔÏ ËÁË ÔÁË?íÏÖÎÏ ÐÏÐÏÄÒÏÂÎÅÅ?úÁ ÓÞÅÔ ÞÅÇÏ ÕÓËÏÒÅÎÉÅ?

AK> ó×ÑÚÁÎÏ ÜÔÏ Ó ÔÅÍ, ÞÔÏ × È86-È ÓÉÓÔÅÍÁÈ ÐÒÏÃÅÓÓÏÒ (ËÏÔÏÒÙÊ ÎÁÔÉ×ÎÙÊ ËÏÄ AK> ×ÙÐÏÌÎÑÅÔ ÂÙÓÔÒÅÅ) ÎÅ Ñ×ÌÑÅÔÓÑ ÓÁÍÙÍ ÍÅÄÌÅÎÎÙÍ Ú×ÅÎÏÍ - ÏÞÅÎØ ÍÎÏÇÏ AK> ×ÒÅÍÅÎÉ ÔÒÁÔÉÔÓÑ ÎÁ ÚÁÇÒÕÚËÕ ÉÚ ÐÁÍÑÔÉ. ôÁË, ÞÔÏ ÅÓÌÉ ÛÉÔÙÊ ËÏÄ ÐÏ ÏÂßÅÍÕ AK> ÂÕÄÅÔ × ÄÅÓÑÔØ ÒÁÚ ËÏÒÏÞÅ ÁÎÁÌÏÇÉÞÎÏÇÏ ÎÁÔÉ×ÎÏÇÏ, ÐÏÞÔÉ ÎÁ×ÅÒÎÑËÁ ÏÎ ÂÕÄÅÔ AK> É ÂÙÓÔÒÅÅ (ÎÅ ÓÍÏÔÒÑ ÎÁ ÚÁÄÅÒÖËÉ ÐÒÉ ÁÄÒÅÓÎÏÊ ÉÎÔÅÒÐÒÅÔÁÃÉÉ). ü... ÍÏÖÅÔ,Ñ ÞÅÇÏ-ÔÏ ÎÅ ÐÏÎÉÍÁÀ,ÎÏ...

- åÓÌÉ Õ ÎÁÓ ÉÎÔÅÒÐÒÅÔÁÔÏÒ ÔÏ ËÒÏÍÅ(ÄÏÐÕÓÔÉÍ,ËÏÍÐÁËÔÎÏÇÏ)ÉÎÔÅÒÐÒÅÔÉÒÕÅÍÏÇÏ ËÏÄÁ ÅÓÔØ ÅÝÅ ËÏÄ,ÓÏÂÓÔ×ÅÎÎÏ,ÓÁÍÏÇÏ ÉÎÔÅÒÐÒÅÔÁÔÏÒÁ.ïÎ ÞÔÏ,ÎÉÞÅÇÏ ÎÅ ÚÁÎÉÍÁÅÔ, ÎÉÏÔËÕÄÁ ÎÅ ÂÅÒÅÔÓÑ É ×ÒÅÍÅÎÉ ÎÁ ×ÙÐÏÌÎÅÎÉÅ ÅÍÕ ÎÅ ÎÁÄÏ?÷ ÉÄÅÁÌØÎÏÍ ÓÌÕÞÁÅ ÉÎÔÅÒÐÒÅÔÁÔÏÒ ËÏÎÅÞÎÏ ×ÍÅÓÔÅ Ó ËÏÄÏÍ ×ÌÅÚÅÔ × ËÜÛ,ÎÏ...ÓÍ ÎÉÖÅ.

- åÓÌÉ Õ ÎÁÓ "ËÏÍÐÉÌÑÔÏÒ", ÔÏ ÓÇÅÎÅÒÅÎÎÙÊ ÉÍ ÎÁÔÉ×ÎÙÊ ËÏÄ × *ÌÕÞÛÅÍ* ÓÌÕÞÁÅ ÂÕÄÅÔ ÎÅ ÓÉÌØÎÏ ÂÏÌØÛÅ ÓÏÏÔ×. ËÏÄÁ ÐÉÓÁÎÏÇÏ ÎÁ native ÁÓÍÅ ÎÁÛÅÊ ÐÌÁÔÆÏÒÍÙ ÞÅÌÏ×ÅËÏÍ.îÏ × ÌÀÂÏÍ ÓÌÕÞÁÅ,ÁÓÓÅÍÂÌÅÒÎÙÊ ËÏÄ ÕÍÅÝÁÀÝÉÊÓÑ × ËÜÛ ÐÒÏÃÅÓÓÏÒÁ ÂÕÄÅÔ ÒÁÂÏÔÁÔØ ÅÝÅ ÂÙÓÔÒÅÅ É ÚÁÎÉÍÁÔØ ÔÁÍ ÐÏÍÅÎØÛÅ ÍÅÓÔÁ :)) (Á ËÜÛ ËÁË ÂÙ ÎÅ ÒÅÚÉÎÏ×ÙÊ) - ÔÁË É ÄÅÌÁÀÔ ×ÓÑËÉÅ ÐÒÉÂÌÕÄÙ ÔÉÐÁ ÓÏÆÔÉÎ ÔÅÓÔÑÝÉÈ RAM,Ô.Ë.ÉÈ ÉÓÐÏÌÎÅÎÉÅ ÉÚ RAM ËÏÔÏÒÏÅ ÐÏÐÕÔÎÏ ÅÝÅ É ÔÅÓÔÉÔÓÑ ÏÏÏÞÅÎØ ÚÁÍÅÄÌÑÅÔ ÜÔÏÔ ÐÒÏÃÅÓÓ.

Good Bye, Artem.See you later. ... æÉÄÏÌÕË-ÛÔÕËÁ ÈÏÒÏÛÁÑ.á Fidolook SL ÓÔÁÌ ÅÝÅ ÌÕÞÛÅ:)

Sat Oct 04 2003 20:22, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR>>> Скомпилированный для "Hейрона" из "Hейрон-C" код выполняется OR>>> ПРОЦЕССОРОМ СО СТЕКОВОЙ АРХИТЕКТУРОЙ.

OR>>> Или есть исторические сведения, что стековая архитектура вообще OR>>> родилась только после появления форта и в результате воздействия оного OR>>> на умы архитекторов ЭВМ?

AK>> А... Опять спор о терминах и приоритетах... "Форт-процессор" и "стековый AK>> процессор" - синонимы.

OR> Значит всё-таки у меня в атлоне стоит форт-сопроцессор плавающей OR> арифметики... OR> Может ещё и С-компилятор генерит вставки на форте для него?

OR> И тот технологический управляющий контроллер Reliance Electric OR> на рассыпухе 74-ой серии, в котором я копался когда-то (битовый OR> процессор со стековой архитектурой) - тоже "форт-процессор"?

OR> Улёт....

Раз ты так все хорошо объясняешь.... И не являешься неофитом, жалким "форрррртером", "кульхацкером", или каким другим быдлом... И про Форт знаешь давно, раньше всех присутствующих, да и сам что-то похожее когда-то изобрел... Будь добёр, растолкуй простым смертным, в чем разница между стековым процессором и Форт-процессором? Дай, пожалуйста, определения того и другого, чтобы можно было отличить в случае нужды. Или дай хотя бы какое-нибудь ЦУ, как жить дальше: совсем слово "Форт" употреблять нельзя, или таки можно, но шепотом, и в узком кругу, чтоб никто не слышал?

Пока, Алексей

Mon Oct 06 2003 03:20, Power User wrote to Artem Kamburov: PU> - Если у нас интерпретатор то PU> кроме(допустим,компактного)интерпретируемого кода есть еще PU> код,собственно,самого интерпретатора.Он что,ничего не занимает, ниоткуда PU> не берется и времени на выполнение ему не надо?В идеальном случае PU> интерпретатор конечно вместе с кодом влезет в кэш,но...см ниже.

PU> - Если у нас "компилятор", то сгенеренный им нативный код в *лучшем* PU> случае будет не сильно больше соотв. кода писаного на native асме PU> нашей платформы человеком.

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

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

Среди множества возможных вариантов реализации тебе будет очень трудно выбрать оптимальный, или даже просто хороший. То есть, "самопал на асме", скорей всего, будет "большой каракатицей" и "кривым угробищем". Тогда как знание Форта _позволит_ тебе сделать этот код компактным и эффективным, так что он сможет уместиться в кэш. Не буду утверждать что FVM в качестве интерпретатора всегда именно _оптимальна_, но, по крайней мере, Форт тебе предлагает опробованный _хороший_ вариант. Конечно, чтобы даже просто начать копать в этом направлении, тебе надо не бояться стековых машин и RPN. А то некоторые упертые попробовали Форт раз-другой, не смогли его освоить, и теперь на всех углах хают как сам Форт, так и тех, кто может его использовать.

Пока, Алексей

Не путай нынешнего человека (программиста) с таковым 70-х годов. В свое время даже процедуру двоичного поиска не могли безошибочно написать в течении нескольких лет. Идеи появляются в голове у того, кто уже и без того имеет много идей. В те времена Форт был революционной идеей - хоть и опирался на уже известный шитый код - да и "подпрограммный шитый код" здесь не причем, Ф4 работал на косвенном шитом коде.

Аркадий

ЗЫ Форт это не язык (по крайне мере так как он был придуман) - это СИСТЕМА, интерпретатор, компилятор, интерфейс пользователЯ, файловая система.

Hi Ilia!

÷ ×ÏÓËpÅÓÅÎØÅ, 05 ÏËÔÑÂpÑ 2003 22:16:05, Ilia Tarasov ÐÉÓÁÌ to Dima Orlov:

IT> HÕ ×ÏÔ ÂÙÌÁ ÓÉÓÔÅÍÁ, × ËÏÔÏÒÏÊ ×ÈÏÄÎÏÊ ÐÏÔÏË ÉÎÔÅÒÐÒÅÔÁÔÏÒÁ ÇÒÕÚÉÌÓÑ IT> ÐÒÑÍÏ ÞÅÒÅÚ COM. óÏÏÔ×ÅÔÓÔ×ÅÎÎÏ, ÛÌÉ ÞÅÒÅÚ ÎÅÇÏ Ó×ÅÒÔËÉ ÓÌÏ× æÏÒÔÁ ÉÚ IT> ÂÉÂÌÉÏÔÅËÉ, É ÎÅ ÎÁÄÏ ÂÙÌÏ ÐÒÉÄÕÍÙ×ÁÔØ ËÁËÏÊ-ÔÏ ÄÏÐÏÌÎÉÔÅÌØÎÙÊ IT> ÐÒÏÔÏËÏÌ ÏÂÍÅÎÁ ÍÅÖÄÕ ÈÏÓÔÏÍ É embedded-ÓÉÓÔÅÍÏÊ.

ðÒÉ ÉÓËÁÖÅÎÉÉ × ÐÅÒÅÄÁÞÅ ÄÁÎÎÙÈ -- ËÏÎÅÃ ÕÓÔÒÏÊÓÔ×Õ?

Sincerely, Vadim.

Hello Ilia.

05 Oct 03 23:09, you wrote to me:

IT>>> y=sin(sqrt(abs(2*x))) þÔÏ ÚÄÅÓØ ÎÅÚÁ×ÉÓÉÍÏÇÏ? RK>> é ÜÔÏ ×ÓÑ ÐÒÏÇÒÁÍÍÁ? éÌÉ × ÎÅÊ ÅÓÔØ ÅÝÅ ÞÔÏ-ÔÏ? ÷ÏÔ ÜÔÏ 'ÞÔÏ-ÔÏ' RK>> É ÂÕÄÅÔ 'ÎÅÚÁ×ÉÓÉÍÙÍ' IT> æÏÒÍÁÌØÎÏ ÓÏÇÌÁÓÅÎ. äÏÂÁ×ÌÀ, ÒÁÚ×É×ÁÑ ÔÅÍÕ, ÞÔÏ ÄÁÎÎÏÅ ×ÙÞÉÓÌÅÎÉÅ IT> ÚÁÎÉÍÁÅÔ ÂÏÌØÛÕÀ ÞÁÓÔØ ×ÒÅÍÅÎÉ...

ôÏ ÅÓÔØ ×ÓÅ ÔÁËÉ ÜÔÏ ÅÄÉÎÓÔ×ÅÎÎÁÑ ÒÁÂÏÔÁÀÝÁÑ ÆÏÒÍÕÌÁ × ÐÒÏÇÒÁÍÍÅ :) þÔÏ ÔÏ ÎÅ ×ÅÒÉÔÓÑ. ëÒÏÍÅ ÔÏÇÏ, ÚÄÅÓØ ÕÖÅ ÚÁÍÅÞÁÌÉ, ÞÔÏ ÓÏÂÓÔ×ÅÎÎÏ sin É sqrt ÓÁÍÉ ÐÏ ÓÅÂÅ ×ÐÏÌÎÅ ÈÏÒÏÛÏ ÐÁÒÁÌÌÅÌÑÔÓÑ.

IT>>> HÁÐÒÉÍÅÒ, ÁÌÇÏÒÉÔÍÙ ÃÉÆÒÏ×ÏÊ ÏÂÒÁÂÏÔËÉ ÞÁÓÔÏ Ó×ÏÄÑÔÓÑ Ë IT>>> ÕÍÎÏÖÅÎÉÀ Ó ÎÁËÏÐÌÅÎÉÅÍ. ðÒÅÄÓÔÁ×ÉÍ, ÞÔÏ ÐÅÒÅÍÎÏÖÉÔÅÌØ ÏÄÉÎ, É IT>>> Ñ×ÌÑÅÔÓÑ, ÓÏÏÔ×ÅÔÓÔ×ÅÎÎÏ, ÕÚËÉÍ ÍÅÓÔÏÍ. þÔÏ × ÜÔÏÍ ÓÌÕÞÁÅ ÍÏÖÎÏ IT>>> ÒÁÓÐÁÒÁÌÌÅÌÉÔØ?

RK>> íÏÖÎÏ ÒÁÚÄÅÌÉÔØ ÕÍÎÏÖÁÅÍÙÊ ÍÁÓÓÉ× ÎÁ 2 ÐÏÄÍÁÓÓÉ×Á (Ó ÞÅÔÎÙÍÉ É RK>> ÎÅÞÅÔÎÙÍÉ ÉÎÄÅËÓÁÍÉ), É ÕÍÎÏÖÁÔØ Ó ÎÁËÏÐÌÅÎÉÅÍ ÜÔÉ ÐÏÌÏ×ÉÎÙ RK>> ÏÔÄÅÌØÎÏ, ÐÏÔÏÍ ÒÅÚÕÌØÔÁÔÙ ÓÌÏÖÉÔØ, ÔÏÇÄÁ 2 ÜÔÉÈ ÃÉËÌÁ ÕÍÎÏÖÅÎÉÊ RK>> ÍÏÖÎÏ ÐÁÒÁÌÌÅÌÉÔØ.

IT> HÅ ÐÏÎÑÌ... õÓÔÒÏÊÓÔ×Ï ÕÍÎÏÖÅÎÉÑ ×ÓÅÇÏ ÏÄÎÏ, ÞÔÏ ÍÏÖÎÏ ÐÁÒÁÌÌÅÌÉÔØ?

÷ ÓÕÐÅÒÓËÁÌÑÒÅ ÉÈ ÎÅÓËÏÌØËÏ.

IT> Fixed. á æÏÒÔ-ÐÒÏÃÅÓÓÏÒ Ó ÚÁÐÁÒÁÌÌÅÌÅÎÎÙÍÉ ÓÔÅËÁÍÉ?

üÔÏ ÂÕÄÅÔ ÎÁÚÙ×ÁÔØÓÑ ×ÅËÔÏÒÎÁÑ ÍÁÛÉÎÁ. ôÁËÉÅ ÕÖÅ ÂÙÌÉ É ×ÙÍÅÒÌÉ ÚÁ ÎÅ×ÏÓÔÒÅÂÏ×ÁÎÎÏÓÔØÀ :)

RK>> åÝÅ ÒÁÚ ÐÏ×ÔÏÒÑÀ - ËÏÇÄÁ ÎÕÖÎÏ ÄÏÂÉÔÓÑ ÔÏÐÏ×ÙÈ ÓËÏÒÏÓÔÅÊ, ÔÏÇÄÁ É RK>> ÎÕÖÎÏ ÐÁÒÁÌÌÅÌÉÔØ.

RK>> éÎÔÅÒÅÓÎÏ, ÅÓÌÉ ÏÂßÅÄÉÎÉÔØ × ÏÄÉÎ 3 ÐÌÏÈÉÈ ÐÒÏÃÅÓÓÏÒÁ, ÔÏ RK>> ÐÏÌÕÞÉÔÓÑ ÏÄÉÎ ÈÏÒÏÛÉÊ? éÌÉ ×ÓÅ ÔÁËÉ ÌÕÞÛÅ ÏÂßÅÄÉÎÑÔØ 3 ÈÏÒÏÛÉÈ RK>> ÐÒÏÃÅÓÓÏÒÁ :)

IT> ëÏÎÅÞÎÏ, 3 ÈÏÒÏÛÉÈ :) HÁÐÒÉÍÅÒ, ÓÔÅËÏ×ÁÑ ÁÒÈÉÔÅËÔÕÒÁ ÎÁ FPGA Xilinx IT> ÄÁÅÔ ÒÏ×ÎÏ × 16 ÒÁÚ ÂÏÌØÛÉÊ ÏÂßÅÍ ÓÔÅËÏ×ÏÊ ÐÁÍÑÔÉ ÎÁ ÔÅÈ ÖÅ IT> ÒÅÓÕÒÓÁÈ... ;)))

÷ÏÚÍÏÖÎÏ. ñ ÔÁË ÐÏÎÉÍÁÀ, ÞÔÏ ÓÔÅË ÔÁÍ ÄÅÌÁÅÔÓÑ ÎÁ FIFO?

IT> HÕ, ËÏÍÕ ËÁË. óÏÇÌÁÓÅÎ, ÄÌÑ ÐÏÄÁ×ÌÑÀÝÅÇÏ ÂÏÌØÛÉÎÓÔ×Á ÒÁÚÒÁÂÏÔÞÉËÏ× IT> ÒÁÚÒÁÂÏÔËÁ ÓÏÂÓÔ×ÅÎÎÏÇÏ ËÏÍÐÉÌÑÔÏÒÁ - ÄÁÌÅËÏ ÎÅ ÐÅÒ×ÏÏÞÅÒÅÄÎÁÑ IT> ÚÁÄÁÞÁ.

á ËÔÏ ÇÏ×ÏÒÉÔ ÐÒÏ ÓÏÂÓÔ×ÅÎÎÙÊ? HÁÐÉÓÁÔØ èïòïûéê ËÏÍÐÉÌÑÔÏÒ - ÜÔÏ _ÏÞÅÎØ_ ÎÅÐÒÏÓÔÁÑ ÚÁÄÁÞÁ. åÇÏ ÏÂßÅÍÙ ×ÐÏÌÎÅ ÍÏÇÕÔ ÚÁÛËÁÌÉÔØ ÚÁ ÎÅÓËÏÌØËÏ ÍÉÌÉÏÎÏ× ÓÔÒÏË ÎÁ ó.

RK>> ôÅÂÅ ÛÁÛÅÞËÉ ÉÌÉ ÅÈÁÔØ? èÏÞÅÛØ ÐÏÌÕÞÉÔØ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔØ - RK>> ÐÏËÕÐÁÊ ËÏÍÐÉÌÑÔÏÒ (ÉÌÉ ÐÉÛÉ ÎÁ ÁÓÍÅ, ÅÓÌÉ × ÚÁÐÁÓÅ ÅÓÔØ RK>> ÎÅÏÇÒÁÎÉÞÅÎÎÏÅ ×ÒÅÍÑ :)

IT> íÎÅ - ÅÈÁÔØ Ó ÛÁÛÅÞËÁÍÉ... :) ÷ÏÔ Ñ ÏÂÙÞÎÏ ÎÁÞÉÎÁÀ ÎÁ ÁÓÍÅ, ÎÏ IT> ÉÓÐÏÌØÚÕÀ ÒÑÄ ÐÒÉÅÍÏ× ËÏÄÉÒÏ×ÁÎÉÑ, ÐÏÚ×ÏÌÑÀÝÉÅ ÐÉÓÁÔØ ÓÌÏ×Á "×ÔÏÒÏÇÏ IT> ÓÌÏÑ" × ÓÔÉÌÅ ÐÏÓÔÆÉËÓÎÏÊ ÓÔÅËÏ×ÏÊ ÍÁÛÉÎÙ. íÏÖÎÏ ÚÁ×ÏÄÉÔØ ÐÅÒÅÍÅÎÎÙÅ, IT> ÍÏÖÎÏ ÐÙÔÁÔØÓÑ ÕÐÉÈÁÔØ ×ÓÅ × ÒÅÇÉÓÔÒÙ... ÍÏÖÎÏ ÉÍÉÔÉÒÏ×ÁÔØ ÓÔÉÌØ IT> ÐÒÏÃÅÄÕÒÎÙÈ ÑÚÙËÏ× - ÇÏÔÏ×ÉÔØ ÓÔÅËÏ×ÙÊ ËÁÄÒ, Á ÐÏÔÏÍ ÓÎÉÍÁÔØ IT> ÒÅÚÕÌØÔÁÔ. íÎÅ ×ÏÔ ÎÒÁ×ÉÔÓÑ ÎÁ ÁÓÍÅ ÐÉÓÁÔØ × ÓÔÉÌÅ ñ÷õ, É ÓÔÉÌØ æÏÒÔÁ IT> ÒÅÁÌÉÚÕÅÔÓÑ Ó ÎÁÉÍÅÎØÛÉÍÉ ×ÒÅÍÅÎÎÙÍÉ ÚÁÔÒÁÔÁÍÉ...

åÓÔØ ÔÁËÏÅ ÎÁÂÌÀÄÅÎÉÅ - ÐÒÏÇÒÁÍÉÓÔ ÐÉÛÅÔ ÐÒÉÂÌÉÚÉÔÅÌØÎÏ Ó ÏÄÎÏÊ É ÔÏÊ ÖÅ ÓËÏÒÏÓÔØÀ (× ÓÔÒÏËÁÈ × ÞÁÓ) ÎÁ _ÌÀÂÏÍ_ ÑÚÙËÅ. ôÅÐÅÒØ ÐÒÉËÉÎØ ÏÄÎÁ ÓÔÒÏËÁ ÎÁ ó

- ÜÔÏ ÓËÏÌØËÏ ÓÔÒÏË ÎÁ asm? þÔÏ ËÁÓÁÅÔÓÑ æÏÒÔÁ, ÔÏ ÔÕÔ ÎÁ ÐÅÒ×ÙÊ ÐÌÁÎ ×ÙÈÏÄÉÔ ÅÇÏ 'Ó×ÏÅÏÂÒÁÚÎÏÓÔØ' - Ó ÞÉÔÁÅÍÏÓÔØÀ ÅÇÏ ÐÒÏÇÒÁÍÍ ÄÅÌÏ ÏÂÓÔÏÉÔ ÄÁÖÅ ÈÕÖÅ, ÞÅÍ Ó ÏÂÙÞÎÙÍ asm'ÏÍ :) (ôÕÔ Ñ ÐÏÌÎÏÓÔØÀ ÓÏÇÌÁÓÅÎ Ó DO)

RK>> þÔÏ ËÁÓÁÅÔÓÑ ÇÌÀËÏ× - ËÁË ÔÙ ÄÕÍÁÅÛØ, × ÞÅÍ ÐÒÏÝÅ ÉÓÐÒÁ×ÉÔØ RK>> ÇÌÀËÉ, × ËÏÍÐÉÌÑÔÏÒÅ ÉÌÉ × ÐÒÏÃÅÓÓÏÒÅ? éÌÉ ÔÙ ÄÕÍÁÅÛØ, ÞÔÏ RK>> ÐÒÏÃÅÓÓÏÒÙ ÒÏÖÄÁÀÔÓÑ ÓÁÍÉ ÐÏ ÓÅÂÅ É ÁÂÓÏÌÀÔÎÏ ÂÅÚÇÌÀÞÎÙÅ? é ËÁË RK>> ÔÙ ÄÕÍÁÅÛØ, × ËÁËÏÍ ÐÒÏÃÅÓÓÏÒÅ ÂÕÄÅÔ ÂÏÌØÛÅ ÇÌÀËÏ× - × ÔÏÍ, RK>> ËÏÔÏÒÙÊ ÓÌÏÖÎÅÅ, ÉÌÉ × ÔÏÍ, ËÏÔÏÒÙÊ ÐÒÏÝÅ?

IT> ðÒÏÝÅ ÉÓÐÒÁ×ÉÔØ ÇÌÀËÉ × ÂÏÌÅÅ ÐÒÏÓÔÏÊ ÓÉÓÔÅÍÅ. æÏÒÔ-ÐÒÏÃÅÓÓÏÒ (ËÁË É IT> ÌÀÂÏÊ ÄÒÕÇÏÊ) ÐÒÅÄÓÔÁ×ÌÑÅÔ ÓÏÂÏÊ ÒÁÚÎÏ×ÉÄÎÏÓÔØ ËÏÎÅÞÎÏÇÏ Á×ÔÏÍÁÔÁ, É IT> ÐÒÏÅËÔÉÒÕÅÔÓÑ ÐÏ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÍ ÍÅÔÏÄÉËÁÍ.

á ÐÏÔÏÍ ÏÎ ×ÏÐÌÏÝÁÅÔÓÑ × ÖÅÌÅÚÅ, ËÏÔÏÒÏÅ × ÏÔÌÉÞÉÉ ÏÔ ÓÏÆÔÁ ÕÖÅ ÎÅ ÉÓÐÒÁ×ÉÛØ. á ×ÙÐÕÓË ÎÏ×ÏÊ ×ÅÒÓÉÉ ÖÅÌÅÚÁ ÜÔÏ ÓÏ×ÓÅÍ ÎÅ ÔÏ, ÞÔÏ ×ÙÐÕÓË ÎÏ×ÏÊ ×ÅÒÓÉÉ ÓÏÆÔÁ. (ðÏËÁ Ñ ÎÅ ÒÁÓÓÍÁÔÒÉ×ÁÀ æÏÒÔ ÐÒÏÃÅÓÓÏÒÙ × FPGA - ÔÁÍ ÏÎÉ ×ÐÏÌÎÅ ÏÐÒÁ×ÄÁÎÎÙ)

RK>> (á Ñ ÕÖÅ ÐÉÓÁÌ, ÞÔÏ æÏÒÔ ÐÒÏÃÅÓÓÏÒ ÂÕÄÅÔ ÓÌÏÖÎÅÅ ÁÎÁÌÏÇÉÞÎÏÇÏ RK>> RISC ÐÒÏÃÅÓÓÏÒÁ)

IT> çÏÒÁÚÄÏ ÐÒÏÝÅ ÓÕÐÅÒÓËÁÌÑÒÁ,

ó ÜÔÉÍ ÎÉËÔÏ ÎÅ ÓÐÏÒÉÔ, ÏÄÎÁËÏ É ÐÏ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ ÏÎ ÂÕÄÅÔ ÅÍÕ ÕÓÔÕÐÁÔØ.

IT> É ÐÒÁËÔÉÞÅÓËÉ ÜË×É×ÁÌÅÎÔÅÎ ÏÂÙÞÎÏÍÕ ÒÅÇÉÓÔÒÏ×ÏÍÕ (Ñ ÐÒÏÂÏ×ÁÌ × ðìéó IT> ÒÁÚÎÙÅ ÐÏÄÈÏÄÙ). õÄÏÂÓÔ×Ï ÓÔÅËÏ×ÏÇÏ ÐÒÏÃÅÓÓÏÒÁ Ó ËÏÍÁÎÄÁÍÉ, IT> ÜË×É×ÁÌÅÎÔÎÙÍÉ ÓÌÏ×ÁÍ æÏÒÔÁ, ÇÏÒÁÚÄÏ ×ÙÛÅ ÕÄÏÂÓÔ×Á ÒÅÇÉÓÔÒÏ×ÏÇÏ IT> ÐÒÏÃÅÓÓÏÒÁ Ó ÔÅÍ ÖÅ ÏÂßÅÍÏÍ ÒÅÓÕÒÓÏ× -

ëÏÍÐÉÌÑÔÏÒÕ ×ÓÅ ÒÁ×ÎÏ, Á ÎÁÐÉÓÁÎÉÅ ÎÁ ÇÏÌÏÍ ÁÓÍÅ/æÏÒÔÅ ÐÏÄÈÏÄÉÔ ÔÏÌØËÏ ÄÌÑ ÎÅÂÏÌØÛÉÈ ÐÒÏÅËÔÏ×, Á ÄÌÑ ÎÉÈ ÁÂÓÏÌÀÔÎÏ ÐÏ ÂÁÒÁÂÁÎÕ, ËÁËÏÊ ÂÕÄÅÔ ÐÒÏÃÅÓÓÏÒ.

IT> ÄÌÑ ÓÔÅËÏ×ÏÊ ÁÒÈÉÔÅËÔÕÒÙ ÓÒÁÚÕ IT> ÇÏÔÏ×Ù ×ÓÅ ÁÌÇÏÒÉÔÍÙ, Á ÄÌÑ ÒÅÇÉÓÔÒÏ×ÏÊ ÎÁÄÏ ÄÏÌÇÏ ÄÕÍÁÔØ, ËÁË ×ÓÅ IT> ÔÕÄÁ ÕÐÉÈÁÔØ, É ÎÅ ÚÁ×ÅÓÔÉ ÌÉ ÅÝÅ ÒÅÇÉÓÔÒ, Á ÔÏ ÞÔÏ-ÔÏ ÍÅÓÔÁ ÍÁÌÏ É × IT> ÐÁÍÑÔØ ÌÅÚÔØ ÐÒÉÈÏÄÉÔÓÑ...

á ÅÓÌÉ Õ æÏÒÔ ÐÒÏÃÅÓÓÏÒÁ ËÏÎÞÉÔÓÑ ÓÔÅË? üÔÏ ÐÒÏÂÌÅÍÁ ÔÏÇÏ ÖÅ ÐÌÁÎÁ.

RK>> üÔÏ ×ÁÖÎÏ. åÓÌÉ ÎÁÂÏÒ ÒÅÇÉÓÔÒÏ× ÎÅ ÎÉÍÍÅÔÒÉÞÎÙÊ (ËÁË × x86), ÔÏ RK>> ÒÁÓÐÒÅÄÅÌÅÎÉÅ ÒÅÇÉÓÔÒÏ× ÕÓÌÏÖÎÑÅÔÓÑ (ÎÏ ÎÅ ÆÁÔÁÌØÎÏ)

IT> áÇÁ! ôÏ ÅÓÔØ ×ÓÅ-ÔÁËÉ ÒÁÚÎÉÃÁ ÅÓÔØ,

åÓÔØ

IT> É ÔÕÔ ÕÖÅ ÎÁÄÏ ÎÁÊÔÉ ËÏÍÐÒÏÍÉÓÓ ÍÅÖÄÕ ÒÁÚÒÁÂÏÔÞÉËÏÍ ËÏÍÐÉÌÑÔÏÒÁ

HÉËÁËÉÈ ËÏÍÐÒÏÍÉÓÏ× ÉÓËÁÔØ ÎÅ ÎÁÄÏ.

IT> (ËÏÔÏÒÏÍÕ ÖÅÌÁÔÅÌØÎÏ ÓÉÍÍÅÔÒÉÞÎÙÊ ÎÁÂÏÒ) É ÒÁÚÒÁÂÏÔÞÉËÏÍ ÖÅÌÅÚÁ,

öÅÌÅÚÏ ÏÂÙÞÎÏ ÕÖÅ ÄÁÎÏ ËÁË ÄÁÎÎÏÓÔØ, Á ÐÒÉ ÐÒÏÅËÔÉÒÏ×ÁÎÉÉ ÎÏ×ÙÈ ÐÒÏÃÅÓÓÏÒÏ× × ÌÀÂÏÍ ÓÌÕÞÁÅ ÓÔÁÒÁÀÔÓÑ ÓÄÅÌÁÔØ ÓÉÍÍÅÔÒÉÞÎÙÊ ÎÁÂÏÒ ÒÅÇÉÓÔÒÏ× - ÔÁË ×ÓÅÍ ÐÒÏÝÅ.

IT> ËÏÔÏÒÏÍÕ ÐÒÏÝÅ ÓÏÅÄÉÎÉÔØ ÜÔÏÔ ÎÏ×ÙÊ ÒÅÇÉÓÔÒ Ó ËÁËÉÍ-ÎÉÂÕÄØ IT> ÁËËÕÍÕÌÑÔÏÒÏÍ,

ôÁË ÎÅ ÄÅÌÁÀÔ. ïÂÙÞÎÏ ÅÓÔØ ÎÁÂÏÒ òïHÏ× É ËÁËÏÊ ÎÉÂÕÄØ ÁËËÕÍÕÌÑÔÏÒ (ÉÌÉ ÎÅÓËÏÌØËÏ, ÉÌÉ ÎÉ ÏÄÎÏÇÏ). ðÏÄ ÒÅÇÉÓÔÒÁÍÉ × ÔÁËÏÊ ÁÒÈÉÔÅËÔÕÒÅ ÐÏÎÉÍÁÀÔ òïHÙ, Ë ÁËËÕÍÕÌÑÔÏÒÁÍ (É ÐÒ. ÓÐÅà ÒÅÇÉÓÔÒÁÍ) ÏÔÎÏÓÑÔÓÑ ËÁË Ë ÓÐÅÃÉÁÌØÎÏÇÏ ×ÉÄÁ ÁÐÐÁÒÁÔÕÒÅ, ËÏÔÏÒÁÑ ÉÓÐÏÌØÚÕÅÔÓÑ ÔÏÌØËÏ ÐÒÉ ÇÅÎÅÒÁÃÉÉ ËÏÍÍÁÎÄ, ÎÏ ÎÅ ÕÞÁÓÔ×ÕÅÔ × ÒÁÓÐÒÅÄÅÌÅÎÉÉ ÒÅÇÉÓÔÒÏ×. é ÔÏÌØËÏ ÎÁ ÐÏÓÌÅÄÎÉÈ ÓÔÁÄÉÑÈ ÏÐÔÉÍÉÚÁÃÉÊ ÕÖÅ ÇÏÔÏ×ÏÇÏ ËÏÄÁ (peephole ÏÐÔÉÍÉÚÁÃÉÉ) ÅÇÏ ÐÙÔÁÀÔÓÑ ÉÓÐÏÌØÚÏ×ÁÔØ ÐÏÄ ×ÒÅÍÅÎÎÏÅ ÈÒÁÎÉÌÉÝÅ ÞÅÇÏ ÎÉÂÕÄØ (ÅÓÌÉ ÏÎ ×ÄÒÕÇ ÇÄÅ ÔÏ ÏËÁÚÁÌÓÑ Ó×ÏÂÏÄÎÙÍ)

IT>>> ëÁË ÐÏÎÑÔØ "È×ÁÔÁÌÏ"? RK>> üÔÏ ËÏÇÄÁ ËÏÍÐÉÌÑÔÏÒÕ È×ÁÔÁÌÏ 4È ÒÅÇÉÓÔÒÏ× ÄÌÑ ÈÒÁÎÅÎÉÑ RK>> ÐÒÏÍÅÖÕÔÏÞÎÙÈ ÒÅÚÕÌØÔÁÔÏ×.

IT> (*)

IT>>> üÔÏ ËÏÇÄÁ × ÐÒÏÇÒÁÍÍÅ ÔÏÌØËÏ 4 ÐÅÒÅÍÅÎÎÙÅ, RK>> HÅÔ IT> ïÞÅ×ÉÄÎÏ. üÔÏ ÂÙÌÁ ÏÄÎÁ ËÒÁÊÎÏÓÔØ.

üÔÏ ÓÌÉÛËÏÍ ÓÉÌØÎÁÑ ËÒÁÊÎÏÓÔØ.

IT>>> ÉÌÉ ËÏÇÄÁ ÚÁ×ÉÓÉÍÏÓÔØ ÐÏ ÄÁÎÎÙÍ ÎÅ ×ÙÚÙ×ÁÅÔ ÐÒÏÓÔÏÅ× ËÏÎ×ÅÊÅÒÁ? RK>> HÅÔ. IT> á ËÁË ÜÔÏ ÓÏÏÔÎÏÓÉÔÓÑ Ó (*)? á ×ÏÔ ÄÅÒÖÉ ÐÒÉÍÅÒÞÉË:

IT> a = b + c + d (1) IT> b = a + d - Ó (2) IT> c = a + b + 3 (3) IT> d = a + b + c (4)

IT> HÁÌÉÃÏ WAR ÐÒÉ ÐÏÄÓÔÁÎÏ×ËÅ ÌÀÂÏÊ ÉÚ ÓÔÒÏË 2-4 ÐÏÓÌÅ 1.

óÔÒÏËÉ 2-4 ÚÁ×ÉÓÉÍÙ ÐÏ ÄÁÎÎÙÍ ÏÔ ÓÔÒÏËÉ 1, É ÔÁË ÂÕÄÅÔ ÐÒÉ ÌÀÂÏÍ ËÏÌÉÞÅÓÔ×Å ÒÅÇÉÓÔÒÏ×, ÎÉ 5Ê ÎÉ 25Ê ÚÄÅÓØ ÎÅ ÐÏÍÏÇÕÔ. èÏÔÑ ÄÁÖÅ ÉÈ ÍÏÖÎÏ ÒÁÓÐÁÒÁÌÅÌÉÔØ, ÄÏÐÕÓÔÉÍ Õ ÎÁÓ ÅÓÔØ ÓÕÐÅÒÓËÁÌÑÒ Ó 2ÍÑ ÎÁÂÏÒÁÍÉ áìõ É ËÁÎÁÌÏ× ÄÏÓÔÕÐÁ Ë ÐÁÍÑÔÉ É 4ÍÑ ÒÅÇÉÓÔÒÁÍÉ (t1-t4)

c->t1 d->t2 t1+t2->t3 t2-t1->t4 b->t2 t3+t2->t2 t2+t4->t4 t2->a t4->b t2+t4->t2 t2+3->t3 t2+t2->t4 t3->c t4->d

ôÏ ÅÓÔØ × ÓÒÅÄÎÅÍ 1.44 ËÏÍÁÎÄÙ ÚÁ ÔÁËÔ (ÞÔÏ ÏÞÅÎØ ÎÅÐÌÏÈÏ), É 5Ê ÒÅÇÉÓÔÒ ÚÄÅÓØ ÎÅ ÎÕÖÅÎ

IT>>> óÔÏÉÔ ÌÉ ÄÅÌÁÔØ ÎÏ×ÙÊ ÐÒÏÃÅÓÓÏÒ Ó ÄÏÐÏÌÎÉÔÅÌØÎÙÍ ÒÅÇÉÓÔÒÏÍ, RK>> åÓÌÉ ÔÁËÁÑ ÚÁÄÁÞÁ ÔÏÌØËÏ ÏÄÎÁ, ÔÏ ÏÞÅ×ÉÄÎÏ ÎÅ ÓÔÏÉÔ, Á ÅÓÌÉ ÐÏÞÔÉ RK>> ×ÓÅ ÚÁÄÁÞÉ ÔÁËÉÅ - ÔÏ ÓÔÏÉÔ. IT> ôÁË ÂÕÄÅÔ ÌÉ ×ÙÉÇÒÙÛ - ÜÔÏ ×ÅÄØ ÅÝÅ ÎÅ ÒÅÛÅÎÏ....

HÁ ÜÔÏ ÓÕÝÅÓÔ×ÕÀÔ ÜÍÕÌÑÔÏÒÙ, ÎÁ ÎÉÈ ÐÒÏÇÏÎÑÀÔ ÔÅÓÔÙ É ÐÏÌÕÞÁÀÔ ÔÅ ÓÁÍÙÅ ÃÉÆÒÙ, ÐÏ ËÏÔÏÒÙÍ É ÓÕÄÅÔ - ÂÕÄÅÔ ×ÙÉÇÒÙÛ ÉÌÉ ÎÅÔ.

IT> HÕ É ËÁË ÖÅ ÐÒÉËÁÖÅÛØ ÎÁÞÉÎÁÔØ ÒÁÂÏÔÕ ÎÁÄ ÎÏ×ÙÍ ÐÒÏÃÅÓÓÏÒÏÍ, ÅÓÌÉ IT> ÓÎÁÞÁÌÁ ÄÌÑ ÎÅÇÏ (ÐÏËÁ ÅÝÅ ×ÉÒÔÕÁÌØÎÏÇÏ) ÎÁÄÏ ÎÁÐÉÓÁÔØ ËÕÞÕ ÐÒÏÇÒÁÍÍ,

HÁÄÏ ÂÒÁÔØ ÇÏÔÏ×ÙÅ. åÓÌÉ ÉÈ ÎÅÔ - ÔÏ ÎÅ ÎÁÄÏ É ÐÒÏÃÅÓÓÏÒ ÓÔÒÏÉÔØ. á ÅÓÌÉ ÅÓÔØ ÎÅÏÂÈÏÄÉÍÏÓÔØ ÉÍÅÎÎÏ ÐÏÄ ÎÅÇÏ ÓÐÅÃÉÁÌØÎÏ ÎÁÐÉÓÁÔØ ÐÒÏÇÒÁÍÍÕ - ÔÏ ÚÎÁÞÉÔ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔØ ÅÇÏ ÎÅ ×ÁÖÎÁ É ÏÃÅÎÉ×ÁÔØ ÎÅÞÅÇÏ :)

IT> ÐÒÏÔÅÓÔÉÒÏ×ÁÔØ ÉÈ ÎÁ ÍÏÄÅÌÑÈ, É ÕÚÎÁÔØ Õ ÔÅÈÎÏÌÏÇÏ×, ËÁË ÂÕÄÅÔ IT> ÍÅÎÑÔØÓÑ ÞÁÓÔÏÔÁ ÐÒÏÃÅÓÓÏÒÁ × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÓÌÏÖÎÏÓÔÉ ×ÎÕÔÒÅÎÎÉÈ IT> ÓÏÅÄÉÎÅÎÉÊ?

äÁ.

IT> äÁ, ÜÔÏ ÏÞÅÎØ ÒÅÁÌØÎÏ ÐÒÉ ÍÎÏÇÏÍÉÌÌÉÏÎÎÙÈ ×ÌÏÖÅÎÉÑÈ × IT> ÐÒÏÅËÔ, Ñ Ó ÜÔÉÍ É ÎÅ ÓÐÏÒÀ. ïÄÎÁËÏ ×ÙÓËÁÚÙ×ÁÀ ÍÎÅÎÉÅ, ÞÔÏ ÓÏ IT> ÓÔÅËÏ×ÏÊ ÁÒÈÉÔÅËÔÕÒÏÊ ÐÒÏÂÌÅÍ ÂÕÄÅÔ ÍÅÎØÛÅ, ÐÏÓËÏÌØËÕ Õ×ÅÌÉÞÅÎÉÅ IT> ÇÌÕÂÉÎÙ ÓÔÅËÁ ÎÅ ÓÏÐÒÏ×ÏÖÄÁÅÔÓÑ ÐÅÒÅÓÍÏÔÒÏÍ ÏÓÎÏ×ÎÙÈ ÁÌÇÏÒÉÔÍÏ×.

õ×ÅÌÉÞÅÎÉÅ ÞÉÓÌÁ òïHÏ× - ÔÏÖÅ.

RK>> ñ ÎÅ ÕÔ×ÅÒÖÄÁÀ, ÞÔÏ æÏÒÔ ÎÉËÕÄÁ ÎÅ ÇÏÄÉÔÓÑ. åÓÔØ ÐÒÉÌÏÖÅÎÉÑ, ÇÄÅ RK>> ÏÎ ËÁÔÅÇÏÒÉÞÅÓËÉ ÎÅ ÐÏÄÈÏÄÉÔ, Á ÅÓÔØ, ÇÄÅ ÏÎ ÉÍÅÅÔ ÐÒÅÉÍÕÝÅÓÔ×Ï:

RK>> æÏÒÔ ÐÒÏÃÅÓÓÏÒ ËÁÔÅÇÏÒÉÞÅÓËÉ ÎÅ ÐÏÄÈÏÄÉÔ ÄÌÑ: RK>> 1) éÚÇÏÔÏ×ÌÅÎÉÑ ÎÁ ÅÇÏ ÂÁÚÅ top-preformance ÐÒÏÃÅÓÓÏÒÁ

IT> ÷ ÃÅÌÏÍ ÓÏÇÌÁÛÕÓØ, É ÐÒÉÄÅÒÖÉ×ÁÀÓØ ÔÏÊ ÖÅ ÐÏÚÉÃÉÉ. óÔÅËÏ×ÏÅ ÑÄÒÏ ÍÎÅ IT> ÓÅÊÞÁÓ ÏÞÅÎØ ÎÒÁ×ÉÔÓÑ ÄÌÑ ÒÅÁÌÉÚÁÃÉÉ embedded-ÐÒÏÃÅÓÓÏÒÏ× × ðìéó, ÇÄÅ IT> ÏÎÏ ÚÁÎÉÍÁÅÔ ÍÁÌÏ ÍÅÓÔÁ, ÐÏÚ×ÏÌÑÑ ÐÒÉ ÜÔÏÍ ÐÉÓÁÔØ ÎÁ ñ÷õ ÄÌÑ 16-32 IT> ÒÁÚÒÑÄÏ× É 20-40 íçÃ.

RK>> æÏÒÔ ÐÒÏÃÅÓÓÏÒ ÐÏÄÈÏÄÉÔ ÄÌÑ: RK>> 1) ðÒÉÍÅÎÅÎÉÑ × ËÁÞÅÓÔ×Å ÐÒÏÃÅÓÓÏÒÁ ÄÌÑ ËÏÔÏÒÏÇÏ ÁÓÓÅÍÂÌÅÒÏÍ RK>> Ñ×ÌÑÅÔÓÑ ñ÷õ (ÅÓÌÉ æÏÒÔ ÔÁËÏ×ÙÍ ÍÏÖÎÏ ÎÁÚ×ÁÔØ :), ÐÒÉ ÜÔÏÍ ÉÍÅÅÔ RK>> ÚÎÁÞÅÎÉÅ ËÏÍÐÁËÔÎÏÓÔØ ËÏÄÁ É ÎÅ ÉÍÅÅÔ ÚÎÁÞÅÎÉÅ RK>> ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔØ. (÷ÅÓØÍÁ ÕÍÏÚÒÉÔÅÌØÎÙÊ ÐÒÉÍÅÒ :)

IT> äÁ. ëÓÔÁÔÉ, ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔØ ×ÓÅ ÖÅ ÎÅ ÔÁË ÐÌÏÈÁ, ÒÅÇÉÓÔÒÏ×ÁÑ IT> ÁÒÈÉÔÅËÔÕÒÁ ÎÅ ÄÁÅÔ ÓÕÝÅÓÔ×ÅÎÎÏÇÏ ×ÙÉÇÒÙÛÁ... ÅÓÌÉ ×ÏÏÂÝÅ ÄÁÅÔ ÅÇÏ × IT> ðìéó.

RK>> æÏÒÔ, ËÁË ÓÉÓÔÅÍÁ ÐÒÏÇÒÁÍÉÒÏ×ÁÎÉÑ, ÐÏÄÈÏÄÉÔ ÄÌÑ: RK>> 1) ðÌÁÔÆÏÒÍ, ÔÉÐÁ OpenBoot (æÏÒÔ ÚÁÛÉÔ × ðúõ É ÓÌÕÖÉÔ ÄÌÑ RK>> ÚÁÇÒÕÚËÉ ÓÉÓÔÅÍÙ). ðÒÉ ÜÔÏÍ ÄÒÁÊ×ÅÒÁ ÒÁÚÌÉÞÎÙÈ ËÁÒÔ (ÓÅÔØ, ÄÉÓË É RK>> ÄÒ.), Ó ËÏÔÏÒÙÈ ÐÒÏÉÚ×ÏÄÉÔÓÑ ÚÁÇÒÕÚËÁ, ÎÁÐÉÓÁÎÙ ÎÁ ÜÔÏÍ ÓÁÍÏÍ RK>> æÏÒÔÅ É ÚÁÛÉÔÙ × ðúõ ÎÁ ÜÔÉÈ ËÁÒÔÁÈ. (ëÓÔÁÔÉ, × ÓÐÅÃÉÆÉËÁÃÉÉ PCI RK>> ÅÓÔØ ÐÅÒÅÞÉÓÌÅÎÉÅ ÐÌÁÔÆÏÒÍ, ÄÌÑ ËÏÔÏÒÙÈ ÎÁ PCI ËÁÒÔÁÈ ÍÏÇÕÔ RK>> ÎÁÈÏÄÉÔÓÑ ÄÒÁÊ×ÅÒÁ ××ÏÄÁ-×Ù×ÏÄÁ, ÜÔÏ x86 - ÒÁÓÛÉÒÅÎÉÑ BIOS'Á, É RK>> OpenBoot) 2) ðÌÁÔÆÏÒÍ, ÇÄÅ ÎÅÏÂÈÏÄÉÍÏ ÉÍÅÔØ ÉÎÔÅÒÐÒÅÔÁÔÏÒ ÄÌÑ RK>> ÉÓÐÏÌÎÅÎÉÑ ËÏÄÁ ÉÚ ÂÏÌØÛÏÊ ×ÎÅÛÎÅÊ ÐÁÍÑÔÉ (ÐÒÏÃÅÓÓÏÒ, ÔÉÐÁ PIC É RK>> AVR ÐÌÀÓ ÂÏÌØÛÏÊ ×ÎÅÛÎÉÊ EEPROM). é ÔÏ, × ÜÔÏÍ ÓÌÕÞÁÅ æÏÒÔ RK>> ËÁË ÑÚÙË ÐÒÏÇÒÁÍÉÒÏ×ÁÎÉÑ ÄÌÑ ÜÔÉÈ ÐÌÁÔÆÏÒÍ ÍÁÌÏ ÐÒÉÇÏÄÅÎ (ÉÚ ÚÁ RK>> ÅÇÏ ÎÅÏÂÙÞÎÏÓÔÉ), Á ×ÏÔ æÏÒÔ VM ×ÐÏÌÎÅ ÐÒÉÇÏÄÎÁ.

IT> é Ó ÜÔÉÍ ÐÏÌÎÏÓÔØÀ ÓÏÇÌÁÛÕÓØ. úÁÍÅÔØ, ÏÄÎÁËÏ, ÞÔÏ ÓÆÅÒÁ ÐÒÉÍÅÎÅÎÉÑ ×ÓÅ IT> ÖÅ ÐÏÑ×ÌÑÅÔÓÑ, É ÄÏ×ÏÌØÎÏ ÏÂÛÉÒÎÁÑ...

éÔÁË, ËÏÎÓÅÎÓÕÓ ÐÏ ×ÓÅÍ ÐÏÚÉÃÉÑÍ. é Ï ÞÅÍ ÖÅ ÍÙ ÔÏÇÄÁ ÓÐÏÒÉÍ?

Roman

Hello Ilia.

05 Oct 03 23:35, you wrote to me:

RK>> á ÓÔÅË ÎÁ ÞÅÍ ÒÁÓÐÏÌÏÖÅÎ? éÌÉ ÏÔ ÔÏÇÏ, ÞÔÏ ÏÎ ÓÔÅË ÏÎ ÐÅÒÅÓÔÁÌ RK>> ÓÏÓÔÏÑÔØ ÉÚ ÒÅÇÉÓÔÒÏ×?

IT> HÁ ÐÁÍÑÔÉ ×ÏÏÂÝÅ-ÔÏ. üÔÏ ÐÒÏÝÅ, ÞÅÍ ÒÅÇÉÓÔÒ...

á 'ÐÁÍÑÔØ' - ÜÔÏ ÇÄÅ? åÓÌÉ ÎÁ ËÒÉÓÔÁÌÅ, ÔÏ ÜÔÏ ÔÅ ÖÅ ÒÅÇÉÓÔÒÙ, ÅÓÌÉ ÓÎÁÒÕÖÉ - ÔÏ ÜÔÏ ÂÕÄÅÔ _ÖÕÔËÉÊ_ ÔÏÒÍÏÚ.

Roman