В действительности FPGA обходятся производителю существенно дешевле. Другое дело, что пересылка чего бы то ни было тоже стоит денег. Продавая готовую отладочную плату, производители стимулируют покупателей не тратить время на выполнение рутинных инженерных операций, в процессе чего можно в десятке мест запороть плату/чип и потерять интерес к микросхеме как таковой. Гораздо выгоднее продать недорогое средство разработки, чтобы появлялись интересные изделия, которые уже можно будет выпускать крупными тиражами. Бывают и совсем интересные варианты - там плата+софт стоят дешевле, чем установленная ПЛИС.

А если на одной и той же FPGA разные разработчики сделали разные форт-схемы, у которых скорости различаются на порядок?

Кстати вот посчитал: в моем ARM-форте около 40 CODE-слов, из них 14 выполняются за один такт, 17 за два.


Правильно. Когда писал инициализаторы модулей контроллера и настраивал pinout'ы, то мне тоже эта аналогия приходила в голову. ARM - это разновидность FPGA с более крупными и более функциональными блоками (и по этой причине менее гибкими, чем простой FPGA). Т.е. как языки низкого и высокого уровня.


Программа на асме вероятно будет быстрее чем на Си. А программа на SPF с оптимизатором имени ~mak быстрее, чем на TCC (можно сравнить прямо из форта - ~ac/lib/lin/lang/tcc/tcc.f ). И я думаю, что даже на Форт-процессоре (любом) сишный "длиннофункциональный" стиль программирования будет давать более быстрый код, чем фортовый стиль. Так что всё относительно. Тем более если под "выжать" понимать производительность, а не объем функционала. Т.к. Си не сможет тягаться с (неоптимизированным) Фортом по плотности кода.

Значит, мы говорим о более или менее эффективном форт-процессоре.

Что такое FPGA - записано в патенте на FPGA. Исходя из этого патента, ARM - это не разновидность FPGA. С точки зрения разработчика это тоже не FPGA, потому что я могу написать поведенческий или RTL-код, и FPGA сможет его реализовать, а ARM - нет (процессоры вообще не могут реализовать HDL-описания произвольных схем, они сами описываются вполне определенными языковыми структурами *HDL).

Наиболее быстрой будет не "программа на языке <languagename>", а та программа, которая наиболее эффективно использует типы транзакций данных, реализуемых процессором. Именно транзакций, а не команд, если учитывать, что команды могут выполняться за разное число тактов. Откуда получить такой код - второй вопрос. Соревнование тут идет не между входными языками, а между внутренними представлениями кода. Регистровому ARM удобнее работать с регистровыми представлениями, стековому процессору - со стековыми. Раз Форт без проблем генерирует именно стековые представления, то ему удобнее работать на процессоре с аппаратной поддержкой стека. Оптимизатор генерирует шаблоны кода для регистров ARM? Замечательно, вот и объяснение эффекта. А вот если ARM будет по-честному эмулировать стек данных (в ядре его нет, так что придется в памяти), то тут он и проиграет процессору с аппаратным стеком.

А если тот разработчик, у которого наименее эффективный форт-процессор получился, делал его так: сначала сделал ARM-процессор, а потом в его кодах сделал форт?


А у него (контроллера) память в ядре, на независимой шине. И стековые команды (часть стековых команд; ты не ответил, сколько их надо для форт-процессора) реализуются однотактно.


Так ведь и на Си, и вообще почти на любом языке, проще генерировать именно стековые представления. На регистры все перешли не от хорошей жизни, а потому что еще в 60-70х народу показали, что регистровые машины быстрее. А до этого выпускали и стековые машины, в т.ч. ту, из которой Мур почерпнул часть своих идей (была ссылка на f.o.r).

Процессоры могут всё. Тебе ведь не обязательно все HDL-схемы в железе проверять, можно и в эмуляторе на PC.
Другое дело, что это будет медленнее (при условии равной базовой частоты).

Не знал, да ещё и забыл:) i.MX51 - "Forth" CPU (вроде стековый)
Freescale i.MX51 Android Tablet prototype develop
На плате FORTH обозначен.

