Pull to refresh

Comments 49

К пункту DEC PDP-11 можно было бы добавить MSP430.

P.S. А, так в качестве ассемблера пропущен вариант MISC какой нибудь архитектуры (GA144. J1, RX2010 ...) Forth Chips
(хотя в прочих и есть упоминание близкой архитектуры — стекового транспьютера — T100 от Inmos?)

Проблема с PDP-11: я знаю, что я оскорбляю святыню, но эта архитектура плохо конвейеризуется и хотя на ней приятно писать, но для обучения молодежи, работающей в 21 веке, это не подходит. Потому что когда они будут переходит к следующей главе про реализацию процессора в хардвере, то им прийдется забывать выученный PDP-11, выучивать RISC-V и продолжать так.

Вообще PDP-11 была реализована с помощью микрокода - метода для составления последовательностей контрольных сигналов, популярный в 1970-х годах. Микропрограммирование (не путать с программированием на ассемблере) - это удобный способ реализации сложных инструкций в последовательном процессоре без конвейера, но вся схема рассыпается когда мы вводим конвейер, так как контрольные сигналы становятся зависимыми не только от одной инструкции, но и от ее соседей. Поэтому процессоры с 1980-х в основном hard-wired, и микропрограммирование осталось только в специальных местах дизайна для редких инструкций.

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

Да, стэковые процессоры проиграли ещё и по тому, что тащить стэковую память в процессор оказалось не совсем экономически выгодно в сравнении с регистровыми CISC, RISC процессорами (да ещё и в количестве двух стэков)
Перевод книги Philip J. Koopman, Jr. Stack Computers: the new wave

Думаю, что при подобающем развитии MISC архитектуры вопросы её производительности в сравнении с RISC, MISC могли быть сняты.

А, некоторые стэковые процессоры переделывали и в Java процессоры.

P.S. А, так даже у Atmel были беспроводные стэковые 4-х битные контроллеры Marc4 (бывшие разработкой от Temic), но не продвигаемые на рынок ввиду наличия в портфеле AVR.
В России тоже были сделаны стэковые «контроллеры» К1894 (TF-16) уже не так давно.
В Белоруссии K1881BE1T ( Минск, «Интеграл» продолжение линейки Дофин процессоров)
Кстати, одной из популярных задач программирования на ассемблере выступает задача реализации Forth (Форт) в рамках выбранного процессорного железа. :)
На RISC-V её уже в разных вариантах тоже сделали на Github
risc-v forth

Intel Core в основном 2 конвейера на ядро + микрокод, или я чего-то не понимаю?

У Интела динамический out-of-order конвейер с большим количество параллельно работающих functional units. И там важно не путать RISC-like микроинструкции в которые front-end процессора перекодирует CISC инструкции - с микрокодом в стиле 1970-х (где последовательность контрольных сигналов записанная в памяти) - это разные вещи. Я не эксперт по организации интеловских ядер, но вы можете посмотреть идею организации в Modern Processor Design: Fundamentals of Superscalar Processors 1st Edition by John Paul Shen, Mikko H. Lipasti.

Так или иначе, использовать интел для обучения основам микроархитектуры (устройству конвейера) CPU - это плохая идея, даже кафедра Интела в МФТИ учила на основе архитектуры (системы команд) MIPS, а сейчас учит на основе архитектуры (системы команд) RISC-V

Да вроде как в гцц поддержка классических архитектур, таких как pdp-11 и 68k никуда не девалась особо и была всегда. Другое дело, что код он выдавал весьма паршивого качества. И что-то я очень сомневаюсь, что тут именно прорыв в генерации оптимального кода произошёл.

пдп-11 конечно и среди своих современников выглядит довольно сложным в реализации. Но зато, он может послужить хорошим примером того, как его команды можно перекодировать в risc-like и дальше выполнять их в обычном risc-ядре :)

Я сторонник того, что знания, которые даёт образовательная система, должны быть хотя бы минимально применимыми. И RISC-V, и ARM - нормальные варианты. Это современные ассемблеры с хорошими тулчейнами и минимальным разбродом-шатанием (привет, Intel и AT&T) - и именно эти архитектуры в ходу в микроконтроллерах, а как раз там ассемблер сейчас чаще всего оказывается нужен.

Восьмибитные "учебные" архитектуры, в которых всё красиво, но которые при этом максимально далеки как от реального железа, так и от практических применений, не нужны.

