Comments 44
Извините, а где статья? Выглядит, как простое перечисление способов, без малейшего объяснения, что эти способы делают и как реализуются.
Так и есть. В статье я указал, о сухости и лапидарности. Обычно считается что многие способы повышения производительности нельзя использовать в стековых процессорах, поэтому простое перечисление способов со ссылкой на литературу, имеет определенную ценность. Особенно если до того момента в русскоязычном сегменте некоторые вещи из этих, не обсуждались. Перечисление этих способов, это и есть цель данной статьи. Или поста.
Перечисление этих способов, это и есть цель данной статьи.Перечисление без описания — это не статья или пост, а свинство по отношению к читателям.
Не согласен с вами, даже этого не сумели нашкрести, особенно в тот период, когда эта тема была на слуху, лет 15 назад.
Я оговорил ограниченность задачи. Или вы хотели, что бы я выкладывал уже готовый код спекулятивного исполнения для стекового процессора на verilog?
Мои утверждения, обоснованны определенными статьями или авторскими свидетельствами (за исключением того что и так обсуждалось на русскоязычных форумах).
Описания содержатся в статьях.
Или вы хотели, что бы я выкладывал уже готовый код спекулятивного исполнения для стекового процессора на verilog?Я хотел бы, чтобы вы описали методы повышения быстродействия сектовых процессоров.
Мои утверждения, обоснованны определенными статьями или авторскими свидетельствами (за исключением того что и так обсуждалось на русскоязычных форумах).Ничего этого нет в тексте, в комментариях к которому мы общаемся.
Описания содержатся в статьях.В других статьях, да. Но не в этой. И в этом, собственно, и есть проблема.
В других статьях, да. Но не в этой. И в этом, собственно, и есть проблема.
Что и было заявленно целью. Я не ставил нигде задачи пересказать содержимое этих статей.
Я хотел бы, чтобы вы описали методы повышения быстродействия сектовых процессоров.
Да не вопрос: применение кэшей, конвейеров, спекулятивного исполнения, предсказателей адресов стека, многопоточностью. Устранением излиших взаимообменов и копирований, а так же постоянных обращений к памяти. Это все что можно реализовать в одном ядре.
Что и было заявленно целью.Так о том и речь, что это негодная цель для статьи на Хабре.
Да не вопросОписать, а не поименовать.
Описать, а не поименовать.
Поименовать это вроде как бы дать названия, тому чему нет имени. А тут как миниму перечислено, то что ранее считалось невозможным.
Так о том и речь, что это негодная цель для статьи на Хабре.
Вы действующий разработчик сбис, у вас 17 публикаций на хабре. Напишите так как считаете нужным по этой тематике. Мы с удовольствием вас прочтем.
А тут как миниму перечислено, то что ранее считалось невозможным.Окей, исправляюсь. «Описать, а не перечислить». Так вам больше понятно?
у вас 17 публикаций на хабре. Напишите так как считаете нужнымКак вы верно заметили, у меня 17 публикаций, с довольно неплохим средним рейтингом — ровно потому, что я писал так, как считаю нужным. И я пытаюсь до вас донести, что если вам важно, чтобы аудитория Хабра вас услышала и заинтересовалась, то писать нужно вообще по-другому.
Способы повышения производительности ядра процессора: Конвейеризация. Суперскалярность. Параллельная обработка данных. Технология Hyper-Threading.
https://studfile.net/preview/6407067/page:2/
Первый попавшийся файл, который явно используется на лекциях. Взят на студенческом файлообменнике. Им студенты пользуются. Те студенты, какие есть. Может им до вас и далеко, но тем не менее.
Как вы верно заметили, у меня 17 публикаций, с довольно неплохим средним рейтингом — ровно потому, что я писал так, как считаю нужным. И я пытаюсь до вас донести, что если вам важно, чтобы аудитория Хабра вас услышала и заинтересовалась, то писать нужно вообще по-другому.
Ну, я надеюсь вы все таки не вся аудитория хабра. Я даже удивлен тому что вы захотели, внезапно вступить со мной в диалог. Если мне не изменяет память ранее вы не хотели вступать со мной в диалог.
Как вы верно заметили, у меня 17 публикаций, с довольно неплохим средним рейтингом — ровно потому, что я писал так, как считаю нужным.
То есть ваш рейтинг хорош, только потому, что вы пишете так как считаете нужным. А мне вы запрещаете писать, так как я считаю нужным. Как я понял из ваших слов, вы ставите мне взаимоисключающие условия.
Главная проблема Форт процессоров - не сама архитектура, а отсутствие готовых библиотек (словарей в терминологии Форта).
Попробуйте к примеру найти готовые Форт исходники для шифрования: md5, RSA, SHA256/512, RC4/RC5/RC6, Blowfish, GOST. Попробуйте найти что-то SSL/TLS. Да просто найдите реализацию сетевого стека TCP/UDP/DHCP.
Что-то желающих нет написать это и выдать людям для свободного пользования. Возникает проблема курицы-яйца. Что важнее? Никто не хочет заниматься особенной архитектурой если там нет важных библиотек. А важных библиотек нет потому, что никто не хочет заниматься особенной архитектурой.
PS: и да, я запускал Форт процессор в FPGA, знаю что это такое..
То же верно. Мне люди о этом говорили. И отсутствии современных средств разработки и так далее.
Но тут еще все зависит от предназначения процессора. Конечно авторам или автору новой стековой архитектуры придется выше указанные вами проблемы решать. Тут спору нет.
К примеру на сайте rosettacode.org есть и решения представленных задач на Форт.
MD5 если не изменяет память даже в статье на Форт был и другие «хэш» алгоритмы (вероятно несложно сделать и другие реализации нужных алгоритмов непосредственно на Форт) к тому же на Форт был реализован мультисервер eserv (с исходниками). В крайнем случае кросс компиляция с Си тоже возможна вполне эффективно сделана в стековую архитектуру.
P.S. Целый Биос (OpenBiios) для ПК на Forth сделали и открыли исходники.
nncron планировщик до сих пор находит своих пользователей.
К примеру на Форт есть и реализации разных языков программирования Алгол направленности,
а, то, что Форт реализуют в рамках разных языков программирования, думаю, что Вам не надо рассказвать о таком известном факте. ?
Тут всё немного проще, нет Форт железа, то и нет особой потребности в его использовании как «ассемблерa». и поэтому его зачастую можно встретить в рамках использования с микроконтроллерами.
В рамках Форт реалий много информации, но она остаётся вне понимания для её использования, а сама тематика использования Форт полнится вот такими слухами от людей (и к бабке ходить не надо :)
я все таки не эмбедед программист, у меня все таки другая причина интереса. Я не могу всего знать.
Даже для интереса посмотрел как там на rosettacode.org реализовано sha256 на Форте.
Ну вот так:
c-library crypto
s" ssl" add-libs" crypto" add-lib \c #include <openssl/sha.h>c-function sha256 SHA256 a n a -- a end-c-library : 2h. ( n1 -- ) base @ swap hex s>d <# # # #> type base ! ;
: .digest ( a -- ) 32 bounds do i c@ 2h. loop space ; s" Rosetta code" 0 sha256 .digest crbye Алгоритм построения цифрового дайджеста MD5.pdf (в рамках Forth)
Ну, я надеюсь вы все таки не вся аудитория хабра. Я даже удивлен тому что вы захотели, внезапно вступить со мной в диалог. Если мне не изменяет память ранее вы не хотели вступать со мной в диалог.
Речь шла конечно же о диалоге в комментариях. Нашу с вами переписку в личке я нашел. Уж извините забыл.
В прошлом веке я много времени уделил стековой архитектуре. Эта архитектура просто превосходна когда у вас нет нормальной технологии. Даже имея 2 микрона можно было получить несколько миллионов операций в секунду. Но лично мне очень не нравились эти DUP OVER SWAP ROT ADD DROP. Когда в обычной регистровой архитектуре можно было просто написать r0 = r1+r2 :) Но еще есть энтузиасты этого дела и это хорошо.
ну, что делать, правило рычага: выигрываешь в расстоянии, проигрываешь в силе, и наоборот.
Благодаря алгоритму дейстры можно в известной степени отойти от обратной польской записи, к инфиксной. Где то в старой литературе даже приводились исходные тексты слов, которые это как то реализовывали.
Везде есть свои особенности, с чем то нужно просто смириться.
Вот по этой ссылке https://forum.ixbt.com/topic.cgi?id=64:4404-10 где-то в середине страницы можно посмотреть как "смирялся" я с этой архитектурой :) Там есть пример ассемблерного кода, генерируемого С-компилятором.
Я читал о дофине, что у него была очень высокая производительность, что он аналогичный интел обгонял в 50 раз. Если вы с дофином работали моженте подробнее о этом процессоре рассказать? У него же не было защиты памяти? Привелигированного режима?
Исходный Дофин-1610 был аналогом https://en.wikichip.org/wiki/novix/nc4016 . А это несколько регистров (вершины стеков) плюс внешние стеки. Никаких защит памяти или режимов. Про 50 раз это скорее всего если исполнять Форт на непригодной машине :) А вот если Си, то скорее всего в 50 раз в обратную сторону :)
я встречал мнение, что в современных процессорах предсказатель переходов забивается шитым кодом, а если форт процессор аппаратно поддерживает шитый код, то форт на таком процессоре будет работать ощутимо быстрее.
Тогда, скорей всего действительно, быстродействие дофина и интела сравнивалось на форт программах.
Я встречал утверждения, что если мол си не компилировать напрямую, в исходный код процессора, а сначала программу на си оттранслировать в форт, и уж затем эту программу использовать, то будет даже ускорение работы программы.
P.S. Вот при убирании, конечно, в модели построения и выполнения шитого кода по классике на вычислении рекурсивных алгоритмов как примера чисел Фибоначи «Форт» код обходил Си оптимизаторы.
(где то этот тред был на ЛОР в обсуждениях от Balancer)
Жалко, что дальше этого. применениe этой микросхемы не произошло как и TF-16 (K1894)
P.S. У Вас было и местное Хабр это сообщение к статье по Си для для этого «постсоветского» кристалла
получается, что как не парадоксально, в некоторых случаях у стекового процессора больше мегагерц, чем у аналогичного по техпроцессу регистрового?
P.S. Почему то Atmel не стала развивать линейку своих 4-х битных форт контроллеров Marc4 из своего портфеля в угоду AVR, а если учесть, что и 8051 уже давно ускорили до однотактного выполнения команд на высокой частоте, то становится ещё интересней понимание этого вопроса.
В моей практике получилось так , что ни один CISC процессор, который пытались переделать в те годы просто не поместился на кристалле или не заработал. А вот эта архитектура была реализована в несколько месяцев, без всяких HDL и синтезов, и заработала с первого раза. Это было то, что соответствовало уровню технологии. Соответствовал ли этот процессор требованиям по производительности для решения чьих-то задач, это уже совсем другой вопрос.
После всего этого встает вопрос, а зачем тогда нужны были регистровые процессоры, если они при одинаковом техпроцессе были менее мощными и дорогими?
И самое главное, если их даже сделать было элементарно тяжело, то зачем они тогда были нужны? Возможно в те времена следовало бы сделать ставку на стековые процессоры и конкатенативные языки?
В те времена было много инженеров и ставку можно было делать на всё ;) У меня был интересный случай. Переделывали 68НС11. Появилась возможность поставить его в смарт-карту. Но не влезли в размер. Тогда удалили микрокод со сложной оригинальной системой команд и вместо него к тракту обработки данных добавили простую систему команд, имитирующую 8-разрядный стековый процессор (а-ля 1016). Влезли в размер и получили изделие.
В прошлом веке я много времени уделил стековой архитектуре. Эта архитектура просто превосходна когда у вас нет нормальной технологии. Даже имея 2 микрона можно было получить несколько миллионов операций в секунду.
сегодня, ваши слова , с учетом нынешних событий, актуальны как никогда!
Вот что выдаёт поисковик Яндекса по картинкам на запрос.
Стековые+машины+с+изменяемой+адресностью+команд.+Н.П.+Брусенцов
это не книга, а статья.
@ «О сколько нам открытий чудных. Готовят просвещенья дух ...»
Статья из книги «Современный компьютер», Москва, «Мир», 1986:
Лоуренс Г. Теслер «ЯЗЫКИ ПРОГРАММИРОВАНИЯ»
одна и та же задача, запрограммированная на шести языках: Бейсик, Паскаль, Кобол, Форт, АПЛ и Лисп. Выбор этих языков отчасти обусловлен их…
Источник: с новостной страницы сайта с почившим былым содержанием и не восстановленным www.forth.org.ru
вот когда под стековый процессор будет компилятор С/C++ тогда можно говорить о возможности проверки эффективности
те сделать на FPGA-макетке процессор + память и запустить какой-нибудь легкий дистрибут *nix-а
и вот тогда - можно о чем-то говорить. а пока - глухая теория без практики
Я против С/С++ . И даже против ставки на linux.
Да, вы правы это пока что глухая теория без практики. Практику я буду публиковать по мере готовности.
А так да, вы правы.
возможно народ не понял, постараюсь объяснить. Я сам сижу на линуксе вот уже лет десять, и знакомых уговариваю на него переехать, но что касается моего гипотетического стекового процессора, то я лично, не хочу на него переносить компилятор си, и запускать линукс. Они уже тяжеловаты, и для меня интереснее уже что то другое. Если и портировать какой нибудь юникс, то скорее всего netbsd, но не gnu/linux. Опять же тяжеловесность, и кроме того, со стековыми процессорами лучше всего сочетаются стековые языки.
Как пишет @byman:
Исходный Дофин-1610 был аналогом https://en.wikichip.org/wiki/novix/nc4016 . А это несколько регистров (вершины стеков) плюс внешние стеки. Никаких защит памяти или режимов. Про 50 раз это скорее всего если исполнять Форт на непригодной машине :) А вот если Си, то скорее всего в 50 раз в обратную сторону :)
Поэтому, я не вижу смысла для моего проекта, переносить компилятор си.
Хотя если мой проект состоится, и будет доступен общественности, то любой желающий сможет сделать, что захочет. У меня просто на это нет сил, и если честно желания. Тем более, как я понимаю по производительности я серьезно потеряю.
Конечно байт код в этих вариантах — это форма хранения формы исполнения программы с соответствующих языков и при исполнении происходит их нативное пpофилирование и исполнение уже в рамках целевого процессора девайса, но если будет для них аппаратный ускоритель, как к примеру ранее существующие варианты, аппаратного ускорения Java byte кода, то наличие регистровых процессоров не будет играть значимую роль в аппаратном обеспечении устройств.
P.S. Сам, в качестве эксперимента, делал бэкэнд к LCC -> SPF4 (Форт) на базисе c2forth110.zip(в конце страницы) и ничего всё в первом приближении исполнения тестовых программ заработало.
В TpForth (2001г) есть возможность трансляции JS в Форт код (или исполнения с js.dll), конечно от такого же решения на Форт оно достаточно отличается по результирующему коду, но для демонстрации возможности такого варианта использования применимо.
Спасибо ! Утаскиваю в закладки. Сам сейчас делаю довольно продвинутый стековый процессор для одного проекта. Если работодатель разрешит, опубликую здесь на хабре.
Стековые процессоры: способы повышения производительности и блоки, которые для этого используются. Библиография