[quote="WingLion"]Неужели это заговор?[/quote]Не думаю.
[quote="WingLion"]или это фортеры мысль зажали и никому не дають?[/quote]Очень сомневаюсь. Тем более что самый успешный стековый процессор ничего общего с фортом не имел. :)

[quote="Forthware"]Однако почему то они упорно не рапространяются...[/quote]
Неужели это заговор?
Интересно, чей?
Интеля против всего мира и фортеров?
или это фортеры мысль зажали и никому не дають? :))

[quote="WingLion"]И какой же это Такой Глобальный Закон запретит мне прочитать одну и ту же переменную сразу одновременно в два канала?[/quote]Хорошо. Убедили. Я такого закона не знаю. :)
[quote="WingLion"]безусловно, для возможности широкого рспространения форт-процессоров существует принципиально-непреодолимое препятствие![/quote]Ладно, пусть будет что его нет. Я не против. Однако почему то они упорно не рапространяются... :roll:
[quote="WingLion"]И его зовут Ктулху Фтагн.[/quote]Это врядли. :lol:

[quote="Forthware"]Этот конкретный пример невозможно паралелизовать на СТЕКОВОЙ машине, поскольку вторая копия A@ недоступна до завершения комманды C! . Поэтому повторю еще раз: [/quote]
Припаять два провода к одной точке уже нельзя??? :shock:

[quote="Forthware"]Этот конкретный пример невозможно паралелизовать на СТЕКОВОЙ машине, поскольку вторая копия A@ недоступна до завершения комманды C![/quote]

Здравствуйте, я ваша тетя! И какой же это [b]Такой Глобальный Закон[/b] запретит мне прочитать одну и ту же переменную сразу одновременно в два канала?

[quote="Forthware"]Поэтому повторю еще раз: [/quote]
Вы полагаете, что от повторения чего-либо оно немедленно станет правдой?
Попробуйте поповторять: [b]2+2=5[/b]

[quote="Forthware"]не доказывают возможности широкого распространения форт-процессоров[/quote]

безусловно, для [u]возможности[/u] широкого рспространения форт-процессоров существует принципиально-непреодолимое препятствие! И его зовут [b]Ктулху Фтагн[/b]. :))

[quote="Хищник"]Совокупность индивидуальных наработок и определяет техническую область. А в более общем смысле - вообще технический прогресс.[/quote]Не спорю. Но мы тут не о техническом прогрессе говорили.
[quote="Хищник"]Эээ... в пятницу я смогу дать документальный ответ на этот вопрос (надеюсь)[/quote]Действительно? Ну тогда искренне желаю вам успеха! :D Честно говоря, такая новость была бы очень приятной для меня. :)

[quote="Forthware"]То Хищник. Хорошо, если вы переводите разговор в русло индивидуальных наработок, мне нечего вам предоставить.[/quote]
"А кому же еще американский президент должен чистить ботинки?" (с) Линкольн (?) Совокупность индивидуальных наработок и определяет техническую область. А в более общем смысле - вообще технический прогресс.
[quote="Forthware"]Однако ваши наработки никоим образом не доказывают возможности широкого распространения форт-процессоров. Верно? [/quote]
Эээ... в пятницу я смогу дать документальный ответ на этот вопрос (надеюсь) :)

[quote="Хищник"]Какая правильная теория, и как она потрясающе не соответствует конкретно приведенному примеру...[/quote]Этот конкретный пример невозможно паралелизовать на СТЕКОВОЙ машине, поскольку вторая копия A@ недоступна до завершения комманды C! . Поэтому повторю еще раз:
[quote="Forthware"](теоретически это возможно, но результат будет регистровой архитектурой с оптимизирующим рантайм компилятором, который будет переводит код стековой машины).[/quote]

То [b]Хищник[/b]. Хорошо, если вы переводите разговор в русло индивидуальных наработок, мне нечего вам предоставить. Однако ваши наработки никоим образом не доказывают возможности широкого распространения форт-процессоров. Верно?

[quote="Хищник"]Я понял - у меня глюки Прямо на столе лежат...[/quote]Нет это не глюки, а реализации совершенно нераспространенных процессоров, в отличии от Transputer.

[quote="Forthware"]WingLion писал(а):
ежу видно, что такой код легко паралелится

