Данная статья пишется с несколькими целями: изложить возможные методы повышения быстродействия стековых процессоров, собрать попутно небольшую библиографию, и закрепить на данный момент что мне известно в этой области. Статья или точнее пост, выйдет крайне сухим и лапидарным.
Статья очень обзорная, даже поверхностная и в ней я не буду углубляться в детали реализации, так как основной целью является сбор и публикация в одном месте тех сведений которые остаются малоизвестными широкой общественности, что бы можно было проводить работу вокруг уже стабильного текста. Малоизвестность их, связана и с недоступностью патентных баз, с тем что некоторые исследования либо недавние, либо только относительно недавно попали в открытый доступ и пылились в архивах.
Часть положений не имеет ссылок на литературу, в силу не полной разработанности темы. И еще потому, что это довольно общеизвестные факты, которые легко найти. А так же потому, что упор сделан на то что неизвестно широким массам общественности.
Широко распространено мнение, что стековые процессоры являются тупиковой ветвью развития, я считаю что это не так. Многие люди полагают, что в стековом процессоре нельзя реализовать те же решения, которые в регистровых процессорах являются основными причинами повышения производительности. Поэтому на сегодняшний момент, стековые, форт -процессоры, в основном используются во встраиваемых системах. Это обусловлено не только их принципиальной ограниченностью, но и основным полем деятельности их разработчиков. Я полагаю, что стековые процессоры могут быть не только процессорами реального времени, но и процессорами общего назначения, пригодными для десктопного и серверного использования.
Для того что бы построить собственный стековый процессор на сегодня достаточно отладочной платы с fpga на борту. Стековый софт-процессор обычно имеет почти в два раза меньший размер аналогичного по разрядности регистрового. Более меньший размер процессорного ядра положительно скажется на цене процессора при его изготовлении в виде сбис.
Способы и блоки для повышения производительности стековых процессоров.
Однопоточные:
Специфические для стековых процессоров.
Устранение излишних взаимообменов и копирований.
Введение регистров промежуточных значений(«кэширующих» регистров).
Предсказатель адресов возврата (return address predictor).
Многостековость.
Опционально - Совершенная ПОЛИЗ Общие для регистровых и стековых процессоров:
Кэш (не сильно ускорит сам процессор, зато ускорит выполнение программы которая полностью в кэше).
конвейер (двухстадийный fetch+decode-read+exec+write+mem, зато как я полагаю гораздо более предсказуемый).
Алгоритм Томасуло так же реализуем на стековой машине, и решает проблему ее постоянного обращения в память. (спекулятивное исполнение). Параллелизм:
Многопоточность
-
Параллелизм
Библиография по пунктам:
Стековые машины с изменяемой адресностью команд. Н.П. Брусенцов
Стековые машины с изменяемой адресностью команд. Н.П. Брусенцов
Dual-Stack Return Address Predictor Caixia Sun, Minxuan Zhang.
По материалам сети интернет.
Стековые машины с изменяемой адресностью команд. Н.П. Брусенцов
По материалам сети интернет.
По материалам сети интернет.
BOOST: Berkeley’s Out-of-Order Stack Thingy. Steve Sinha, Satrajit Chatterjee and Kaushik Ravindran
П. Н. Советов, И. Е. Тарасов Разработка многопоточного софт процессора со стековой архитектурой на основе совместной оптимизации программной модели и системной архитектуры.
авт.свид. № 556440 1976 г. В.М. Яковлев Устройство для управления параллельным выполнением команд в электронной вычислительной машине; авт.свид. № 2316853/24 Ю. Х. Сахин Устройство для управления параллельным выполнением команд в стековой электронной вычислительной машине.
Я полагаю, что отставание стековой машины по быстродействию относительно регистровой машины может быть и будет скомпенсировано, в известной степени, чрезвычайно компактным кодом стековой машины (меньше работы), а так же предположительно получить превосходство по быстродействию над регистровыми машинами за счет ПО написанного на конкатенативных, стековых языках программирования. То есть на языках типа Forth. Именно этот момент следует рассматривать, как некий способ повышения быстродействия стекового процессора.
Как мы видим в стековом процессоре можно использовать блоки которые повышают производительность, и которые сегодня используются в регистровых процессорах: кэши, конвееры, спекулятивное исполнение, существует свой аналог предсказателя переходов (предсказатель адресов возврата (return address predictor)), многопоточность, параллельная обработка, многоядерность, кластеры из ядер, и многопроцессорность, есть свои собственные способы увеличения производительности процессоров, недоступные регистровым машинам: многостековость, и предсказание адресов возвратов в стеке.
Таким образом стековые процессоры по прежнему остаются интересной, альтернативной линии развития процессорных архитектур.
В данном случае, стековые процессоры являются целью. Поэтому выбор регистровых архитектур не рассматривается. Там уже есть risc-v.
Комментарии (38)
byman
16.02.2022 14:15В прошлом веке я много времени уделил стековой архитектуре. Эта архитектура просто превосходна когда у вас нет нормальной технологии. Даже имея 2 микрона можно было получить несколько миллионов операций в секунду. Но лично мне очень не нравились эти DUP OVER SWAP ROT ADD DROP. Когда в обычной регистровой архитектуре можно было просто написать r0 = r1+r2 :) Но еще есть энтузиасты этого дела и это хорошо.
Gennadij_Kalin2020 Автор
16.02.2022 14:19ну, что делать, правило рычага: выигрываешь в расстоянии, проигрываешь в силе, и наоборот.
Благодаря алгоритму дейстры можно в известной степени отойти от обратной польской записи, к инфиксной. Где то в старой литературе даже приводились исходные тексты слов, которые это как то реализовывали.Везде есть свои особенности, с чем то нужно просто смириться.
forthuser
16.02.2022 14:44RPL язык калькуляторов… HP49|HP50 немного подругому выстраивает свой синтаксис и работу со «стеком» представленным в четырёх регистрах.
byman
16.02.2022 15:22Вот по этой ссылке https://forum.ixbt.com/topic.cgi?id=64:4404-10 где-то в середине страницы можно посмотреть как "смирялся" я с этой архитектурой :) Там есть пример ассемблерного кода, генерируемого С-компилятором.
Gennadij_Kalin2020 Автор
16.02.2022 15:54Я читал о дофине, что у него была очень высокая производительность, что он аналогичный интел обгонял в 50 раз. Если вы с дофином работали моженте подробнее о этом процессоре рассказать? У него же не было защиты памяти? Привелигированного режима?
byman
16.02.2022 16:22Исходный Дофин-1610 был аналогом https://en.wikichip.org/wiki/novix/nc4016 . А это несколько регистров (вершины стеков) плюс внешние стеки. Никаких защит памяти или режимов. Про 50 раз это скорее всего если исполнять Форт на непригодной машине :) А вот если Си, то скорее всего в 50 раз в обратную сторону :)
Gennadij_Kalin2020 Автор
16.02.2022 16:28+1я встречал мнение, что в современных процессорах предсказатель переходов забивается шитым кодом, а если форт процессор аппаратно поддерживает шитый код, то форт на таком процессоре будет работать ощутимо быстрее.
Тогда, скорей всего действительно, быстродействие дофина и интела сравнивалось на форт программах.
Я встречал утверждения, что если мол си не компилировать напрямую, в исходный код процессора, а сначала программу на си оттранслировать в форт, и уж затем эту программу использовать, то будет даже ускорение работы программы.forthuser
17.02.2022 07:06Есть сомнения, но интересно, а может это как то связано с тем фактом, что, к примеру, «потоковая» макрооптимизация цепочек команд реализованная в коде Форт системы SPF4 показывает приличные результаты по ускорению изначального шитого кода при преобразовании шитого подпрограммного Форт кода в регистровые пересылки x86.
P.S. Вот при убирании, конечно, в модели построения и выполнения шитого кода по классике на вычислении рекурсивных алгоритмов как примера чисел Фибоначи «Форт» код обходил Си оптимизаторы.
(где то этот тред был на ЛОР в обсуждениях от Balancer)
forthuser
16.02.2022 22:19А, у меня где то остался и файл PDF с ТО (описaнием) К1881ВЕ 2T (вроде) из где то 2004г. высланного по запросу от разработчиков этого кристалла. При расмотрении архитектуры кристала написал им пару замечаний.
Жалко, что дальше этого. применениe этой микросхемы не произошло как и TF-16 (K1894)
P.S. У Вас было и местное Хабр это сообщение к статье по Си для для этого «постсоветского» кристаллаGennadij_Kalin2020 Автор
16.02.2022 22:39получается, что как не парадоксально, в некоторых случаях у стекового процессора больше мегагерц, чем у аналогичного по техпроцессу регистрового?
forthuser
17.02.2022 06:49Вероятно, но прямое сравнение не так просто с учётом получаемой «суммарной» скорости выполнения стекового кода.
P.S. Почему то Atmel не стала развивать линейку своих 4-х битных форт контроллеров Marc4 из своего портфеля в угоду AVR, а если учесть, что и 8051 уже давно ускорили до однотактного выполнения команд на высокой частоте, то становится ещё интересней понимание этого вопроса.
byman
17.02.2022 09:51В моей практике получилось так , что ни один CISC процессор, который пытались переделать в те годы просто не поместился на кристалле или не заработал. А вот эта архитектура была реализована в несколько месяцев, без всяких HDL и синтезов, и заработала с первого раза. Это было то, что соответствовало уровню технологии. Соответствовал ли этот процессор требованиям по производительности для решения чьих-то задач, это уже совсем другой вопрос.
forthuser
17.02.2022 10:12Вроде даже этот/эти стековые процессоры были в поддержке и со стороны Интеграла (делающейся в сопряжённой организации) в IDE под названием (вроде) «Winter» (когда то скачивал демо версию для ПК этой IDE и дальнейшую её судьбу не знаю)
Gennadij_Kalin2020 Автор
17.02.2022 11:15После всего этого встает вопрос, а зачем тогда нужны были регистровые процессоры, если они при одинаковом техпроцессе были менее мощными и дорогими?
И самое главное, если их даже сделать было элементарно тяжело, то зачем они тогда были нужны? Возможно в те времена следовало бы сделать ставку на стековые процессоры и конкатенативные языки?
byman
17.02.2022 12:00+1В те времена было много инженеров и ставку можно было делать на всё ;) У меня был интересный случай. Переделывали 68НС11. Появилась возможность поставить его в смарт-карту. Но не влезли в размер. Тогда удалили микрокод со сложной оригинальной системой команд и вместо него к тракту обработки данных добавили простую систему команд, имитирующую 8-разрядный стековый процессор (а-ля 1016). Влезли в размер и получили изделие.
eandr_67
16.02.2022 15:25+3Простейший способ инфиксной записи выражений в Forth есть, например, в: Баранов, Ноздрунов «Язык Forth и его реализации». Да и в целом полезная книга.
forthuser
16.02.2022 20:39А, где можно ознакомиться с книгой Н.П. Брусенцова из поста?
Вот что выдаёт поисковик Яндекса по картинкам на запрос.
Стековые+машины+с+изменяемой+адресностью+команд.+Н.П.+БрусенцовGennadij_Kalin2020 Автор
16.02.2022 20:41это не книга, а статья.
forthuser
16.02.2022 21:00Спасибо.
@ «О сколько нам открытий чудных. Готовят просвещенья дух ...»
Статья из книги «Современный компьютер», Москва, «Мир», 1986:
Лоуренс Г. Теслер «ЯЗЫКИ ПРОГРАММИРОВАНИЯ»одна и та же задача, запрограммированная на шести языках: Бейсик, Паскаль, Кобол, Форт, АПЛ и Лисп. Выбор этих языков отчасти обусловлен их…
Источник: с новостной страницы сайта с почившим былым содержанием и не восстановленным www.forth.org.ru
ertaquo
Извините, а где статья? Выглядит, как простое перечисление способов, без малейшего объяснения, что эти способы делают и как реализуются.
Gennadij_Kalin2020 Автор
Так и есть. В статье я указал, о сухости и лапидарности. Обычно считается что многие способы повышения производительности нельзя использовать в стековых процессорах, поэтому простое перечисление способов со ссылкой на литературу, имеет определенную ценность. Особенно если до того момента в русскоязычном сегменте некоторые вещи из этих, не обсуждались. Перечисление этих способов, это и есть цель данной статьи. Или поста.
amartology
Gennadij_Kalin2020 Автор
Не согласен с вами, даже этого не сумели нашкрести, особенно в тот период, когда эта тема была на слуху, лет 15 назад.
Я оговорил ограниченность задачи. Или вы хотели, что бы я выкладывал уже готовый код спекулятивного исполнения для стекового процессора на verilog?
Мои утверждения, обоснованны определенными статьями или авторскими свидетельствами (за исключением того что и так обсуждалось на русскоязычных форумах).
Описания содержатся в статьях.
amartology
Вы можете быть хоть Джоном Хеннеси и Дэвидом Паттерсоном в одном лице, но Хабр — не место для оглавления и библиографии без собственно текста статьи.
Я хотел бы, чтобы вы описали методы повышения быстродействия сектовых процессоров.Ничего этого нет в тексте, в комментариях к которому мы общаемся.
В других статьях, да. Но не в этой. И в этом, собственно, и есть проблема.
Gennadij_Kalin2020 Автор
Что и было заявленно целью. Я не ставил нигде задачи пересказать содержимое этих статей.
Да не вопрос: применение кэшей, конвейеров, спекулятивного исполнения, предсказателей адресов стека, многопоточностью. Устранением излиших взаимообменов и копирований, а так же постоянных обращений к памяти. Это все что можно реализовать в одном ядре.
amartology
Описать, а не поименовать.
Gennadij_Kalin2020 Автор
Поименовать это вроде как бы дать названия, тому чему нет имени. А тут как миниму перечислено, то что ранее считалось невозможным.
Вы действующий разработчик сбис, у вас 17 публикаций на хабре. Напишите так как считаете нужным по этой тематике. Мы с удовольствием вас прочтем.
amartology
Как вы верно заметили, у меня 17 публикаций, с довольно неплохим средним рейтингом — ровно потому, что я писал так, как считаю нужным. И я пытаюсь до вас донести, что если вам важно, чтобы аудитория Хабра вас услышала и заинтересовалась, то писать нужно вообще по-другому.
Gennadij_Kalin2020 Автор
Способы повышения производительности ядра процессора: Конвейеризация. Суперскалярность. Параллельная обработка данных. Технология Hyper-Threading.
https://studfile.net/preview/6407067/page:2/
Первый попавшийся файл, который явно используется на лекциях. Взят на студенческом файлообменнике. Им студенты пользуются. Те студенты, какие есть. Может им до вас и далеко, но тем не менее.
Ну, я надеюсь вы все таки не вся аудитория хабра. Я даже удивлен тому что вы захотели, внезапно вступить со мной в диалог. Если мне не изменяет память ранее вы не хотели вступать со мной в диалог.
То есть ваш рейтинг хорош, только потому, что вы пишете так как считаете нужным. А мне вы запрещаете писать, так как я считаю нужным. Как я понял из ваших слов, вы ставите мне взаимоисключающие условия.
nckma
Главная проблема Форт процессоров - не сама архитектура, а отсутствие готовых библиотек (словарей в терминологии Форта).
Попробуйте к примеру найти готовые Форт исходники для шифрования: md5, RSA, SHA256/512, RC4/RC5/RC6, Blowfish, GOST. Попробуйте найти что-то SSL/TLS. Да просто найдите реализацию сетевого стека TCP/UDP/DHCP.
Что-то желающих нет написать это и выдать людям для свободного пользования. Возникает проблема курицы-яйца. Что важнее? Никто не хочет заниматься особенной архитектурой если там нет важных библиотек. А важных библиотек нет потому, что никто не хочет заниматься особенной архитектурой.
PS: и да, я запускал Форт процессор в FPGA, знаю что это такое..
https://marsohod.org/projects/proekt-m02mini/410-forth-j1
Gennadij_Kalin2020 Автор
То же верно. Мне люди о этом говорили. И отсутствии современных средств разработки и так далее.
Но тут еще все зависит от предназначения процессора. Конечно авторам или автору новой стековой архитектуры придется выше указанные вами проблемы решать. Тут спору нет.
forthuser
А в чём принципиальне сложности реализовать в рамках Форт языка тот или иной алгоритм? (сложно начать «мыслить» на Форт?)
К примеру на сайте rosettacode.org есть и решения представленных задач на Форт.
MD5 если не изменяет память даже в статье на Форт был и другие «хэш» алгоритмы (вероятно несложно сделать и другие реализации нужных алгоритмов непосредственно на Форт) к тому же на Форт был реализован мультисервер eserv (с исходниками). В крайнем случае кросс компиляция с Си тоже возможна вполне эффективно сделана в стековую архитектуру.
P.S. Целый Биос (OpenBiios) для ПК на Forth сделали и открыли исходники.
nncron планировщик до сих пор находит своих пользователей.
К примеру на Форт есть и реализации разных языков программирования Алгол направленности,
а, то, что Форт реализуют в рамках разных языков программирования, думаю, что Вам не надо рассказвать о таком известном факте. ????
Тут всё немного проще, нет Форт железа, то и нет особой потребности в его использовании как «ассемблерa». и поэтому его зачастую можно встретить в рамках использования с микроконтроллерами.
В рамках Форт реалий много информации, но она остаётся вне понимания для её использования, а сама тематика использования Форт полнится вот такими слухами от людей (и к бабке ходить не надо :)
Gennadij_Kalin2020 Автор
я все таки не эмбедед программист, у меня все таки другая причина интереса. Я не могу всего знать.
nckma
Даже для интереса посмотрел как там на rosettacode.org реализовано sha256 на Форте.
Ну вот так:
forthuser
Да, Форт при необходимости может использовать интеграцию с какими то готовыми библиотеками в системе.
Алгоритм построения цифрового дайджеста MD5.pdf (в рамках Forth)
Gennadij_Kalin2020 Автор
Речь шла конечно же о диалоге в комментариях. Нашу с вами переписку в личке я нашел. Уж извините забыл.