То этот разработчик сделал ARM. Можно ведь и томик Пушкина использовать в качестве гнета для закваски капусты. Теперь гнет для закваски надо делать так же, как печатается Пушкин?

Так на шине, или в ядре? Ядро процессора - это достаточно плотная и компактная часть, если есть еще память, то она не является частью ядра процессора.

Чем больше, тем лучше. Вопрос тут не в количестве команд, а в том, насколько то, что делает процессор, соответствует тому, что требуется команде Форта.

Да, быстрее, если брать в среднем. Стек действительно имеет "бутылочное горлышко" в виде своей вершины, поэтому добиваться экстремально высокой производительности на стековой машине сложнее, чем на машине с регистровым файлом. Но мы о чем говорим-то? Ты хочешь под термином "форт-что-то" понимать просто самое быстрое, выразительное, эффективное и т.п.?
Вот к примеру, есть понятие адресности процессора. Например, add r3, r4, r7 - трехадресная команда. А add eax, ebx - двухадресная. Несмотря на то, что я могу написать add r3, r3, r7, первый процессор от этого двухадресным не станет. Точно так же ARM не становится стековым процессором.

Это не реализация, а моделирование. Реализация - когда я пишу c <= a nand b; и получаю 1 (один) вентиль в сколько-то квадратных микрон площадью. А не когда я для этой операции раскочегариваю ARM.

Слишком толстый. Я такой не куплю. Даже если внутри форт. Вот когда он будет потоньше, да со всякими плюшками внутрях - тогда можно и подумать будет.

На шине в ядре. В отличие от внешней шины к другим чипам.


А где конкретно там форт? Если девайс разработан конторой с названием FORTH, то этого недостаточно для превращения ARM Cortex A8 в форт-процессор...

Т.е. сишный стек - это не стек вовсе?

А если в форт-процессоре с правильным стеком вдруг добавят регистры (для реализации локальных переменных, допустим), то он перестанет быть форт-процессором?

Хорошая штучка, чтобы побаловаться, но есть и пара ложек дегтя...
VGA-выхода нет, PS/2 входа нет... т.е. придется внешнюю платку
с этими делами приделывать самому. 79$ - это у производителя цена,
сколько накрутят, пока в Россию привезут - совсем не ясно.

ПЛИС по объему всего на 22К LCELL, и по характеристикам Cyclone-IV
мало отличается от Cyclone-III.

Короче, я бы такую, если бы и взял, то только в подарок.
А свои кровные 2.5тыр потратил бы на изготовление платы
с Cyclone-III с тем, что мне нужно в комплекте.

А если до этого никто такого не делал, ARM'ом не называл, а разработчик назвал это "вот такая у меня система форт-команд"? И команда LDR называется у него "@", а PUSH {R0} называется "DUP".

Память не входит в ядро процессора. Внешняя шина памяти отличается от внутренней прежде всего характеристиками производительности. Сколько и чего за такт сможет сделать эта память на внутренней шине? У нее один адрес?

Стек - он не сишный, он стек процессора с определенным типом поддержки системой команд. Там есть PUSH и POP? Этого недостаточно для Форта, придется дорабатывать.

Да, он будет процессором общего назначения с поддержкой стекового режима.

Это будет процессором, на котором удобно и эффективно сделать Форт. А вот на кой там PUSH {R0} -то? Вообще-то, с точки зрения архитектуры, Форт-процессор должен быть 0-адресным, то есть никаких R0 у него в команде быть не должно. Потому что, если PUSH можно сделать с регистрами от R0 до R15, то это лишние 4 бита в команде. Команда растет, уменьшается плотность кода, увеличивается площадь кристалла (хотя на нее-то как раз можно обращать меньше внимания, а вот размер команды - это серьезнее).

А как же фортовая команда PICK (94 CORE EXT)? Для её эффективной реализации желателен индексный доступ к стеку.

Это вопрос оптимизации архитектуры. Имеет ли смысл увеличивать размер всех команд, чтобы иногда использовать команду из расширенного набора? Можно и ROLL вспомнить, это еще интереснее с точки зрения реализации. К '94 вообще много вопросов... риторических.