Forthware писал(а):
большинство комманд зависимы от предыдущих, и зависимость эту очень трудно устранить (теоретически это возможно, но результат будет регистровой архитектурой с оптимизирующим рантайм компилятором, который будет переводит код стековой машины).[/quote]
Какая правильная теория, и как она потрясающе не соответствует [b]конкретно [/b]приведенному примеру...

[quote="WingLion"] ежу видно, что такой код легко паралелится[/quote]
[quote="Forthware"]большинство комманд зависимы от предыдущих, и зависимость эту очень трудно устранить (теоретически это возможно, но результат будет регистровой архитектурой с оптимизирующим рантайм компилятором, который будет переводит код стековой машины).[/quote]

[quote="Forthware"]Однако, Jazelle медленнее нативного кода ARM. [/quote]
Jazelle быстрее выполняет код JVM, чем ARM, и это в данном случае главное.
[quote="Forthware"]Ну, кому как. И теория и практика показывают что таки следует.[/quote]
И чья же это "теория и практика"? Потому что из моей практики следует, что нет ;) Ну я не знаю, конечно... можно ее не принимать во внимание, как "не массово распространенную в каждом компьютере, телефоне и кофеварке" :)) Но дела это не меняет - имеем одного человека с эффективным стековым процессором, и одного - без такого процессора. :lol:
[quote="Forthware"]Не все - в результате получаем большее количество комманд пересылки данных но меньший размер кода в байтах.[/quote]
Ого! Ну и где мы это "получаем"? Что за проект, сколько там команд? Что за "большее количество команд пересылки данных", и откуда они вообще взялись?
[quote="Forthware"]Вот именно. В стековом нуль операндном коде не может присутствовать потенциал для паралелизации. [/quote]
Странно. А из моих работ следует, что он там вовсю присутствует. Правда, что такое рецензируемый журнал из ВАКовского списка по сравнению с мнением Forthware? :))
[quote="Forthware"]Нет? Тогда покажите стековый процессор более производительный за провальный NetBurst.[/quote]
С NetBurst не сравнивал, но лучший CPI, чем в Pentium, вполне получал. Если посмотреть - так это в моей части отчета по проекту EUROPRACTICE, там все это подробно описано. ;)
[quote="Forthware"]Это, типа тот, который стек возвратов? Он тут не поможет, вы не можете использовать его непосредственно с АЛУ,[/quote]
Интересное заявление. Если рядом стоят два триггера, то писать во второй по каким-то причинам нельзя, если идет запись в первый? Ну-ну...
[quote="Forthware"]Хищник писал(а):
Видно, те люди были единственными, кто умел и умеет делать стековые процессоры...
Возможно, раз у других ничего не получилось... [/quote]
Я понял - у меня глюки :)) Прямо на столе лежат... :)

[quote="Forthware"]Нуль операндный код практически невозможно паралелизовать,[/quote]

возьмем кусок тупой программы для стековой архитектуры и на нем легко видим, что "практические невозможно" - это туфта на постном масле:
[code]A@ DUP B@ + C! E@ * D![/code]

Мало того, что и ежу видно, что такой код легко паралелится,
на Форте этот параллелизм можно и явно задать:
[code]
1CPU: А@ B@ + C!
2CPU: A@ E@ * D!
3CPU: И-ТЫ ОТ-РАБОТЫ НЕ-ОТЛЫНИВАЙ ПАДЛА!
[/code]