Хуже того. 8080, Z80 и 6502 кажутся "красивыми учебными" только людям, которые проспали и относительное повышение скорости логики относительно памяти (что сделало устаревшими аккумуляторные архитектуры), и risc-революцию 1980-х, и распространение semiconductor IP-based систем на кристалле в последние 25 лет, и введение в учебный процесс учебников по микроархитектуре конвейерных процессоров (Хеннесси-Паттерсон).

А, насколько в плане решения задач на «аккумуляторных» контроллерах PIC, STM8, MSP430, 8051 принципиальна их не RISC направленность, если частоты их работы и энергоэффективность достаточны для решения широкого круга задач?

P.S. Вроде как важнее, что на рынке почти, если не полностью нет многоядерных контроллеров (даже в дизайне конкуренции к примеру с GA144)
Есть ли этому факту нормальное объяснение?

Из того что 8051 может использоваться до 22 века, не следует, что его стоит использовать в качестве примера для будущих микроархитекторов высокопроизводительных систем на кристалле, где повсюду конвейеры и встают совсем другие проблемы, чем стояли при дизайне 8051

@YuriPanchul говорит с т.з. обучения создателей микроархитектуры процессоров и конечно верно (хотя учебная задача типа 'сделайте быстрый Z80' вполне валидна, imho), но мне почему-то не кажутся эти архитектуры такими уж ужасными с т.з. введения в программирование на ассемблере. Тут, я думаю, половина всех присутствующих в детстве имели спектрум и учились программировать под него на ассемблере.

Цель данной серии семинаров - подвести студента к проектированию конвейерного процессора. Z80 не был реализован как конвейерный процессор изначально и его архитектура для такой реализации неудобна. Двух-операндные команды (постоянные байпасы на все), использование сдвоенного регистра HL для работы с памятью, и главное - выборка команд переменной длины. Последнее сразу делает конвейер не учебным для начинающих.

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

То есть ему прийдется развидеть свой дизайн Z80, выучить RISC-V и делать конвейерный процессор на нем. Тогда почему-бы это не делать сразу и не оставить Z80 в прошлом, к которому он относится?

У MSP430 — регистровая архитектура, а не аккумуляторная.
Да, но он ближе к пониманию CISC как его идейный прародитель PDP-11,
но по сокращённому количеству системы команд и регистровому файлу можно условно отнести его к RISC.

Думаю что команде Эльбруса стоит поучиться продвижению своей продукции у Syntacore.

Тут и эмулятор, и разбор ассемблера, и преподавание.

ассемблер в 2021г

Ну такое.

Вы наверное начинающий программист. Поэтому поясню вам: без знания ассемблера в 2021 году не смогут работать следующие категории людей:

  1. Cоздатели компиляторов

  2. Писатели драйверов

  3. Писатели ядер операционных систем

  4. Писатели симуляторов процессоров на уровне инструкций (необходимо для тестирования новосоздаваемых процессоров, а также отладки компиляторов и сотфвера на еще не выпеченных на фабрике процессоров).

  5. Проектировщики процессоров

И некоторые другие категории (например создатели бинарных компиляторов), но я перечисли самые существенные. То есть рухнет вся цепочка программирования и проектирования железа вообще.

UPD: Посмотрел на ваши комменты, понял что ошибся. Тогда что вы имеете в виду: что ассемблер не нужно разбирать, или что его Эльбрус открыл только в 2021 году? Вы как-то двусмысленно выразились.

Имею в виду что в настоящее время ассемблер является очень узким инструментом решения крайне специализированных задачь. Сейчас что ОС, что компиляторы, что биосы с гипервизорами в сервисных чипах - это программы на языках высокого уровня по большей части абстрагированные от конкретного железа. Если перед разработчиком не стоит задача прямой или особой поддержки конкретного процессора/железа то ему и вникать в его архитектуру не зачем. Времена DOS давно прошли.

Узким для кого? Для всех инженерных групп, которые занимаются проектированием и верификацией процессоров и DSP, а также написанием для них компиляторов (компилятор конечно написан на Си, но как писать его кодогенератор без знания ассемблера?), в ARM, AMD, Intel, Apple, Synopsys/ARC, Cadence/Tensilica, SiFive, Esperanto, Syntacore, Marvell (архитектурная лицензия на ARM и MIPS), Broadcom (то же), Microchip Technology, Hitachi, Fujitsu, Texas Instruments - для всех этих людей ассемблер - это необходимое знание. Это минимум десятки тысяч человек, даже если мы не учитываем производителей систем. Как вы можете отлавить баг в скажем байпасе конвейера если вы не можете анализировать лог со сравнением результата модели и RTL?

