То, что кто-то назвал инструкцию как or.h не означает то, что это именно or.h а не lui. Грепнул листинг, во всех случаях этот or.h используется именно как lui. Все команды с этой инструкцией имеют вид or.h rX, r0, imm16, что как раз и является загрузкой imm16 в верхную часть регистра, ибо r0 - вседа 0.
Всё же не вижу отличий от MIPS'a, кроме ремапа опкодов (не проверял).
Разве? А как там подгружаются 32-битные числа в 32-битные регистры, если вся инструкция 32 бита? Насколько я помню, там как раз и используется схема lui/ori, когда первая команда заносит верхние 16 бит, а вторая - нижние.
Почти. Шина 8-битная, но она мультиплексирована и используется и для 8-битных данных и для 16-битного адреса. Поэтому и было как минимум 3 такта на команду - в первый такт 8008 отправлял первую половину адреса (8-бит), во второй еще 6 бит адреса + 2 контрольных бита, а уже только во время тертьего такта общая шина используется для обмена данными.
Но они выбрали мультиплексированные пины именно из-за ограничений корпусировки. В 8080/8086 тоже есть отголоски этого, но уже гораздо слабее.
Почему? Я не очень шарю, но когда разрабатываю платы, то сначала расставляю взаимодействющие инетрфейсные компоненты поближе друг к другу (скажем, микроконтроллер и USB-разьём), а потом уже где место осталось втыкаю контроллеры питания и менее важные компоненты. Есть ли что-то плохое в том, чтоб провести линии питания через всю плату на отдельном слое?
В США такая версия электропикапа Foundation Series (три электродвигателями суммарной мощностью 845 л.с. и крутящий моментом 13 960 Н•м) стоит $100 тыс
Даже на скриншоте видно 600лс, а в самом объявлении "Tesla Cybertruck AWD Foundation -- это версия с двумя электромоторами и наибольшим запасом хода ".
Не исключено. В своё время пофиксил пару багов в qucs, который увы уже не очень развивается. Но пока мои проекты для FPGA достаточно просты, чтоб уходить в сторону более сложных абстракций. Пару тысяч строк на верилоге можно и руками набросать без синтаксического сахара.
Почему при разработке сложной цифровой аппаратуры Вам все еще нужен уровен абстрации в виде проводов и D-триггеров ?
Ну вот так получается :) Сами же упоминали важность изучения вывода низкоуровневых утилит. Бывает что нужно разбираться куда пропадают сигналы, которые в исходниках есть, а из netlist'a пропадают, или почему появилась метастабильность.
Может быть пора оторваться и перейти на уровень повыше ?
Я бы рад, но увы пока даже перейти на уровень Verilog'a не всегда выходит. Возможно это потому что у меня недостаточно опыта.
Вангую, с цифровым синтезом будет всё то же самое.
Хорошо если так, но проект пока ИМХО слишком молод и ментейнеров/контрибьюторов не так много.
Конечно, весьма привлекательно использовать SpinalHDL, но это дополнительный слой абстракции. Недостаточно будет знать этот HDL, всё равно потребуется разбираться в языке, в который он транслируется. И любой баг в трансляторе может стоить много часов отладки. Как правильно написано в статье, иногда требуется погружаться на несколько уровней ниже Verilog'a/VHDL'a чтоб понять какие чудеса натворил оптимизатор.
PS: посылаю лучи ненависти Libero SoC от MicroSemi, даже 20 лет назад тулчейн от Altera был лучше чем это современное поделие (v2024.1).
PPS: собирал icestorm из исходников под WSL чтоб залить битстрим на плату с iCE40 - заняло считаные секунды.
То, что кто-то назвал инструкцию как
or.hне означает то, что это именноor.hа неlui. Грепнул листинг, во всех случаях этотor.hиспользуется именно какlui. Все команды с этой инструкцией имеют видor.h rX, r0, imm16, что как раз и является загрузкой imm16 в верхную часть регистра, ибо r0 - вседа 0.Всё же не вижу отличий от MIPS'a, кроме ремапа опкодов (не проверял).
Занятно, недавно наткнулся на похожее видео - https://www.youtube.com/watch?v=KzT9I1d-LlQ
Разве? А как там подгружаются 32-битные числа в 32-битные регистры, если вся инструкция 32 бита? Насколько я помню, там как раз и используется схема lui/ori, когда первая команда заносит верхние 16 бит, а вторая - нижние.
Обычный же первый MIPS, не?
Почти. Шина 8-битная, но она мультиплексирована и используется и для 8-битных данных и для 16-битного адреса. Поэтому и было как минимум 3 такта на команду - в первый такт 8008 отправлял первую половину адреса (8-бит), во второй еще 6 бит адреса + 2 контрольных бита, а уже только во время тертьего такта общая шина используется для обмена данными.
Но они выбрали мультиплексированные пины именно из-за ограничений корпусировки. В 8080/8086 тоже есть отголоски этого, но уже гораздо слабее.
У меня не 3M, а Aries 28-6554-11, немного универсальнее.
Занятно, недавно тоже рисовал подобную панельку в Ondsel (FreeCAD с плюшками). Правда потом в KiCad её подгружал.
Почему? Я не очень шарю, но когда разрабатываю платы, то сначала расставляю взаимодействющие инетрфейсные компоненты поближе друг к другу (скажем, микроконтроллер и USB-разьём), а потом уже где место осталось втыкаю контроллеры питания и менее важные компоненты. Есть ли что-то плохое в том, чтоб провести линии питания через всю плату на отдельном слое?
И в обзоре ни одной мышки с КДПВ? :)
Пользуюсь MX Master 3S и вполне доволен.
Нет, не даст. 1024 это всего 16 цифр по 64 бита. Карацуба в зависимости от архитектуры начинает стрелять с 50+ цифр.
Даже на скриншоте видно 600лс, а в самом объявлении "Tesla Cybertruck AWD Foundation -- это версия с двумя электромоторами и наибольшим запасом хода ".
Исходное сообщение для отправки всегда в нижнем регистре.
Есть немного более универсальный проект - https://github.com/hoglet67/RGBtoHDMI/wiki
Первое число это как раз жёсткий лимит. Даже в примере это очевидно, ибо жёсткий лимит не может быть меньше мягкого ;)
Весьма напоминает обычное рекурсивное деление - https://maths-people.anu.edu.au/~brent/pd/mca-cup-0.5.9.pdf (RecursiveDivRem). Оно в GMP используется, к примеру.
Не исключено. В своё время пофиксил пару багов в qucs, который увы уже не очень развивается. Но пока мои проекты для FPGA достаточно просты, чтоб уходить в сторону более сложных абстракций. Пару тысяч строк на верилоге можно и руками набросать без синтаксического сахара.
Ну вот так получается :) Сами же упоминали важность изучения вывода низкоуровневых утилит. Бывает что нужно разбираться куда пропадают сигналы, которые в исходниках есть, а из netlist'a пропадают, или почему появилась метастабильность.
Я бы рад, но увы пока даже перейти на уровень Verilog'a не всегда выходит. Возможно это потому что у меня недостаточно опыта.
Хорошо если так, но проект пока ИМХО слишком молод и ментейнеров/контрибьюторов не так много.
Конечно, весьма привлекательно использовать SpinalHDL, но это дополнительный слой абстракции. Недостаточно будет знать этот HDL, всё равно потребуется разбираться в языке, в который он транслируется. И любой баг в трансляторе может стоить много часов отладки. Как правильно написано в статье, иногда требуется погружаться на несколько уровней ниже Verilog'a/VHDL'a чтоб понять какие чудеса натворил оптимизатор.
PS: посылаю лучи ненависти Libero SoC от MicroSemi, даже 20 лет назад тулчейн от Altera был лучше чем это современное поделие (v2024.1).
PPS: собирал icestorm из исходников под WSL чтоб залить битстрим на плату с iCE40 - заняло считаные секунды.
Ну они только недавно добавили дисплей в руль. Все остальные команды давно уже пришли к цифровому табло вместо кучи индикаторов.