[quote="Хищник"]В виде добавки Jazelle к ARM,[/quote]Это уже обратная сторона медали - как язык, имеющий большую распространенность, подтягивает за собой железо. Однако, Jazelle медленнее нативного кода ARM.
[quote="Хищник"]Это ниоткуда не следует![/quote]Ну, кому как. :roll: И теория и практика показывают что таки следует.
[quote="Хищник"]Семантика у них не настолько проста, чтобы каждая команда 2- или 3-адресного ядра разворачивалась в пяток 0-адресных.[/quote]Конечно не настолько! :lol: В зависимости от кода, разница обычно в пределах 1.3-2 раза (по количеству комманд). Это если сравнивать с RISC. Если же взять CISC, то некоторые инструкции, со сложными методами адресации могут разложится на "пяток" и больше стековых. Но это не показатель, поскольку выполняются эти CISC комманды тоже значительно дольше (много такотов), либо преобразуются в последовательность из нескольких RISC комманд и потом исполняются. Так что я сравниваю непосредственно с RISC.
[quote="Хищник"]Нет индекса регистра - компактнее команда, и все.[/quote]Не все - в результате получаем большее количество комманд пересылки данных но меньший размер кода в байтах. Первое является принципиальным ограничением, второе легко компенсируется экстенсивным наращиванием системы (разрядность).
[quote="Хищник"]27 кб на PPC-подобной архитектуре против 12 кб на стековом процессоре.[/quote]По чем килограмм гвоздей? :lol: Как перевести эти числа в количество комманд?
[quote="Хищник"]Тут наоборот, чем короче конвейер, тем меньше "висячих" записей в нем могут сидеть.[/quote]Это верно, но чем длиннее конвейер тем выше тактовая частота. На практике видно, что обычный код регистровой архитектуры х86 может эффективно наполнить даже два конвейера более 10 ступеней каждый. Нульоперандный код не может эффективно наполнить один конвейер длиннее 2-3 ступеней. Правда конвейеры многооперандных машин содержат "лишние" ступени, которых просто нет в стековых. Поэтому прирост производительности надо оценивать не по общей длине конвейера, а по тому, какая длина такта нужна для его работы. У стековых, это, грубо говоря, задержка ALU. В регистровых ALU может состоять из нескольких стадий, соответственно задержка может быть в несколько раз меньше.
[quote="Хищник"]Для стека характерно то, что данные обычно сидят на его вершине, поэтому альтернативного варианта "записали туда, а в это время читаем из другого места" не просматривается.[/quote]Вот именно. В стековом нуль операндном коде не может присутствовать потенциал для паралелизации.
[quote="Хищник"] Но out-of-order и спекулятивные вычисления уже достигли своего апогея в Pentium-IV, дальше эта гонка за гигагерцами с разбиением конвейера на все более и более мелкие кусочки уже ведет в тупик.[/quote]Совершенно верно! Регистровые архитектуры тоже имеют принципиальные ограничения. И я уже говорил, что достигли они их где то после 2000 года. Или вы не внимательно читаете? :?
[quote="Хищник"]Только "возможно" от "реально встречается" отличается очень сильно.[/quote]Если бы реально не встречалось, тогда бы второй конвейер сушил весла, и 66МГц Пентиум был бы медленнее за 80МГц 486. А вот на третий, уже реально не хватает, что видно на примере Атлонов.
[quote="Хищник"] Вплоть до отказа от архитектуры NetBurst.[/quote]Да, это и есть тот предел о котором говорил я. Такие длииииинные конвейеры уже не получается наполнить используя машинный код х86. Для стековых машин, аналогом NetBurst был T-9000.
[quote="Хищник"]Ну и почему я такого эффекта ни разу не наблюдал?[/quote]Нет? Тогда покажите стековый процессор более производительный за провальный NetBurst.
[quote="Хищник"]Особенно мне понравилось про "в несколько раз" То есть ядро с гораздо более простой топологией и меньшим количеством сложных мультиплексоров априори имеет меньшую частоту?[/quote]Смотрите на NetBurst. Частоту можно наращивать тремя путями: технологиями, уменьшением задержки в схеме за счет ее упрощения, паралелизацией (конвейер). Первое для всех одинаково. Второе тоже - ALU проще не сделаешь. Третье ограничено возможностью паралелизации исходного кода. Нуль операндный код практически невозможно паралелизовать, регистровый в какой то степени можно, VLIW значительно лучше и т.д.
[quote="Хищник"]Эта... как его... у Форта-то как раз два стека.[/quote]Это, типа тот, который стек возвратов? :) Он тут не поможет, вы не можете использовать его непосредственно с АЛУ, поскольку в коммандах нет операнда задающего номер используемого стека, в противном случае, это уже будет однооперандная архитектура, которой форт процессоры не являются по определению. А так, что из него гонять данные на DS и обратно, что из памяти (через кэш естественно), особой разницы нет. К тому же, этот стек есть и у регистровых архитектур.
[quote="Хищник"]Видно, те люди были единственными, кто умел и умеет делать стековые процессоры...[/quote]Возможно, раз у других ничего не получилось... :roll:


[quote="WingLion"]Получается, что как бы я ни старался (непосредственно сейчас, на своей работе) у меня ничего не выйдет ведь "никакое усложнение конструкции не принесет вам нужный уровень"[/quote]Я уточнял что я имею ввиду. Исполнение одной программы представленной в виде кода стековой безоперандной машины ограничено одной коммандой на такт, как бы вы не усложняли реализацию. Это ограничение принципиально. Другой вопрос что в вашей работе оно может не играть никакой роли.
[quote="WingLion"]Тут дело уже вовсе не в Форте. Проблемы... они, знаете ли, в головах... (с) уж и не знаю чей[/quote]Ну, да, естественно. Если бы не эти "проблемы в головах", мы бы уже давно жили при коммунизме. :roll: :))
"Плохому процессору программист мешает..." (с) (говорили про i860)
[quote="WingLion"]Для начала, стек - не один! Стеков, как минимум, два помножить на количество форт-процессоров в одном кристалле. 3 штуки - это знаете ли, на микросхеме, которая уже сейчас устарела, в ту, на которойе работаю - сейчас и 30 штук войдет, и не запищит, як корова, лезущая в улей.[/quote]Еще раз, возможность построения многопроцессорных систем тут ни при чем. Я уверен что вы получите нужную вам производительность и сможете запрограммировать нужное вам колличество процессоров. И их архитектура в данном случае роли не играет. Я не знаю особых ограничений стековой архитектуры в плане построения многопроцессорных систем.
[quote="WingLion"]т.е. Вы утверждаете, что люди пишут задачи под архитектуры, а не архитектуры под задачи делают?[/quote]Нет, я утверждаю что любой алгоритм представленный в виде кода нульоперандной машины практически не возможно паралелизовать.
Хотя, насчет "архитектуры под задачи делают" можно сильно усомниться, зная какая архитектура у нас самая распространенная (на рынке РС). :roll:
[quote="WingLion"]Это и означает, что интель форт-процессору (у которого одна команда за такт выполняется) в такой задаче просто сольет...[/quote]Ну да. В сферическом вакууме. А на практике такого не бывает.

[quote="Forthware"]то никакое усложнение конструкции не принесет вам нужный уровень производительности.[/quote]

однако, у Вас и шуточки... :shock:
Получается, что как бы я ни старался (непосредственно сейчас, на своей работе) у меня ничего не выйдет :shock: :shock: ведь [b]"никакое усложнение конструкции не принесет вам нужный уровень"[/b]

[quote="Forthware"]Языки позволяющие лучше других генерировать паралельный код нынче не в моде.[/quote]
Иззвините, а [b]ФорД[/b] на каком языке описывал, как надо конвееры на заводах строить, чтобы они машины выпускали?

Так, чисто для справки. Язык [b]AHDL[/b], на котором я описываю свою архитектуру под свою задачу (и никак не наоборот) - параллелен - [b]АБСОЛЮТНО и ПРИНЦИПИАЛЬНО[/b]. Про моду - не знаю. Кому-то нравится VHDL, a не AHDL.

[quote="Forthware"]Однако Форт такому не способствует. Трудно делать что либо паралельное вокруг одного стека. [/quote]
Тут дело уже вовсе не в Форте. Проблемы... они, знаете ли, в головах... (с) уж и не знаю чей

Для начала, стек - не один! Стеков, как минимум, два помножить на количество форт-процессоров в одном кристалле. 3 штуки - это знаете ли, на микросхеме, которая уже сейчас устарела, в ту, на которойе работаю - сейчас и 30 штук войдет, и не запищит, як корова, лезущая в улей.

Скажете, я не сделаю через дцать лет не 30, а все 300 в одном чипе? Или у меня мозги расплавятся написать к ним программу?


[quote="Forthware"]Реальные задачи описаные нульоперандной стековой системой комманд практически не распараллевиваются никогда. И проблема не в задаче, а в архитектуре. Тоесть, архитектура не дает средств для описания паралельных задач. [/quote]
т.е. Вы утверждаете, что люди пишут задачи под архитектуры, а не архитектуры под задачи делают?
:shock: :shock: :shock:

[quote="Forthware"]Задача, которую принципиально распаралелить нельзя, не будет распаралелена ни на каком процессоре. Она будет сбрасывать конвейер с каждой коммандой, при этом время выполнения комманды будет не меньше количества тактов равного количеству ступеней конвейера. Но на практике такое бывает очень редко. [/quote]
Это и означает, что интель форт-процессору (у которого одна команда за такт выполняется)
в такой задаче просто сольет...