Один видео урок из серии по ассемблеру, где в начале автор отвечает на вопрос где может пригодится знание ассемблера

// Язык Ассемблера #2 [FASM, Linux, x86-64] //


P.S. Интересно, а как подобные уроки могли бы быть представлены в отношении RISC-V в его использовании в Linux на базе данного процессора.
Fasm, по идее, может быть сделан и для RISC-V. (для ARM делался)

А, вообще, на Fasm 32 x86 создана операционная система KolibriOS умещающаяся с оконным GUI, сетью и демонстрационными программами (в том числе и текстовым i-net браузером) в размере дискетки 1.44 Мб! и работающая на многом парке PC x86 компьютерах (начиная с Pentium 1)

Forthress учебный диалект Форт на ассемблере Nasm
в иллюстрации к книге
Igor Zhirkov «Low-Level Programming: C, Assembly, and Program Execution on Intel x86-64 Architecture»

*** Fasm, по идее, может быть сделан и для RISC-V ***

Это совершенно не нужно. В RISC/V нет этой нелепицы сегментных регистров, которая была сделана в 1978 году в x86, поэтому для RISC/V совершенно не нужно делать специальный "flat asm", он уже flat по определению, в risc-v адресное пространство виртуальных адресов уже плоское, и есть TLB MMU для страничного управления памяти.

Не понял комментарий. :)
Разве в х86 нельзя делать ассемблерный код в плоском режиме переключив процессор в его поддержку?
И идеи реализованные в Fasm не лежат в «прибитии гвоздями» к х86.

P.S. На Fasm даже есть вариант сделанного пакета для среды HiAsm.

Зачем модифицировать ассемблер fasm, разработанный хоббистом для x86, если есть как стандартная тулчейн для RISC-V, так и учебный симулятор RARS, который по юзабилити удобнее среды fasm, если судить по его видео. Я просто не вижу чем fasm лучше.

Да, вероятно это так, лучше оставить такую возможность хоббистам.
Вероятно у них «больше» знаний, если их выбор Fasm. :)

учебный симулятор RARS

А, будет ли добавлена в этот симулятор, например, возможность общения с ядром процессора через консольный терминал ввода/вывода текстовых данных (типа VT100) в каком то варианте?
(неплохо бы было и с выходом на реальный UART/USB интерфейс компьютера)

Хорошо бы ещё, чтобы была возможность добавления к симулятору в виде плагинов на каком то языке (как вариант Lua, Phyton ...?) симуляцию какой то внешней периферии или что то по возможностям программы Proteus.

P.S. И, Fasm это быстрый консольный ассемблер не относящийся к используемой средe разработки представленной в видео.

Перевод руководства «Understanding the flat assembler», написанного разработчиком самого FASM

Fresh IDE — FASM inside (сделанная на Fasm)
image

+++ Вероятно у них «больше» знаний, если их выбор Fasm. :) ***

У кого "у них" ? Это выглядит как хобби одного человека, который в этом копается лет 20, и возможно несколько поклонников.

** А, будет ли добавлена в этот симулятор, например, возможность общения с ядром процессора через консольный терминал ввода/вывода текстовых данных (типа VT100) в каком то варианте?
(неплохо бы было и с выходом на реальный UART/USB интерфейс компьютера) ***

Что вы хотите делать в консольном терминале? Ввод-вывод из пользовательской программы? Команды отладчику?

И зачем делать оттуда вывод на реальный uart/USB? Чтобы сделать виртуальную платформу из симулятора, работающей на нем реальной программы и реальных устройств?

А нужно ли это для студенческих проектов? Студенты могут делать в симуляторы типа RARS простые упражнения, которые берут данные из памяти и складируют результаты в память. Далее студенты строят свой процессор в симуляторе типа Icarus на уровне регистровых передач на верилоге. Потом они синтезируют процессор, помещают его в FPGA плату и там он может взаимодействовать с реальными устройствами. Программировать его можно через стандартную gcc toolchain.

