_Loader_

Loading thread data ...

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 вполне пригодна.

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

Reply to
Ilia Tarasov

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>>

formatting link
Там описание стекового процессора в ПЛИС. 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 имеет все же больше академическую ценность, но вот для стековой архитектуры такой подход становится очень интересным.

Reply to
Ilia Tarasov

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

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

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

Reply to
Ilia Tarasov
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,

Reply to
Oleksandr Redchuk
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,

Reply to
Oleksandr Redchuk
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,

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

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

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

wbr,

Reply to
Oleksandr Redchuk

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> чтобы выделиться, иметь возможность считать себя "круче" остальных.

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

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

Reply to
Ilia Tarasov
Reply to
Artem Kamburov
Reply to
Artem Kamburov

Hi Roman,

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

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

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

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

formatting link
этот проц сделан на основе патента, взятого Чаком Муром, "отцом-основателем" Форта. Эти ребята бросают вызов всем: 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-битном проце с сотнями К памяти.

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

Reply to
Alex Kouznetsov

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> Улёт....

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

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

Reply to
Alex Kouznetsov

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. А то некоторые упертые попробовали Форт раз-другой, не смогли его освоить, и теперь на всех углах хают как сам Форт, так и тех, кто может его использовать.

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

Reply to
Alex Kouznetsov

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

Аркадий

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

Reply to
Arcady Schekochikhin
Reply to
Vadim Rumyantsev

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.