Если они не хотят изучать проектирование процессоров, а хотят заниматься проектированием систем с реальными периферийными устройствами, то зачем им виртуальная платформа? Они могут взять микроконтроллер на копеечной плате и использовать обычный отладчик.

Fasm быстрый? А что, gcc не быстрый? Не вижу никакого преимущества у fasm.

У кого «у них»? Это выглядит как хобби одного человека, который в этом копается лет 20, и возможно несколько поклонников.

Их явно больше по упоминанию Fasm в проектах на Github, если каких то приведённых примеров недостаточно (в том числе и ОС на Fasm в размере одной дискетки, хотя с моей точки зрения это уже немного перебор, хотя сообщество этой ОС решило что это адекватный ассемблер для её написания :)

Что вы хотите делать в консольном терминале? Ввод-вывод из пользовательской программы? Команды отладчику?

Да, хотя бы иметь возможность диалога и в таком варианте с пользователем. Хотя, если сделать возможность ввода/вывода терминала на ячейки памяти как в PDP-11 то тоже вариант.
Для проверки и запуска некоторых проектов сделанных на ассемблере Risc-V.

Fasm быстрый? А что, gcc не быстрый? Не вижу никакого преимущества у fasm.

GCC, всё же это не Ассемблер, а Fasm не классический ассемблер.
Для кроссплатформенности есть Fasmg.

*** GCC, всё же это не Ассемблер, а Fasm не классический ассемблер. **
Я имел в виду gas - GNU assembler, он используется GCC.

*** Да, хотя бы иметь возможность диалога и в таком варианте с пользователем. Хотя, если сделать возможность ввода/вывода терминал ***

В RARS есть консольный вывод с помощью инструкции ecall - системный вызов.

RISC-V и MOS 6502 (на этой архитектуре микроконтроллеры STM8) - можно наглядно и просто показать разницу CISC и RISC подходов.

Я бы не сказал, что 6502 это именно пример CISC. Скорее пример аккумуляторной архитектуры, которая потеряла смысл для средних и высокопроизводительных процессоров из-за того, что скорость логики росла в 1980-х гораздо быстрее чем задержки при обращении к памяти.

На фига школьнику разбираться, почему для доступа к элементу массива в памяти, ему нужно делать это через ... эээ ... сдвоенный регистр HL? Про то, что он не подходит для изучения организации конвейерного процессора я написал в комменте выше.

Школьнику много из возможностей и стандартных ассемблеров может быть излишне для начальной практики (Imho) даже без «заморочек» отдельно у той или иной архитектуры.

Как пример можно привести программу графичекого ассемблера АБ ( Algorithm Builder for AVR) где её автор не только применил блок-схемное отображение кода программы, но и изменил сами мнемоники команд ассемблера сделав их более унифицированными и легче запоминаемыми. Учебное пособие по языкам мк-шек
Форумная площадка пользователей данной программы Algorithm Builder for AVR, Начинаем
Разработка программы прекращена автором и варианта для ARM не появилось.

P.S. Г.Р. Алпатов: Применение PIC-контроллеров в измерительной технике
Автор от использования стандартного ассемблера от производителя переходит к иллюстрации работы с контроллером на Forth как тоже более эргономичному варианту языка программирования МК в сравнении со стандартным ассемблером.

Я совсем не против, если кто-нибудь будет учить школьников по блок-схемам, AVR, PIC16 или Forth. Forth - это прикольно, я знаю. Блок-схемы - это менее прикольно имхо, так как рисовать мышкой блок-схемы - это гораздо противнее и медленнее чем писать код, и школьником я блок-схемы не любил. Что касается PIC, то я даже внес свой вклад в PIC32 (я делал bus functional model которую использовали разработчики PIC32).

Но моя цель и цель данного мероприятия - не обучение школьников встроенному программированию микроконтроллеров. Этому уже учат масса людей. Моя цель - сделать нечто другое, чему учат меньшее количество людей.

Моя цель - взрастить будущих микроархитекторов чипов, людей которые будут проектировать конвейеры, арбитры для разделяемых памятей, всякие очереди и прочие конструкции на уровне регистровых передач, внутри CPU, GPU, NPU и сетевых чипов.

Построение собственного игрушечного процессора - это традиционное упражнение для данной специализации. Применять для этого упражнения подмножество проприетарной и не очень ортогональной архитектуры PIC16 или AVR - это не самый оптимальный путь. Это не поддерживается учебниками (Паттерсон-Хеннесси, Харрис & Харрис итд). А учить их сначала PIC16 или AVR а потом говорить: "хорошо, научились? А теперь RISC-V" - это совершенно ненужный обходной путь.

Блок-схемы — это менее прикольно имхо, так как рисовать мышкой блок-схемы — это гораздо противнее и медленнее чем писать код, и школьником я блок-схемы не любил.

:) Скажите это Параджанову — автору языка Дракон может внемлет,
но есть и сторонники Драконо-строительства программ и к тому же перенеся возможность создания блоковых элементов на клавиши клавиатуры можно облегчить их построение, но да к текстовому вводу это их не приблизит.

Дракон площадка

Вы напрасно восприняли мой коммент серьезно. Я там и смайлик поставил. )) честно говоря я и саму голосовалку воспринял не серьезно, прочтя ее пункты. )) более того, саму голосовалку то неожидал, ибо обьявлено в програмсе рискпять - значит рискпять. Ну серьезно бы я ее воспринял, если бы, к примеру, выбор был бы предложен между арм и рискпять. А тут как прочел шестидесятилетний набор молодостей разных поколений, то решил, что это своего рода предложение пообщаться, вот и добавил "свою молодость". )))

Не, я понял, я это так, для поддержания разговора :-) Я сам учил ассемблер КР580ИК80 летом в библиотеке между 8 и 9 классом вместо того чтобы учиться знакомится с девушками на пляже.

Кстати странно, что никто не кликнул на БЭСМ-6. Вроде поколение бэсмолюбов еще не ушло в Вальхаллу. Или они просто не тусуются на Хабре?

честно говоря было искушение "ткнуть" в БЭСМ-6, когда увидел и ее в списке. )))

:) да, он проще чем Z80 но не лучше.
Z80 как легендарный микропроцессор находит своих ностальгирующих пользователей и в современности, если учесть что он был прменён в ZX-Spectrum и его современной реинкарнации, но уже в составе FPGA (ZX Spectrum Next)

P.S. Кто то даже на М4 — командном языке Linux делает кросс Форт в ассемблер Z80 для ZX-Spectrum M4 FORTH: A Forth compiler for the Z80 CPU and ZX Spectrum :)

Моя единственная эмоция по отношению к ностальгическим пользователям Z80 - это сочувствие их приближающемуся пенсионному возрасту. Лично я тратить мой приближающийся пенсионный возраст на них не собираюсь.

Я хочу подготовить из современных школьников и студентов продвинутых ASIC-дизайнеров для гигагерцовых гетерогенных heavily pipelined систем на кристалле. Чтобы они могли при желании пройти cсобеседование на работу в Apple, Intel, NVidia и другие интересные места. И после работы в большой компании сделать старптап и получить сто миллионов финансирования на свой процессор от венчурных капиталистов.

Для целевой аудитории ZX-Spectrum имеет примерно такую же актуальность как холлеритовская перфокарта или магнитный барабан емкостью два килобайта и весом две тонны.

Интересная идея про барабан ))))))) взять 2048 микроконтроллеров, сделать из них сеть, каждый будет выдавать "свой байт", нацепить "всё это" на барабан, центральным "процессором" обрабатывать положение барабана в пространстве и выдавать команды микроконтроллерам в определенное положение барабана в пространстве. )))))))) КЛАСС???!!! )))))))))

Кстати, да, я подумал, что на барабане можно сделать забавную задачку в упражнения по FPGA. Тут главное не увлекаться и не начинать реализовывать на FPGA весь компьютер 1955 года с барабаном

Какой то курьёзный процессор.
Human Resource Machine CPU (Verilog)




P.S. Забавно, наверное, может выглядеть мультипликация выполнения программ на командах калькулятора БЗ-34 упомянутого в опроснике. :)

Какое то количество таких программ представлено для
МК-61/52 на rosettacode.org.
(а, для МК161/152 даже на его командах сделали полноценный Форт c названием Калисто и кросс Форт eForth )

Кошмар, столько усилий, и чисто для хоббистики.

Впрочем, как говорил наш учитель истории в школе "чем бы дитя не тешилось, только бы не забеременело"

Может этому разработчику не надо 100 мульёнов для создания своего процессора. :)
Sign up to leave a comment.

Articles