Китайский производитель чипов T-Head, принадлежащий компании Alibaba Group, опубликовал результаты портирования платформы Android 10 на платы, оснащённые процессорами на базе архитектуры RISC-V. Патчи подготовлены для кодовой базы AOSP (Android Open Source Project) и охватывают различные подсистемы, включая графический стек, библиотеку bionic, виртуальную машину dalvik и фреймворки. Прилагается сценарий для самостоятельной сборки AOSP для устройств RISC-V или для запуска в эмуляторе...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54459
Гуглю нет доверия!
А китайцам -- тем более.
доверяешь только гномам ?
> доверяешь только гномам ?Гномам только глупые гоблины доверяют, они ж жадины что пипец.
Так вот кто пользователи гномского рабочего стола! )
> Так вот кто пользователи гномского рабочего стола! )А ты как думал!
Доверять можно только Беркли
> Доверять можно только БерклиAT&T так не считал.
Слово "Google" в новости не обнаруживается.
Я тебе даже подскажу немного:Репозиторий исходного кода: https://android.googlesource.com
Надеюсь, линукс здорового человека будет на RV больше распространён, чем ведроид.
Были бы еще доступны эти риски. Сейчас в основном отладочные платы за 100500 и какие-то микроконтроллеры на попробовать.
Здесь можно купить плату RISC-V с беспроводной связью за 180 бел. рублей с доставкой: https://www.crowdsupply.com/sifive/hifive1-rev-b
>Running at 320+ MHz, the FE310 is among the fastest microcontrollers on the market.девборда на поиграться же, полноценных пк или мобильных пока не видать
А что мешает использовать её как полноценный ПК?
>320+ MHz;-)
>RISC-V:p
уровень нокии начала нулевых.
Или телевизора 2019 года.
Я рад, что риск-в смог в 2019-ом обработать сигнал от ИК-фотодиода... И как только в прошлом веке это делали?! Прикинь, даже видеоигры были на пиках, которые сами видеосигнал генерили... безо всяких риск-в-ж* и невидия-ртх...
> Я рад, что риск-в смог в 2019-ом обработать сигнал от ИК-фотодиода... И
> как только в прошлом веке это делали?! Прикинь, даже видеоигры были
> на пиках, которые сами видеосигнал генерили... безо всяких риск-в-ж* и невидия-ртх...Только програмить этот пик - рыдание сплошное. Система команд скотская, сишный компилер пародия на таковой, константы хранить в флеше вообще трэш. Единственное их достоинство - при покупке миллиона их отдают почти за цену пластика и кремния, т.к. делается на доисторическом оборудовании которое иначе давно пошло бы в утиль.
> > RISC-V :pПросто набор букв со смайликом. Что сказать-то хотел?
> А что мешает использовать её как полноценный ПК?То же самое, что мешает какую-нибудь PSP 333 МГц использовать как полноценный ПК. И тут PSP просто рвёт твою демоплатку.
> То же самое, что мешает какую-нибудь PSP 333 МГц использовать как полноценный
> ПК. И тут PSP просто рвёт твою демоплатку.Демоплатку можно в ту или иную автоматизацию прикрутить, в общем то. Хотя логичнее на ее основе понять как это делается и прикрутить тот чип на свою плату специфичную для задачи. С этим знанием можно запилить управление и автоматизацию, более-менее на уровне.
А чего с твоей PSP делать, кроме страдания фигней? Это вообще знание не имеющее практической ценности в этом мире. Люди не посчитают это чем-то полезным для них и денег за это не дадут.
> девборда на поиграться же, полноценных пк или мобильных пока не видатьКак тебе такое, Элон Маск? https://www.crowdsupply.com/sifive/hifive-unmatched
А знаешь, почему там не пишут ни частоту проца, ни его производительность? Потому что она на уровне Нокия 3310.
> А знаешь, почему там не пишут ни частоту проца, ни его производительность?
> Потому что она на уровне Нокия 3310.Я бы не отказался от 4-ядерной 64-битной 3310 с pci-e на борту. А для тебя есть вон те EPYC за несколько килогринов с TDP ватт под 300.
> А знаешь, почему там не пишут ни частоту проца, ни его производительность?
> Потому что она на уровне Нокия 3310.Я думаю что сие может быть по минимуму даже и моим рабочим компом. Даже amd GPU можно воткнуть. Конечно геймерской системой оно не станет, но в каде порисовать, попрогать или даже фоты отредактировать на большом экране с его параметрами лично мне вполне прокатит. И это избавит меня от "радостей" проприетарной крапвари которыми я сыт по горло на моих системах.
Можно, но не нужно... Можно и телефон достать из прошлого века, но зачем?!
Чтобы сделать мультимедийное устройство.
Берёшь старую Нокию - вот тебе готовое мультимедиа. Что-то серьёзней всё равно на той демоплатке не сделаешь.
> Берёшь старую Нокию - вот тебе готовое мультимедиа.Угу, ЩА! Операционка либо "proprietary" либо "symbian". Обе без сорцов, зато подписями облеплены как собака блохами. Так что хоть что-то в операционке поменять адсккая джопаболь. Для 3310, который не огороженый еще был так даже делали, но в нем мультимедия ограничена чернобелым экраном 64х96 и одноголосой бибикалкой, кажись. Сейчас даже на микроконтроллере можно получше чем это.
> Что-то серьёзней всё равно на той демоплатке не сделаешь.
Вон там рядом почти компьютер. Да и на неогороженной демоплатке в общем то можно сделать довольно много чего. За то время которое на нокии будет урыто на борьбу с искусственно созданными проприетарщиками проблемами.
Ну не 100500, а только лишь $150 как в новости, будут и ещё дешевле.
> будутОпять будущее время... Может, хватит уж кормить завтраками?!
Судя по тому что за дело взялись узкоглазые, скоро этим будет завален алиэкспресс. К тому же у них эффективный стимул - торговые войны с сша и покупка ARM (американской) нвидией.
Вот только доверия таким устройствам будет на нуле. Верить в то что они не заложат закладки не верю.
> Вот только доверия таким устройствам будет на нуле. Верить в то что
> они не заложат закладки не верю.Пожвальная китайская лавочка - не фирма интел, чтобы слить денег и пару инженерных команд на кодинг Management Engine. Конечно "забыть дефолтный пароль на менеджмент" они могут, но зачем же софт от них использовать? Прошареные люди и сейчас из китайских роутеров первым делом выкидывают гавно с иероглифами и openwrt прошивают. Тогда дешево и круто.
Там закладки прямо в железе.
> Там закладки прямо в железе.И, конечно, вы их покажете? А то ME - вон он, даже и не прячется особо. Но интел может позволить себе пару команд на "фичу" спихнуть, у них денег много и инженеров явный переизбыток.
Проще вшить закладку в железо, чем палиться с прошивкой.
Китайским фирмам-производителям чипов не придётся разрабатывать бэкдоры самостоятельно. Партия готовые бесплатно раздаст, которые разработают специальные производители бэкдоров. Нужно будет только интегрировать и пройти набор тестов.
Партия умеет чипы разрабатывать? И даже вхожа в техпроцессы какого-нибудь TSMC? К тому же хардварные бэкдоры имеют большой жирный минус - апдейту не поддаются. Эппл с дырой в бутроме недавно это ощутил, когда кто попало может takeover их типа-secureboot'а теперь. И ничего с этим не сделаешь ведь, ROM в кристалле вшит и уж какой с фабы вышел :)
> и покупка ARM (американской) нвидиейУвы, сделку тормознули, будет доооолгое разбирательство. Причём даже с американской стороны недовольны, не говоря про британскую и китайскую.
> Увы, сделку тормознули, будет доооолгое разбирательство. Причём даже с американской стороны
> недовольны, не говоря про британскую и китайскую.Людям очень неудобно и некомфортно завязывать всю свою деятельность на результат 1 разбирательства по 1 фирме. Потому что если это будет не так как им удобно - они чего тогда будут делать? Закрывать фирмы оптом и перепрофилироваться в землепашцев?
Нвидия очень хорошо напомнила нам всем почему opensource matters. Это болезненный, но полезный пинок. Спасибо.
> Были бы еще доступны эти рискиДа кому нужно это недоразумение?! Вон, китайцы выпускают гигагерцовые вортексы x86 (486), потому что не кидаются на зазывающие слова "открытый набор команд", а делают то, что реально востребовано.
> Да кому нужно это недоразумение?! Вон, китайцы выпускают гигагерцовые вортексы x86 (486),
> потому что не кидаются на зазывающие слова "открытый набор команд", а
> делают то, что реально востребовано.Вот это уже совершенно точно востребовано меньше чем RISCV. На RISCV китайцы уже даже микроконтроллеры за копье настрогали. А вон GD32 - то же самое что и STM32, только процессорное ядро заменили на китайский вариант RISCV. Они там вообще чипов накопипастили на все вкусы, поставив дело на поток. И что-то мне подсказывает что на 1 проданый вортекс будет 1 вагон проданых GD32. Это добро неплохо разлетается - в ту самую китайскую электронику которую вы так бодро сметаете на али.
Ну и классический ответ:
"Когда он будет удобен в использовании и будет гуй на всё"
Ведроиду отсуствие этого всего не помешало почему-то.
Ведру "повезло", когда они с помощью MS закрыли Нокию.
Ладно уж, не обязательно гуй на всё. Главное, чтобы не буй на всё.
> Главное, чтобы не буй на всё.Вот именно "буй на всё" и заложили в архитектуре риск-в... Ни флагов, ни исключений при вычислениях... Сам всё делай лапками! В результате у каждого, кто пытается юзать это чудо, свой набор расширений, ни с кем не совместимых. Кто в сад, кто в огород.
Альтернатива - как в x86 с A20 и прочим тасканием дерьма из года в год
>> Главное, чтобы не буй на всё.
> Вот именно "буй на всё" и заложили в архитектуре риск-в... Ни флагов,Флаги не обязательны - классический RISC работает на сравнениях значений в регистрах, и на SSA, который в GCC, Clang, MSVC и скоро будет вообще везде, ложится прямее. Есть ещё вариант с предикатными однобитными регистрами (NVidia, IA64 и прочие).
Тот, кто думает, что без флагов жизни нет, отстал лет на 30.
> ни исключений при вычислениях...Исключение при делении точно так же убрано в AArch64, ибо нефиг. Причём там ещё коварнее - если RISC-V отдаёт в этом случае частное ~0, по которому можно заподозрить, что что-то не то, то AArch64 даёт 0.
Исключение при сложении-вычитании отсутствует в ARM, x86 и прочих (как минимум вставлять явный into). Исключения знакового сложения-вычитания присутствуют в MIPS-R, но современные компиляторы их не вставляют даже там, где вроде бы нужно - логика компиляторов поменялась.
Исключения в плавучке нигде не обязательны и на практике у 99.9% заглушены (если и проверяются, то после).
Анониму номер 185 следует перестать говорить о том, в чём разбирается на нуле.> Сам всё делай лапками! В результате у
> каждого, кто пытается юзать это чудо, свой набор расширений, ни с
> кем не совместимых. Кто в сад, кто в огород.С расширениями поднятые вопросы никак не связаны. И пока что идёт утрясание базовой модели с выбираниями лучших решений из расширений.
Чем эта плата в дополнении лучше raspberry pi 4? USB3.0? Зато Bluetooth 4.0В остальном, не увидел ничего интересного.
Своей архитектурой. Процессоры RISC-V ещё проще по набору команд, чем ARM, а преимущества ARM перед х86-64 известны всем - меньше потребление и нагрев, больше открытость (интел и амд засекречивают)
Ну и вообще, как мне кажется, это скорее Proof-of-concept, на котором можно будет поэкспериментировать с RISC-V. Надо же с чего то начинать, вот начали с одноплатника
По арм всё как в сказке описал, только тактично опустил тему её новых хозяев.
Весь RISC-V ныне - это один большой сплошной proof-of-concept.
На то, что оно вообще не взлетит, я не поставлю, но вероятность высока.
> RISC-V ... что не взлетит ... вероятность высока.Так и есть, Вортексы сейчас и то более востребованы, хотя это всего лишь 486 (но экономный и гигагерцовый).
> Так и есть, Вортексы сейчас и то более востребованы, хотя это всего
> лишь 486 (но экономный и гигагерцовый).Да кому это ископаемое фекалье нужно? Полутора индустриальным некромантам, которые по какой-то причине так и не смогли заменить софт из 90х? На _этом_ современные линухи работать уже не будут, на 486-й набор команд все уже давно положили. Это в лине deprecated, если не unsupported. А для RISCV история наоборот только начинается.
Для RISCV история уже много лет начинается, но так никак и не начнётся. Полтора эксперимента.
Открытое железо - это хорошо, но платформа RISC выбрана не то, что неудачно, а вообще бесперспективняк, если честно.
> Для RISCV история уже много лет начинается, но так никак и не начнётся."Языком трындеть - не мешки ворочать".
> Полтора эксперимента.
...было лет 5 назад, а сейчас, особенно после nvidia vs arm уже другой порядок величин.
> Открытое железо - это хорошо, но платформа RISC выбрана не то, что
> неудачно, а вообще бесперспективняк, если честно.WORKSFORME. А вы можете выбирать что вам там угодно. Если сможете.
Вот читаю я вас и начинаю сомневаться в преимуществах плановой экономики, ведь такие умники наверное в госплане СССР и сидели.
> плановой экономикиЗакопать. Рядом с RISC-V.
> Закопать. Рядом с RISC-V.Нашелся тут кладокопатель...
Alibaba Group, in July 2019 announced the 2.5 GHz 16-core 64-bit (RV64GCV) XuanTie 910 out-of-order processor[46]Почему-то и OoO есть, и ядер 16, и вообще, довольно непозорный по параметрам проц. Который, к тому же, у алибабы уже никто не отнимет...
Почему? Потому что RISC - это голая оптимизация под конкретные ALU компилятором, не дополненная оптимизацией в рантайме, и очень рыхлое не шаткое не валкое исполнение. Малейшее развитие - и всю оптимизацию надо переделывать заново, в этом основная проблема.Стоило сразу по аналогии с x86 делать CISCoRISC, и далее отталкиваться от него - CISC на фронте, RISC на подложке.
> Почему? Потому что RISC - это голая оптимизация под конкретные ALU компилятором,
> не дополненная оптимизацией в рантайме,Это заявление вроде бы ниоткуда не следует. И как показывают жирные реализации ARMов и RISCV - вопрос желания. Впрочем в современном мире можно и просто больше ядер накопипастить, коли уж они примитивные.
> и очень рыхлое не шаткое не валкое исполнение.
Я бы не назвал допустим thumb2 рыхлым. И таки они показали как делать плотный код под RISC, для RISCV нечто похожее собезьянили. Похуже, но вы ведь и так не сделаете, так что к чему ваши рассусоливания?
> Малейшее развитие - и всю оптимизацию надо переделывать заново, в этом основная проблема.
С проблемами разбирается обладатель таковых прежде всего. У меня этих проблем нет - в том плане что мне для хреновой кучи задач хватит перфоманса RISCV, и это уже покрывает диапазон от МК до десктопа или микросервера. А что там будут делать рожи с майнфреймами - лично мне не интересно, совсем.
> Стоило сразу по аналогии с x86 делать CISCoRISC, и далее отталкиваться от
> него - CISC на фронте, RISC на подложке.Вообще-то даже сам интел считает это легаси, и итаник был совсем другой штукой. Но там глупый маркетинг, груз совместимости и wintel'изация мира их потопила. Но здесь вам не тут! Это добро уже сильно дешевле итаника - и будет накуплено легионами девов. Которые исправят и оптимизируют софт под это, в отличие от итаника.
> С проблемами разбирается обладатель таковых прежде всегоИменно так. Поэтому абсолютное и подавляющее большинство индустрии в сторону RISC-V даже не посмотрит.
> Именно так. Поэтому абсолютное и подавляющее большинство индустрии в сторону RISC-V даже
> не посмотрит.Вообще-то довольно большое количество довольно жирных фирм резко напряглось от идеи что ИХ КОНКУРЕНТ не будет им лицензировать новые ядра. И как-то стали сильно щедрее на инвестиции и все такое. Потому что проинвестировать В СВОЕ БУДУЩЕЕ лучше чем лишиться нахрен бизнеса в обозримой перспективе. А какой у них выбор есть? А всякие китайцы на примере хуавэя и ко получили очень годное превью как примерно это может быть. Им, кажется, не понравилось судя по всплеску китайских riscv
Wishful thinking - это хорошо.
> Wishful thinking - это хорошо.Держать руку на пульсе отрасли в которой варишься - не wishful thinking а что-то другое, имхо.
А с чего у вас такой батхерт? Так подгорает от того что я смогу послать к архидьяволу заколебавшие блобы даже на моих десктопах и серверах? Так я давно об этом мечтал и даже иногда денег тематическим проектам пулял, ибо don't let your dreams to be just dreams (c). И кажется я такой не один.
Ну а вы можете наслаждаться ME и PSP, разглагольствуя про то что и как "надо" делать. Это вроде единственная опция которую вы реально можете предложить взамен, не?
> Держать руку на пульсе отрасли в которой варишьсяМного юнитов на RISC-V запустили?
Wishful thinking.
> Много юнитов на RISC-V запустили?Тебя что, CrowdSupply забанил? Он там целую подборочку riscv проектов любезно вываливает. Так что я набрел заодно на вон ту штуку с 4-я 64-битными ядрами и pcie на борту.
> Wishful thinking.
Лучше скажи чего у тебя так подгорает? И да, лично я хочу пользоваться нормальным железом, без о...вших вендоров, полагающих что гадить мне за мои же деньги или диктовать невменяемые условия типа ок. А чего такого в этом желании?! Ну вот я не хочу допустим левые мутные блобы, ни в системном фирмваре ни в сервисных сопроцессорах, потому что как показал пример интел и амд, используются они очень характерно - и не в пользу покупателя. Поэтому лично я с удовольствием дам денег тем кто просто делает железо, документирует его и дружественнен к опенсорцу, а не занимается подобной вот фигней.
Ты хочешь пользоваться нормальным железом, на котором ничего не запустил?
Или всё-таки хотя бы одну реально попробовал?
(мне то необходимости говно есть нет - я прекрасно понимаю, чем CISCoRISC от RISC отличается, и почему в общем случае RISC ничего, кроме геморроя, не принесёт)
> Ты хочешь пользоваться нормальным железом,Да. И в понятие нормальности входит отсутствие ME/PSP/unfixable блобварей без сорца.
> на котором ничего не запустил?
У меня там будет ровно тот же софт что и в других случаяхх. Его достаточно тупо перекомпилить GCC для RISCV.
> Или всё-таки хотя бы одну реально попробовал?
Всему свое время и место. А так парочка МК с этим у меня есть уже. Вон ту штуку с pcie я пожалуй попробую. Но да, пока дистры под RISCV только начинают порты делать. Желающие это здесь и сейчас должны быть морально готовы к "early adopter experience". Однако не боги горшки обжигают.
> (мне то необходимости говно есть нет - я прекрасно понимаю, чем CISCoRISC
> от RISC отличается, и почему в общем случае RISC ничего, кроме
> геморроя, не принесёт)Я не знаю у кого там будет геморрой, но явно не у меня. Мне с RISC нормально. Вон ARMов миллиарды, и ничего, не умерли вроде. А вы все-равно не имеете ничего предложить кроме сферического vaporware в вакууме, даже не оформленном как сорец проца, не говоря про кремний.
А г-на я уже от души наелся с интелем и амд. И - вот честно - надоело. Меня заколебали баги проприетарных биосов и уефи. Вот реально, ни 1 вменяемой фирмвари. ACPI на x86 вообще состоит из багов чуть более чем полностью. Вот буквально каждая первая проприетарная дрянь кладет на спеки большой болт и заполняет таблицы левой пяткой индуса перекинутой через правое ухо. При том этот булшит НИКТО НИКОГДА НЕ ПОЧИНИТ. Вот это - гамно. И когда фирмварь стартует дольше чем весь мой линукс с десктопом - это тоже гамно.
>меньше потреблениена единицу FLOPS - не особо
>больше открытостьпонятно, пишешь из альтернативной реальности
Там AI парочка ускорителей на несколько терафлопс.
> Там AI парочка ускорителей на несколько терафлопс.Тера...iops вы хотели сказать? У невротиков в моде int8 или 16, максимально примитивные alu, зато набиты как нейроны в мозге. Для плавучки alu сложнее.
Ну да, но при желании много чего с флоатов на инты перевести можно, не только сетки.
> Ну да, но при желании много чего с флоатов на инты перевести
> можно, не только сетки.Разумеется. А какие-нибудь майнеры так и вовсе даже и переводить особо не надо, им и так:)
>открытостьюДа ни хера ж подобного. У АМД и Интел и документации на ЦПУ просто тысячами страниц, и есть стандартный механизм BIOS, который ещё поддерживают, на котором хоть свою ОСь можно завести за пару недель.
А у arm на каждом камне memory map свой, загрузчиков стандартных нет. Поэтому пока Пи-фаундейшен ядро не выпустит, крутись как хочешь. Хоть случайные адреса реверси, хочешь, микроскопом просвечивай.
Хотя я не уверен, что риск-5 чем-то лучше.
Байкал, кстати, не risc-v?
> Да ни хера ж подобного. У АМД и Интел и документации на
> ЦПУ просто тысячами страниц, и есть стандартный механизм BIOS, который ещё
> поддерживают, на котором хоть свою ОСь можно завести за пару недель.И где там расписано как ME программировать? Да и инициализация железа - вот вам блобы (AGESA -> AMD, FSP -> Intel) - жрите это. А как оно там внутрях работает мы вам не расскажем.
Т.е. там на тысячах страниц что-то, конечно, написано. Но это не позволит вам с ноля накодить ваше собственное, делающее старт платформы с power on. И парочка паскудных процов, типа ME, PSP, SMU и проч будет side-by-side с вами болтаться, вообще без документации, зато умея дернуть вон тот DMA контроллер. И какая разница что у вас там за операционка, если эта проприетарь может ее по своему желанию пропатчить в памти если так захочет?
> А у arm на каждом камне memory map свой, загрузчиков стандартных нет.
Uboot вполне стандартный вроде.
> Поэтому пока Пи-фаундейшен ядро не выпустит, крутись как хочешь.
Да какая вам разница какой там загрузчик? Париться этим будут более высокоразвитые существа, а для тех кому напрягаться вломы они как раз и выкатят черти-что с блобами. А вы как хотели, хомячить и чтобы вас за дурака не посчитали? Так не бывает!
> Да и инициализация железа - вот вам блобы ... жрите это. А как оно там внутрях работает мы вам не расскажем.Ну, в вёдрах и яйфонах кругом блобы, и все жрут с удовольствием. Подсказать причину?
> Ну, в вёдрах и яйфонах кругом блобы, и все жрут с удовольствием.Как видим в подобных новостях - все же не все.
> Подсказать причину?
"Их должно резать или стричь"
> Байкал, кстати, не risc-v?ARM он, кажись. Сейчас нвидия дожует покупку и тогда можно будет про какой-нибудь CAATSA вспомнить. Уже налицензированное не отберут конечно но захотите ли вы по гроб пользоваться старым процессорным ядром...
> Сейчас нвидия дожует покупкуОбнови себе инфу, сделку тормознули.
> Обнови себе инфу, сделку тормознули.Я не буду расчитывать только на это, поэтому на всякий уже прикупил в коллекцию парочку GD32 с RISCV на борту. Перспективы иметь дело с нвидией когда вопрос касается девтулов и доков лично меня не возбуждает.
> Уже налицензированное не отберут конечноА вот тут не надо столь уверенным быть. Как вот "недавно" по мипсу сказали: "Все пользователи свободной лицензии должны в 30-дневеный срок привести в соответствие..." (и т.д.)
Что-то под лицензией кориайт или копилефт не важно по определению не может быть свободной.
Свободный может быть только что-то без лицензии.
> Свободный может быть только что-то без лицензии.Какой ты наивный... Будь добр, посмотри, под какой лицензией предоставляют RISC-V ISA документы, например. И не пори больше чушь.
> Свободный может быть только что-то без лицензии.Юзер IP без лицензии как раз может перестать быть свободным. Так в копирастических законах написано, независимо от того нравятся они нам или нет.
> А вот тут не надо столь уверенным быть.Это основы копирастического законодательства. Дрессируя волков следует изучить их повадки. Иначе порвать могут.
> Как вот "недавно" по мипсу сказали: "Все пользователи свободной лицензии должны
> в 30-дневеный срок привести в соответствие..." (и т.д.)Лицензия обратного хода не имеет. Так что если я уже что-то взял под старыми условиями - то взял. Это впрочем не мешает сменить правила игры в новой версии. Что впрочем не обязывает использовать эту версию - ластикам и икебанам амазон как раз приветы передавал.
>Байкал, кстати, не risc-v?Байкал-Т1 - 2x MIPS32 R5
>А у arm на каждом камне memory map свойА не для того в kernel'е сделали Device Tree?
> А не для того в kernel'е сделали Device Tree?В том числе и для этого. А заодно и описание что и где в конкретной железке, даже если простая шина в PnP совсем не умеет, как i2c/spi и проч. Это позволяет одному кернелу цеплять весьма разные железки, в допущении что драйверы вообще есть а boot loader/firmware/создатель платформы в принципе DTB ядру отдали. Так что сейчас 1 и тот же кернел может кучу разных железок подхватывать.
В том-то и прикол, что подхватывается только то, что в DTB. А что надо - скрыто от глаз и доступно только через блобы.
> В том-то и прикол, что подхватывается только то, что в DTB.Что логично. Более того - бывает и так что некая периферия допустим есть, потому что кристалл от более фичастой SoC - но на лапки не разварена. И кули смысла ее в DTB заявлять? Зачем вам какой-нибудь контроллер дисплея, который будет делать вид что живой, жрать питание, но вот отрисовать ничего не способен - за отсутствием физических лапок на это у того чипа.
> А что надо - скрыто от глаз и доступно только через блобы.
А круто наверное расскатывать все это тому кто DTS'ы умеет писать и грузить из своего бутлоадера эти самые DTB, правда? Но увы, если вы хотели на дурака проскочить, это не получилось. Я неплохо знаю что у меня в железе и бутлоадере.
И кстати если кто думает что народ не сканит регистры, не тыкает палочками в "reserved" и "undocumented" и проч - это вы зря. С китайцами это вообще стандартный modus of operandi, они, видите ли, только склеивают кубики лицензированные у других. Как это работает они вообще без понятия, поэтому даташит состоит из копипаст чипмейкерской документации на IP блок. Поэтому вы узнаете много интересного про сигналы AHB и как их там конектить, хоть вы этот AHB и не увидите никогда, он унутрях кристалла и интересует все это только того кто вон тот периферийный блок к вот тому процессорному ядру при разработке чипа подклеивал. А разработчикам софта, даже самого начального бутлоадера это лишнее знание.
Я думаю предидущий оратор про блоки не прописанные в DT оригинальной прошивки, но используемые какой-нибудь myveryownpowerctl.ko, в которой адреса просто захардкожены.Зачем так делать я не знаю, ибо привязывать свои драйвера через DT куда удобнее, но могут же.
> Я думаю предидущий оратор про блоки не прописанные в DT оригинальной прошивки,
> но используемые какой-нибудь myveryownpowerctl.ko, в которой адреса просто захардкожены.Да я даже и сам так делал немного - даже и не из .ko а вообще mmap() /dev/mem и дальше вон там чудные "HW regs" - ща я их, как обычно, и какой мне хрен что эт не кернелмод покуда запись катит?
А, разумеется такая диверсия катит только от рута и только на ядрах без lockdown. Юзеру конечно же щелкать регистрами железок никто не даст. Ну, кроме sudoedit'а, хаха :)
> Зачем так делать я не знаю, ибо привязывать свои драйвера через DT
> куда удобнее, но могут же.Я так делал для unsupported ядром штуки, минимально пнув ее из юзермода. Но это изврат, делать так фу-фу.
> Байкал, кстати, не risc-v?К счастью, Байкал никак не запятнался с этим риск-в.
> К счастью, Байкал никак не запятнался с этим риск-в.Можешь покупать байкалы, если это для тебя лулше работает - какие проблемы. Но почему-то завалов байкалов по адекватной цене на горизонте не заметно. А так то их может даже и покупали бы - если интересное соотношение цены и качества предложить и производитель не будет жлобским. Но в РФ такие компании просто не водятся.
Послушайте - не позорьтесь. Человек, который задает вопрос - Байкал не на RISKV случайно, вообще и абсолютно не разбирается в архитектуре процессоров. Но с каким апломбом вы рассуждаете про недостатки РИСК 5...
P.S. Байкал на MIPS
Да, все 4 порта USB 3.0. К тому же, насколько мне известно, процессоры RISC-V не страдают от ошибок Meltdown/Spectre, как некоторые процессоры ARM.
> не страдают от ошибок Meltdown/SpectreЧему там страдать, когда все яйца отрезаны... Риск-V - это же кастрат, в котором многое надо руками программно делать.
> Meltdown/Spectreв Б3-34 тоже нет мельдония и спектра :)
>процессоры RISC-V не страдают от ошибок Meltdown/SpectreНе страдают они от Spectre, возможно, пока не завезли Out-Of-Order. А в некоторые разрабатываемые ядра O-O-O уже завезли.
Не покупай эти ядра.
Ой, как вы запели, оказывается, уже и риск-в не все ТЪРУ. А потом откроется, что и в выпускаемых риск-в есть ME и прочие закладки...
Нет там закладок.
> Нет там закладок.Сам микросхему выпускаешь?
Да.
> Чем эта плата в дополнении лучше raspberry pi 4?Отсутствием броадкома. Который жадная и проприетарная компания, а в случае косоглазых к тому же еще и американская, так что им могут на раз перекрыть поставки. И тогда чего? Поставить все проекты использующие это на паузу?
Вам шашечки или ехать?
> Вам шашечки или ехать?Когда таксист обладает видом грабителя банков, чихает без маски или начинает учить жизни не успев открыть дверь - я, пожалуй, на другом поеду.
Нет доверия любым корпорациям, и неважно, частным или нет, т.к. такие объединения хоронят инициативу, конкуренцию и новаторство. Да, кроме конкуренции есть ещё её антипод, кооперация, но в современном мире её ускользающе мало.
зачем dalvik портировать на risc-v?
вроде dalvik был заменён на ARM(android runtime), начиная с android 5?
Вообще-то ART
Но да, с далвиком непонятно...
Ну подумаешь, перепутали в пресс-релизе, делов-то... для китайцев это нормально.
Потому что ART - это Ahead-Of-Time компиляция. Не осилили.
Ну так Google сколько его пилил? Лет 5? Вот и Huaweii пока не осилил.
Называется, сошлись две ненужности.
Надо конечно бороть арм на его поле, но и там, где арм (arm based boards) традиционно не смог, надо тоже со старта всех рвать. Надо открытый UEFI, часы, батарейку. Ибо жонглирование флешками и ембед - это конечно весело, но... хочется всё же кампуктер.
хочется рабочий мобильный аппарат, энергоэффективный и функциональный, и это необязательно должен быть карманный «кампухтер»
Если очень хочется, то можно купить HiFive1 Rev B, матрицу, корпус, всё остальное и собрать ноутбук своими руками. Пусть он не будет особенно тонким, но его можно будет перевозить с места на место без особого труда.
> хочется рабочий мобильный аппарат, энергоэффективный и функциональный, и это необязательно
> должен быть карманный «кампухтер»Если не кампухтер - тогда либо звонилка, либо сборщик геолокации с хомяков. Других вариантов вроде особо и нет.
Умные часы?
> Умные часы?И батарейки для них :)
> Надо открытый UEFIДеланый Wintel'ом для впаривания DRM и секурбутов? А, ну тогда вам по популярным запросам и из RISCV это сделают, хомячка везде облапошивают. Да и андроид тому очень способствует. Так что в конечном итоге рулить твоей системой будет NSA пополам с луноликими, а поскольку копии ничего не стоят, они так и быть поделят твои данные на двоих.
Где процессор, а где UEFI? EFI как раз и сделан, чтобы от проприетарных BIOS избавиться.
ello году так в 2000 появилось, задолго до Win/HP/Apple.
> EFI как раз и сделан, чтобы от проприетарных BIOS избавиться.А в результате лишь заменили мелкого проприетарного пакостника на большой проприетарный монстр с секурбутами и бутгадами.
> ello году так в 2000 появилось, задолго до Win/HP/Apple.
Как угодно но в EFI маздайный формат бинарей на гвозди приколочен, и FAT32 оттуда же. Сразу видно кроссплатформенный замах.
Реализаций - вагон. Ставь какой хочешь.
> Реализаций - вагон. Ставь какой хочешь.Где этот вагон? И как мне это поставить на мой компьютер? А, никак? Отлично, поэтому по итогам мелкий проприетарный пакостник заменился на большой и наглый, еще более проприетарный, еще более наглый и стремный.
А для всего остального это как-то не очень удобно. Начиная с того простого момента что PE EXE видите ли в линуксах стандартным тулчейном не биллдуются, поэтому даже свой модуль этому майкрософтовскому шиту без камасутры не накодить. Системный тулчейн для этого куска wintelя недостаточно круто, надо напрочь кастомный. Я даже не знаю какой. Линуксоиды жестко читерят по этому поводу конечно, подшивая минимальные хидеры вручную, но вот это - не есть поддержка моей операционки и разработки модулей в ней. Нахрен.
Анонимы хотели и ждали.
Анонимам сделали.
Анонимы не доверяют.
Так да.. не вижу несогласованности.
Есть весьма радикальный вариант - сделать самому. Хотя возможно некоторые анонимы не доверяют даже себе?
> Хотя возможно некоторые анонимы не доверяют даже себе?И правильно делают.
По причине тонкости кишки и рук, растущих на выходе из оной.
Чем RISC-V лучше MIPS под который уже все давно портировано?
Вопрос закрыт... конторка wave которая рулила mips банкрот
у тебя устаревшие данные.
Пошел по рукам, т.к. поздно расчехлился с открытием и экосистемой. Новые владельцы полу-недо-отменили открытие архитектуры. Зачем и нафига, кто ж их там знает когда есть RISCV а IBM открыла power, но это уже проблемы нового владельца.
Продуманной архитектурой расширения.
Убожество, а не архитектура... Флагов нет, исключений нет (деление на 0, переполнение), всё надо ПРОГРАММНО делать.
У MIPS многие регистры не общие, имеют на сегодняшний день странные ограничения, RISC-V это исправил и это прекрасно.
> RISC-V это исправил...путём кастрации :)
> и это прекрасно.
...без бубенчиков. Приходится всё лапками делать.
Расширения в RISC-V сделаны в формате большого количества свободных и специально по функциональности сгруппированных регистров, и каждая разработка в рамках того группирования может делать как ей больше выгодно, не боясь конфликтов с функциональностью других групп (обработка исключения в MIPS — это та ещё радость).
> может делать как ей больше выгодноВсё свелось к тому, что нужно просто послать риск-V в ж* и делать самому.
> Всё свелось к тому, что нужно просто послать риск-V в ж* и делать самому.И как, много процессоров то понаделали? А, целый эльбрус, под который даже компилера нормального нет?
x86, arm... Тебе мало?! Плешивый вечно про какой-то эльбрус вспомнит. Возьми вортекс вместо риск-в.
> x86,Ну уж не этому уродцу учить других как процессоры делать.
> arm...
А оно "сделать самому" видите ли только для непонятно кого, кто пошел по рукам, и норовит нвидии солиться. Ядра то у них неплохие, а в последнее время они даже неплохо стали интегрироваться с открытой экосистемой, пиляя девтулсы и даже всякие штуки типа опенсорсной ATF и проч.
И все же, хоть линуксоиды и не злопамятные, но за MALI и многолетнее делание нам мозга они все же должны ответить. А когда их вот-вот сожрет нвидия - так она не будет ядра конкурентам лицензировать. Это заставляет немало компаний гадить кирпичами, от китайских фаблес подвалов с 5 разработчиками до транснациональных корпораций. Так что RISCV получил нефиговое развитие на фоне новостей о сделке.
> Тебе мало?! Плешивый вечно про какой-то эльбрус вспомнит. Возьми вортекс
> вместо риск-в.Ну так то ж не у "вас", а у толи softbank, толи нвидии. И если фирма ARM откажется лицензировать вам очередное ядро - тогда, собственно, чего? При том такой маневр заставил напрячься даже тех на кого CAATSA и близко не распостряняется. Кроме нее видите ли еще конкуренция есть.
p.s. а зачем мне ваш вортекс угробищный? У меня 486 был в 90-е какие-то, тогда это имело смысл. А сейчас в этом смысла - ноль.
> ...путём кастрации :)Как показал пример RISC вообще и ARM в частности, если оборвать всякую оверинженерию, сделать маленькое, крутое и эффективное ядро - при масштабировании всего этого можно получить довольно интересные результаты.
> сделать маленькое, крутое и эффективное ядров случае risc-v получилось маленькое, некрутое, неэффективное...
> в случае risc-v получилось маленькое, некрутое, неэффективное...Вон те штуки с 4 64-ядрами уже не такие маленькие. Или вам все что меньше EPYC'а за $4k - не процессор? :)
> уже не такие маленькиеОй, да, извини... risc-v получилось ОЖИРЕВШЕЕ, некрутое, неэффективное...
> Ой, да, извини... risc-v получилось ОЖИРЕВШЕЕ, некрутое, неэффективное...В смысле - ожиревшее? Оно под задачу конфигуряется, на манер ARM. Есть хренова куча реализаций, кому жирные и производительные, кому мелкие и экономные. И со всеми этими историями с нвидией арм очень сильно нарывается. Уже, имхо, нарвался. Такой всплеск активности по RISCV попер со всех направлений что охренеть просто. Много людей вдруг осознало что им неудобно когда кое-что зажато дверью, целиком управляемой их конкурентом. Или компанией не вхожей в отрасль - нвидия микроконтроллеры не делает и не в курсе специфики.
> Флагов нет, исключений нет (деление на 0, переполнение), всё надо ПРОГРАММНО делать.RISC вообще недружелюбны к любителям писать программы в машинном коде. Хочешь писать в машинном коде, пиши под 8086, или под PDP-11. Там хорошо получается. А, я б ещё порекомендовал глянуть на Сетунь, судя по слухам, там реально ассемблер был не нужен, потому что троичные машинные коды читались как ассемблер.
А для тех, кто полагается на компилятор, хорошо: меньше флагов и исключений, -- меньше зависимостей между командами, больше простора компилятору для оптимизаций; меньше исключений -- меньше сбросов кеша. В этом смысле, исключений от деления на ноль вполне можно избежать, проверив на ноль заранее, прежде чем делить, но нахрена в процессор закладывать схемы, которые никогда не используются?
> RISC вообще недружелюбны к любителям писать программы в машинном коде.Мнение полного профана в вопросе. Ты вообще на ассемблере программировать умеешь? Посмотри на ARMовский ассемблер, например. Только стоит честно предупредить: попробовав это врядли ты захочешь когда-нибудь еще програмить для x86. Классная, симметричная система команд, нормальные режимы адресации, крутой компактный и эффективный код без сложного декодера. Вот это - работа настоящих профессионалов.
RISCV немного более дурацкий: из-за излишней академичности авторов они были не везде в курсе проблем реального мира, а ЧСВ не позволило им посмотреть на то что сделали другие. Поэтому бутануть cortex-M одними сями - легко. А вот RISCV таки все же потребует небольшой но все же асмовый стартап, увы и ах.
> Хочешь писать в машинном коде, пиши под 8086, или под PDP-11. Там хорошо получается.
Попробовав програмить под ARM прогать под х86 нормальному ассемлерщику немедленно расхочется. Потому что все познается в сравнении. И это древнее легаси обвешаное костылями не выдерживает никакого сравнения с современным аккуратным ядром сделаным теми кому надо чтобы его у них еще и лицензировал бы кто-нибудь, в отличие от интела.
Самое логичное описание ARM: если x86 это такой потомок 8080, то ARM - потомок 6502. Крутой и правильный потомок. Пример того как его надо было делать с самого начала.
>> RISC вообще недружелюбны к любителям писать программы в машинном коде.
> Мнение полного профана в вопросе.Ох, тут анонимный специалист нарисовался? Наконец-то. А то как не глянешь вокруг, никто из анонимов не понимает, о чём пишет.
> Ты вообще на ассемблере программировать умеешь?
А почему вы спг’ашиваете?
> Посмотри на ARMовский ассемблер, например.
Чё на него смотреть? RISC как RISC. С этой дурацкой манерой выполнять операции исключительно над регистрами, необходимостью в две-три команды грузить полное значение регистра из immediate операнда. На это похрен, когда этим компилятор занимается, но вручную я этим заниматься не буду.
> Только стоит честно предупредить: попробовав это врядли
> ты захочешь когда-нибудь еще програмить для x86.Хаха.
> Классная, симметричная система команд,
> нормальные режимы адресации, крутой компактный и эффективный код без сложного декодера.
> Вот это - работа настоящих профессионалов.Ну вот у RISC-V декодер ещё проще. Плюс система команд разработана с мыслью о том, что команды конвееризировать, и что конвееров может быть больше одного.
> RISCV немного более дурацкий: из-за излишней академичности авторов они были не везде
> в курсе проблем реального мира, а ЧСВ не позволило им посмотреть
> на то что сделали другие.Как раз они были в курсе, и о всех этих зависимостях по данным, и тех костылях, которыми надо подпирать флаги, чтобы переупорядочив команды эмулировать то самое поведение, как будто в процессоре есть один физический регистр флагов, и что инструкции выполняются последовательно.
> Поэтому бутануть cortex-M одними сями -
> легко. А вот RISCV таки все же потребует небольшой но все
> же асмовый стартап, увы и ах.Ты так говоришь, будто это что-то плохое.
> никто из анонимов не понимает, о чём пишет.Тот Аноним прогал на штуках пяти разных ассемблерах. И x86 был наиболее блевотным из таковых, хуже ассемблер вообще наверное только PIC. Но там это простительно за то что этот таракан делается на ископаемом оборудовании (чуть не 1u) и поэтому отсыпается по цене кремния и пластмассы из которых состоит, с очень маргинальной накруткой.
> А почему вы спг’ашиваете?
А потому что есть подозрения насчет титиретиков.
> Чё на него смотреть? RISC как RISC.
Большинство тех кто развлекается програмингом на асме ссали после совета на него посмотреть кипятком. Ну вот прикольная штука. Логичная, симметричная, набор команд не тупой.
> С этой дурацкой манерой выполнять операции исключительно над регистрами,
А все потому что это - просто и быстро. Изначальный x86 вообще убл*док редкий, в этой фекалии position-independent код вообще нельзя толком сделать, адовые костыли с релокациями, совершенно кретинская адресация и полтора регистра на все, так что программа состоит из пушпопов чуть менее чем полностью.
В x86-64 стало немного получше - но таки голимый костыль над легаси уродцем, это уж точно не являет собой state of art процессорных ядер и наборов команд. Всего лишь попытки сделать из антика хоть какое-то подобие современного проца. Довольно жалкое.
> необходимостью в две-три команды грузить полное значение регистра из immediate операнда.
1) Современные компилеры умеют нехило кешировать и глобально оптимизировать это дело. Благо регистров - есть. А прикинь, gcc оформляет сплев бита в GPIO чуть не парой команд, ты и на голом асме лучше хрен напишешь. А на х86 это действо... хм... там вообще ничего такого способного за пару циклов лапой дернуть не бывало вроде никогда и никак. И эти люди быкуют на ARM? :P
2) Если ассемблерщик так не умеет - на кой черт он вообще нужен?
3) Кроме immediate, видите ли, грузить можно еще [r] и [r+off]. И даже инкретменты всякие бывают. Опять же - gcc в этом плане поумнее "типа-ассемблерщиков" бывает. Оформив кучу констант блоком, вгрузив его базу в какой-нибудь регистр и танцуя от него смещениями. Ну да, это немного иной стиль програмизма, но он вообще совсем ничем таким не плох, тем более что при серьезном замахе на такое - асм сам может смещения по символическим лэйблам считать.> На это похрен, когда этим компилятор занимается, но вручную я этим заниматься не буду.
На самом деле оно и вручную неплохо получается. К тому же если хотелось автоматики и проч - ну, компилер ее и сделает. И кстати довольно оптимально для такой архитектуры, кодогенерация у того же gcc на редкость приличная в случаях когда это может быть интересно.
>> ты захочешь когда-нибудь еще програмить для x86.
> Хаха.Как минимум, у ARM нормальная модель памяти и логичные адресации используя регистров а не дикое ушлепанство с сегментами которое придумывал какой-то наркоман, а потом обезьянили до упора.
> Ну вот у RISC-V декодер ещё проще.
Спорный вопрос. Скажем Cortex-M0 - одно из самых мелких процессорных ядер, кристалл мизерный. Правда и набор команд за это обрублен, условные команды (IT + порция команд) обкушены. Это все же нагибает эффективность кода уже. Кстати, thumb2 весьма эффективный набор команд, а для простого декодера так и есть state of art. Сделать вот ЭТО без ucode rom - вот так и видно кто профи, а кто углы срезает, как интел по жизни. Впрочем досрезались с своими спектрами мельдониевыми, желаю им обанкротиться нахрен. Давно заслужили за такую "инженерию", где маркетинг сожрал здравый смысл.
> Плюс система команд разработана с мыслью о том, что команды конвееризировать,
> и что конвееров может быть больше одного.С другой стороны - не особо продумано насчет микроконтроллеров и проч где суперскорость нафиг не надо, надо максимальную предсказуемость по времянкам. И вот тут простой и быстрый набор команд оказывается EPIC WIN-ом. Ну они и захватили рынок, основательно поперев 8-битники.
У ARM есть разные варианты ядер - от микроконтроллеров до серверов. А прикольно в этом то что система команд более-менее одна и та же. Ну и за все эти конвееры и проч расплатами уязвимости и потеря предсказуемости. Где-то с этим можно жить, а где-то нет.
> Как раз они были в курсе, и о всех этих зависимостях по данным, и тех костылях,
> которыми надо подпирать флаги, чтобы переупорядочив команды
> эмулировать то самое поведение, как будто в процессоре есть один физический
> регистр флагов, и что инструкции выполняются последовательно.Они были слишком однобокие и не учли некоторые системные моменты. Переклинившись на конкретных юзкейсах но не имея внятного гранд-плана. По поводу чего гораздо тухлее смотрятся в реалтаймных системах и микроконтроллерах. Давай расскажи как это не надо, а надо сраные сервер с котиками. А то на чем вся планета держится пусть, дескать, нвидия нагибает. Логика хомяка, которому "и хрен с поездами, лишь бы котики с вконтача грузились".
>> Поэтому бутануть cortex-M одними сями - легко. А вот RISCV таки все же потребует
>> небольшой но все же асмовый стартап, увы и ах.
> Ты так говоришь, будто это что-то плохое.Да, я считаю что написать фирмаварь на си без единого бита асма - это прикольно придумали. Правда, в паре мест - только подумайте - тоже наследие легаси - и они таки тоже протупили.
> С другой стороны - не особо продумано насчет микроконтроллеров и проч где
> суперскорость нафиг не надо, надо максимальную предсказуемость по времянкам. И вот
> тут простой и быстрый набор команд оказывается EPIC WIN-ом. Ну они
> и захватили рынок, основательно поперев 8-битники.RISC-V -- открытая архитектура. Не нужна суперскалярность, нарисуй себе RISC-V без суперскалярности.
Консенсус на HN, если почитать комментарии: RISC-V займёт нишку "встраиваемых" ядер. В частности и тех, где предсказуемость в большем приоритете нежели производительность. В качестве CPU у нас будет ARM, а вот всякие "сопроцессоры", контроллеры и прочие будут под RISC-V. Я не уверен, что я согласен с этим, но с другой стороны не думаю, что правильно было бы заигнорить это мнение.
> У ARM есть разные варианты ядер - от микроконтроллеров до серверов. А
> прикольно в этом то что система команд более-менее одна и та
> же. Ну и за все эти конвееры и проч расплатами уязвимости
> и потеря предсказуемости. Где-то с этим можно жить, а где-то нет.В RISC-V это решается более грамотно. Собирая себе процессор, ты выбираешь какие части системы команд он будет поддерживать. Блоками. Вот теми блоками, как они в спецификациях описаны.
> Они были слишком однобокие и не учли некоторые системные моменты. Переклинившись на
> конкретных юзкейсах но не имея внятного гранд-плана.Да. Я почти о том же. Единственное отличие, я не склонен их винить в этом: они разрабатывали ARM ещё до того, как суперскалярность и out-of-order execution вошли в моду.
>>> Поэтому бутануть cortex-M одними сями - легко. А вот RISCV таки все же потребует
>>> небольшой но все же асмовый стартап, увы и ах.
>> Ты так говоришь, будто это что-то плохое.
> Да, я считаю что написать фирмаварь на си без единого бита асма
> - это прикольно придумали. Правда, в паре мест - только подумайте
> - тоже наследие легаси - и они таки тоже протупили.Ну а мне как-то совершенно фиолетово. До тысячи строк ассемблерного кода -- это такая штука, которую легко можно поддерживать. Можно хоть переписать с нуля, если что. Даже если система команд не нравится. На такой кодобазе бонусы всяких там C мало сказываются. Если вообще сказываются.
> нарисуй себе ... Собирая себе ...Вот и получается, что проще сразу сделать свой проц, чем торкаться с риск-в.
>> нарисуй себе ... Собирая себе ...
> Вот и получается, что проще сразу сделать свой проц, чем торкаться с
> риск-в.Ты забываешь про:
1. github, откуда ты можешь таскать готовый verilog. Плюс к этому прилагается куча опыта тех, кто уже нарисовал, то есть если ты захочешь нарисовать свой с нуля, ты сможешь за неделю-две узнать где лежат грабли, почитав других, и обойти их.
2. Тулчейны. Под свой проц придётся попыхтеть, под risc-v ты можешь взять любой компилятор на llvm (и возможно gcc), и использовать его, лишь передав ему флагов, говорящих о том, какие блоки системы команд доступны в процессоре.
> Вот и получается, что проще сразу сделать свой проц, чем торкаться с риск-в.Так много процов то понаделали, если это проще? А то кучка SoC с RISCV которые уже выпускаются или на грани этого вон там по ссылкам рядом с новостью на краудсаппли без проблем.
А вы там есть? И если да - как у вас с поддержкой линукса? Опенсорсными бутлоадерами и поддержкой системы команд gcc? А то может мне и вам тоже денег насыпать? А если вы хотели сказать что у вас всего этого нет - ну тогда вы и денег с меня ни копья не получите. Вот такой простой и понятный любому комерсу аргумент. С моей стороны запрос на вот такой фичесет. Кто ему соответствует - получает мои бабки.
> RISC-V -- открытая архитектура. Не нужна суперскалярность,
> нарисуй себе RISC-V без суперскалярности.Ну так в систему команд оно и не вхаркожено особо. И таки нарисовали и такие реализации тоже. А козыряя "типа фичой" стоит понимать что в половине случаев фича легко превращается в жирный баг. И крутизна ARM в том что они смогли все это избежать, ухитрившись сделать какую-никукую консистентность системы команд при нефиговой масштабируемости.
> Консенсус на HN, если почитать комментарии: RISC-V займёт нишку "встраиваемых" ядер.
К этому есть сильные предпосылки.
> В частности и тех, где предсказуемость в большем приоритете нежели производительность.
Он, в принципе, может - потому что нвидия выбора особо и не оставила. Никто не потерпит прямого конкурента как лицензиара ядер. Равно как нвидия не знает специфику области и экосистемы МК и уж куда как враждебнее к девам чем ARM сейчас.
Но мы же про заточенность ядра? И вот в RISCV как таковой не имеет никаких особых козырей для управляющих систем. Cortex-M были несколько адаптированы, чтобы делать это удобно. В RISCV это никто не делал. Ну вот не были его авторы вхожи в это и не в курсе как real-world применения выглядят.
Если ARM coretex M вызывает "вау, как клево, аккуратно, продумано и удобно" то RISCV - ну, обычное "искусство" рядового мясника. Там правда фирма ARM много интересных фокусов запатентовала, не отнять.
> В качестве CPU у нас будет ARM, а вот всякие "сопроцессоры", контроллеры
> и прочие будут под RISC-V.С учетом покупки ARM nvidia это уже вообще не факт. Как вы представляете себе лицензирование крутых ARMов прямым конкурентам нвидии? Вот жизнь и не оставила им выбора кроме как развивать что-нибудь еще. А другого не так уж много, 64-битные версии RISCV с расширениями не так уж далеко от cortex-A. И вон та штука с pcie под видяху - про вон то самое уже.
А в микроконтроллере столько - не надо! Там от этого один вред. Пока там 32-битных ядер всем за глаза, от 64 только код пухлый, а памяти и близко не 2^32. Накристальный NOR дорого стоит, площадь кристалла сильно жрет. И тонкий техпроцесс для МК же баг а не фича, хлипкий чип получается. Что хреново для управляющих систем, потом 20 лет ГАРАНТИИ сохранности фирмвары в флеше, при +105 желаемых автомотивщиками - ну, ой. А, представляете, это паяют куда попало, в том числе и в то что жарится у вас под капотом. И как вы понимаете, 7 нм NAND при +105 утечет быстрее поросячьего визга, юзер получит встрявшее на дороге авто, спасибо если не впечатавшееся в соседа, и кому оно в таком виде будет надо?
> Я не уверен, что я согласен с этим, но с другой стороны не думаю, что правильно было
> бы заигнорить это мнение.На этой планете довольно много тех кто не прочь забить гвоздь микроскопом. Но вообще логичнее наоборот: нвидия точно будет душиться жабой на апликушные тяжеловесы, т.к. сами не прочь в этом сегменте потусоваться, а микроконтроллерная мелочь по жизни не их бизнес и там нет особого конфликта интересов. Но они в область не вхожи и обречены наломать дров.
> В RISC-V это решается более грамотно. Собирая себе процессор, ты выбираешь какие
> части системы команд он будет поддерживать. Блоками.Ну так ARM и сделал примерно так же, только логичнее и тематичнее, с осмысленной разблюдовкой под задачи а не сферически-абстрактной модульностью в вакууме. Которая к тому же создает проблемы с совместимостью.
> Вот теми блоками, как они в спецификациях описаны.
Ну да. Однако вот именно нормальной спецификации "для микроконтроллеров" там как таковой и нет. Поэтому в целом оно на задачу похуже Cortex M от арм ложится, особенно в low end где больше жесткого реалтайма и предсказуемости и меньше мегагерцев с гигабайтами, потому что там не в этом счастье. А в том чтобы на вон тот раздражитель за наносекунды что-то сделать - и без дикого джиттера (привет кэшам и проч). А кому там нужна дерганая непредсказуемая система, которая вот так в дедлайн укладывается, а вот так - лажает? Реальное время ждать не будет, и если это вопрос в том не #$%нет ли что-нибудь от этого - сие уже аргумент. По этому поводу пики и авр до сих пор живые. Они тупы как дрова, но вот *ГАРАНТИРОВАННОЕ* время реакции на событие считается с точностью швейцарских часов, потактово, и даже жалкие 10 МГц просчитанные потактово - оперирование квантами времени по 100 наносекунд. А когда у тебя толи 10 наносекунд, толи 200, смотря hit оно там или miss, так уже не катит. И вот тут мелкий уродец пик воткнет жирному апликушному процу как делать нефиг. По поводу чего и выпускается до сих пор, хоть и не стоит добрых слов по архитектуре.
> Да. Я почти о том же. Единственное отличие, я не склонен их
> винить в этом: они разрабатывали ARM ещё до того, как суперскалярность
> и out-of-order execution вошли в моду.Это про RISCV было. Фирма ARM доперла сделать "профайлы" под "задачи", логично сгруппированые, и даже частично отбросив легаси. Это было эпиквином, абстрактные блоки - несколько менее об этом. Какую-то адаптивность под задачу получить можно но в целом кривее и неудобнее. Так что ARM - state of art, RISCV - такой art как мясник с топором супротив шефповара. Но если вопрос в том что шефповар шашлык сам сожрет, народ и на мясника согласен.
> Ну а мне как-то совершенно фиолетово.
Я могу с этим жить, но симпатий к процессорному ядру это не добавляет. После ARM это ощущается как даунгрейд и легаси. А почему, собственно, хоть к 2020 нельзя бы сделать проц удобный системщикам? Особенно когда ARM все это смогли?
> До тысячи строк ассемблерного кода -- это такая штука, которую легко можно поддерживать.
Да как сказать? Если ты не писал этот код, удовольствие одуплять в 1000 строк этого счастья довольно так себе. Си все же может быть сильно декларативнее на тему того что и нафига тут происходит. И какой-нибудь pll_reclock(100, 200) будет информативнее того как это на асме будет. Особенно ежели рантайм параметры захотеть. При том что си можно убедить стать очень тонким shim над железкой, когда код будет тот же как я сам бы сделал, или лучше (глобальные оптимизации в 1К команд я вероятно прошляплю).
> Можно хоть переписать с нуля, если что. Даже если система команд не нравится. На такой
> кодобазе бонусы всяких там C мало сказываются. Если вообще сказываются.Можно. Но в целом это оказывается такой кусок кода который никто предпочитает не трогать. Потому что кус черной магии, в которую надо непропорционально долго вкуривать. И допереть по этой кучке россыпи что это pll_reclock(100, 200) довольно неудобно. Хоть и делается.
> Тот Аноним прогал на штуках пяти разных ассемблерах. И x86 был наиболее
> блевотным из таковыхБлевотный какой-то аноним.
Если рейтинговать по блевотности, то в лидеры скорее выбьется как раз таки обожаемый ARM.
> Если рейтинговать по блевотности, то в лидеры скорее выбьется как раз таки
> обожаемый ARM.Его в отличие от интела делали профессионалы, а не маркетологи, до последнего камлавшие на свой win32'tel убогий, происходящий из эпохи когда каждый транзистор был на счету, так что убогий регистровый файл имел хоть какое-то оправдание. Но это закончилось 20+ лет назад, и уж выделить транзисторов на нормальный набор регистров и человесческую адресацию наверное все-таки уже можно. И было уже можно четверть века назад. ARM об этом догадался - и не интелу учить их транзисторы экономить, кстати :)
Ну ладно Acorn, VLSI - тут да. Но свежак то после...Apple
ИнженерыБлеванул.
> Ну ладно Acorn, VLSI - тут да. Но свежак то после...По сравнению с Acorn'овскими - Cortex'ы как летающий делореан супротив винтажных драндулетов. Клевые, логичные, продуманые ядра. Где легаси эпохи акорнов немного повытрясли и как раз сделали как логичнее, удобнее и лучше работает, а не что-нибудь еще. А будучи инженерами а не маркетологами еще и придумали как сделать все это компактно и эффективно. Иначе кто бы в здравом уме это у них лицензировал?!
> Apple
> Инженеры
> Блеванул."Эксперт" походу ваще не читает тематические новости и не в курсе что эти дезигнеры между делом сманили у ряда кондовых чипмейкеров типа амд и интеля инженеров процессорного направления. А таки да, теперь ябл может и довольно глубокий дизайн чипов сам. И самсуня они таки послали с этим, теперь это уже не малость допиленый заказной exynos а вполне себе свои чипы.
> больше простора компилятору для оптимизацийВся проблема RISC в том, что там нет рантайм-оптимизации. Которая вполне себе есть в CISCoRISC'ах.
Она просто невозможна потому, что компилятор ничего не знает о входных данных, которые коду придут в каждую конкретную единицу времени.
> Вся проблема RISC в том, что там нет рантайм-оптимизации. Которая вполне себе
> есть в CISCoRISC'ах.Интел своими мельдониевыми оптимизациями уже несколько подзаколебал. Понасрезали углов везде где можно и нельзя, а как исследователи потыкали палочкой так и оказалось что это не чипы а сплошной багодром. Где вся система разваливается от безобидных непривилегированных фокусов программ.
Вот это - не инженеры. Это - жулики от маркетинга. И с TDP у интелья отродясь та же история.
> Она просто невозможна потому, что компилятор ничего не знает о входных данных,
> которые коду придут в каждую конкретную единицу времени.Компилятор отлично в курсе аргументов функции, допустим. А то что интель там пытается спекулировать - блин, доспекулировались, undo спекуляций глюкав донельзя получился.
Компилятор вообще ничего не знает о том, какие аргументы в эту функцию придут, если они не статические.
В этом и вся проблема.
> Компилятор вообще ничего не знает о том, какие аргументы в эту функцию
> придут, если они не статические.А что в вашем понимании - не статические? А то в большинстве случаев они как раз именно такие. Нет, ну при желании variadic сделать можно, но вот это уже малость экзотика.
И как угодно но я смотрел что gcc для cortex M делает и там вполне зачетный код. А с глобальными оптимизациями типа LTO он временами очень лихо заворачивает, так что ассемблерщик то не сразу допрет так выпендриться.
> В этом и вся проблема.
Хызы, куча ARMов у меня уже работают и никаких особых проблем я по этой части не имею. Больше всего у меня проблем с x86 системами, радующими глюками проприетарной фирмвари и прочих acpi вокруг. Отделаться от этого "счастья" очень хочется. И платить за ME и PSP из своего кармана мне "религия не позволяет", если так угодно. Я лучше эти деньги отдам стартаперу который направление открытых и опенсорс френдли систем раскручивает чем о...вшему в край мегакорпу удумавшему мне бэкдоры за мои бабки всучивать.
А так - рассуждения о сферических конях в вакууме не решают мои насущные проблемы. И проц каким бы он крутым не был ничто без экосистемы. Приветы итанику. Сам то дизайн может и ничего, если не считать оверинженерии, как всегда у интеля. Но вот с софтовой экосистемой вышел большой облом. Ну как бы если процы стоят килобаксы, а софта нет - их и девы не больно побегут покупать. Получится infinte loop.
> А что в вашем понимании - не статические? А то в большинстве
> случаев они как раз именно такие.То есть у вас все вызовы функций с константами? Никакого пользовательского ввода?
Ну там processMyData(2, 5, 'ohmygod')?
Везёт :DВ реальном мире же в основном аргументы приходят из пользовательского ввода, с сети, с файлов и т.п.
Они заранее не известны. Соответственно компилятор не может предсказать, что будет на входе того или иного участка кода в тот или иной момент. Финальную оптимизацию разных условий делает именно что планировщик CISC в сложных CPU. Ну а простым RISC приходится перетаптываться - в синтетических бенчмарках и на отдельных хорошо оптимизируемых без конвееров алгоритмах они как правило выдают прекрасные цифры, в реальных задачах - начинают сливать, потому что выполнение реального кода получается куда менее оптимальным.
> То есть у вас все вызовы функций с константами? Никакого пользовательского ввода?И тем не менее, ABI у ARM по сравнению с 32-битным x86 вообще masterpiece. С x86-64 уже менее однозначно, но скелеты в этом шкафу до сих пор пинаются и архитектура все-равно мерзотненькая по наследству.
> В реальном мире же в основном аргументы приходят из пользовательского ввода, с
> сети, с файлов и т.п.Это никак не мешает особо. Ну вон ARM64 на древнем девайсе спокойно жует VP9 с ютуба 1080p софтварно. А то что у интеля гигантомания - задолбали уже. Их power management дико невменяем и переусложнен, а толку с него буй. Bullshit bingo!
> Они заранее не известны. Соответственно компилятор не может предсказать, что будет на
> входе того или иного участка кода в тот или иной момент.И хрен с ним учитывая что все команды простые и быстрые, оно мигом вертухается в нужную сторону в отличе от CISCового слоупока.
> Финальную оптимизацию разных условий делает именно что планировщик CISC в сложных CPU.
У RISC половины таких проблем нет сразу на старте - они сильно быстрее вертухаются в новую сторону. К тому же продвинутые жирные ядра могут и спекулятивщину и префетч практиковать, вообще совсем ничему не противоречит.
> Ну а простым RISC приходится перетаптываться - в синтетических бенчмарках
> и на отдельных хорошо оптимизируемых без конвееров алгоритмах они как правило
> выдают прекрасные цифры, в реальных задачах - начинают сливать, потому что
> выполнение реального кода получается куда менее оптимальным.Для меня игра древним ARM64 1080p на ютубе - вполне себе нормальный бенчмарк на real world данных. И с чего бы RISC64 с simd на сравнимой частоте это бы сливал при сравнимой частоте с такой же или более быстрой памятью я хз.
Ну и имхо интель может пойти с своими зионами курить бамбук. Кто это от ARM хотел - набили жирных ядер да побольше, при том их поболее х86 в тот же TDP и площадь влазит, и суммарный перфоманс вполне себе. А интеловские бзики по переросткам с мельдонием лично мне уже просто надоели. Иногда фирма интел бывает иррациональна и уперта донельзя. Ее уже даже эппл послал, видимо "батарейки для часов" и непотребные цены и TDP им надоели.
>> больше простора компилятору для оптимизаций
> Вся проблема RISC в том, что там нет рантайм-оптимизации. Которая вполне себе
> есть в CISCoRISC'ах.Что это значит, ты можешь объяснить? Можешь привести пример ситуации, в которой то, что ты называешь "рантайм-оптимизацией" дало бы возможности выполнять код быстрее, чем тот же код скомпилированный для risc-v?
Может быть я чего-то не понимаю, но склоняюсь к мысли, что не понимаешь ты. Рантайм оптимизация строится вокруг параллельного выполнения команд во многих конвеерах, идея в том, чтобы иметь много исполняющих устройств для каких-то элементарных операций, и потом максимально загружать эти исполняющие устройства работой в рантайме. Но если ты присмотришься, то ты увидишь, что во-первых, для того, чтобы это работало приемлимо нужны костыли типа branch-prediction или out-of-order-execution, которые потребляют ватты и занимают драгоценные транзисторы, во-вторых, существенная часть работы выполняется в компайл-тайме компилятором, который, зная алгоритмы этой рантайм "оптимизации", подбирает инструкции и располагает их так, чтобы они нужным образом разложились бы по конвеерам, а потом по исполняющим устройствам. Втыкает, например, nop'ов, чтобы занять чем-нибудь конвеер, чтобы тот не воткнулся в бранчевание не вовремя и не сбросился бы. Или скажем атрибут unlikely для условия -- это же подсказка компилятору как расположить в памяти бранчи, дабы рантайм "оптимизация" не спотыкалась бы на этом условии. Или PGO -- топовое достижение "рантайм оптимизации": давайте соберём профайлером данные о том, как выполняется код, а потом скомпилируем его так, чтобы он хорошо "оптимизировался" бы в рантайме.
Последняя фраза не вызывает когнитивного диссонанса? Рантайм оптимизация в компайл-тайме -- как тебе?
Дык может рантайм-оптимизация и не нужна, если процессор изначально спроектирован с мыслью о том, что команды будут выполнятся во много этапов на конвеере, и что таких конвееров будет много? Может можно сэкономить на всех этих сложнейших декодерах команд и рантайм-оптимизаторах, а сэкономленные транзисторы потратить на то, чтобы на тот же кристалл в полтора раза больше ядер воткнуть?
Именно так. OOO, предсказание переходов, спекулятивное выполнение.
На уровне компилятора это НЕ делается.
Хоть с likely, хоть с unlikely, хоть с highly likely.
Потому что реальные данные известны только на момент выполнения, соответственно и результат кондишнла.
> Именно так. OOO, предсказание переходов, спекулятивное выполнение.
> На уровне компилятора это НЕ делается.
> Хоть с likely, хоть с unlikely, хоть с highly likely.
> Потому что реальные данные известны только на момент выполнения, соответственно и результат
> кондишнла.Глупости. Процессор знаешь как делает? Он декодирует инструкцию условного перехода, он не может её выполнить сразу, потому что FLAGS ещё не готовы, чтобы знать как её выполнять, поэтому он делает "предсказание", сводящееся к следующему:
если условный переход имеет отрицательный аргумент (смещение в байтах которое надо приплюсовать к текущему значению IP -- instruction pointer), то он выполнится, если переход с положительным аргументом, то он не выполнится.
Вот и всё ясновидение в CPU. Оно заточено под циклы, которые как правило заканчиваются инструкцией "jnz my_loop" или типа того: поскольку переход выполняется в сторону меньших адресов, то аргумент к jnz оказывается отрицательным, и поэтому процессор его "предсказывает" как выполняющийся, и спекулятивно начинает выполнять тело цикла ещё раз, до того, как посчитает условие, которое выставит флаги для jnz.
Переход вперёд рассматривается как unlikely, зачем-то. Я предполагаю, для того, чтобы была возможность оптимизировать unlikely переходы под этот тупой предсказатель, без инверсии условия, которая требует ещё одной команды.
likely/unlikely лишь располагает ветви if'а таким образом, чтобы likely переход выполнялся бы назад, а unlikely вперёд. То есть _оптимизация_ происходит в compile-time, код располагается таким образом, чтобы "предсказания" процессора были бы верными.
> Как только встретился кондишнл - всё, нет больше конвеера, ждём да/нет/не знаю (чёрный юмор) от такового.
Нет, не ждём, а включаем предсказания и спекулятивное выполнение.
> Потому что реальные данные известны только на момент выполнения, соответственно и результат кондишнла.
Реальные данные могут изменить лишь то, что unlikely переходы иногда всё же выполняются, а likely иногда не выполняются, и в таком случае предсказания процессора оказываются неверными и все результаты достигнутые в результате спекулятивного выполнения надо выкинуть. Скажем любой цикл (где в конце тела есть условный переход назад, на начало цикла) приводит к одному misprediction, к одному сфейлившемуся предсказанию, которым собственно цикл заканчивается. Единственный способ избежать этого -- отправить на выполнение вычисление условия продолжения цикла до того, как на выполнение ушло тело цикла, тогда есть шансы, что когда процессор доберётся до команды условного перехода, условие уже будет посчитано, и тогда процессору не придётся полагаться на свои предсказания. Но для того, чтобы это работало, придётся результаты расчётов условия хранить не в регистре FLAGS, который глобальный для всех команд, и который будет перезаписан командами тела цикла, а в каком-нибудь другом регистре.
upd. Глупость сморозил: "предполагаю, для того, чтобы была возможность оптимизировать unlikely переходы под этот тупой предсказатель, без инверсии условия, которая требует ещё одной команды". Там не нужна ещё одна команда, можно инвертировать условие команды условного перехода. То есть я вообще без идей, зачем это надо.
> Глупости. Процессор знаешь как делает? Он декодирует инструкцию условного перехода, он не может её выполнить сразуКондишнлы внезапно - это не только переходы. Даже банальный сдвиг на бит с использованием флага переноса является кондишнлом. Не говоря уже о специализированных инструкциях типа CMOVxx в x86. При работе того же сдвига и наличии далее зависимой от него команды - возникают две ветки исполнения.
Проц со спекулятивным исполнением вполне способен протрассировать обе, если ресурсов свободных хватит, и сбросить не нужную после появления реальных данных, а вот RISC придётся стоять и ждать флага. Потому что реальные входные данные на момент исполнения сдвига ещё не известны, и компилятор далее в параллель с ним ничего зависимого расставить уже не сможет.
> Нет, не ждём, а включаем предсказания и спекулятивное выполнение.
Нет у RISC спекулятивного выполнения. На то он и RISC. И предсказатели переходов сложные не могут возникнуть - неоткуда.
Это прерогатива CISCoRISC, которые могут разложить инструкции на конвеер, выбрать свободные регистры, протегировать, и запустить на хорошо известном планировщику RISC-ядре в параллель.
> Реальные данные могут изменить лишь то, что unlikely переходы
Повторюсь. Кондишнлы - это не только переходы. Нет, в RISC - в основном, и это как раз та причина, по которой они не взлетают в реальных условиях.
Да что там блин далеко ходить.
Сложение с переносом банальное - кондишнл.Псевдокод (целевой аргумент - левый):
ADD v,w
ADC x,y
MOV [mem],xВсё. RISC вот этот вот примитив будет в линеечку выполнять, и никак иначе.
Хотя как минимум ADC вполне можно спекулятивно запустить.
> Да что там блин далеко ходить.
> Сложение с переносом банальное - кондишнл.
> Псевдокод (целевой аргумент - левый):
> ADD v,w
> ADC x,y
> MOV [mem],x
> Всё. RISC вот этот вот примитив будет в линеечку выполнять, и никак
> иначе.
> Хотя как минимум ADC вполне можно спекулятивно запустить.Как ADC запустить, когда там зависимость по данным? На двух исполнителях с разным carry и один из результатов отбросить?
Примерно это и делает планировщик в CISCoRISC'ах.
Ты можешь это попытаться делать в компилере - но нужна поддержка исполнительного железа. Которой нет.И это я тебя ещё в дебри не повёл. С промахом в кеш ты так легко уже компилером не разберёшься. А они тоже возникают по-разному, в зависимости от рантаймовых данных. Компилятор тут тебе не поможет ничем. А вот рантайм-планировщик - да. Он в это время попробует что-нибудь другое исполнить, если возможно.
> Примерно это и делает планировщик в CISCoRISC'ах.Почему же Вы не указали причины, по которым "примерно это" не может делать "планировщик" в "RISCoRISC"'ах?
Потому что исходный спектр команд достаточно куцый - на то он и RISC, и разбирается на более мелкие независимые операции весьма посредственно. Особенно извращённые комбо, которые тут приводили - группировка условий на целый блок команд и т.п.
> Потому что исходный спектр команд достаточно куцыйНайдите структурную схему процессора. Посмотрите, где там декодер и где ALU. Это разные блоки. К мантре "R в RISC означает религия" они отношения не имеют.
> R в RISC означает религияСпасибо. Я теперь знаю что ответить любому ратующему за RISC во все поля.
Заодно уточняйте, что Вам религия запрещает усложнять исполнительный блок, что бы не тратить время.
> Заодно уточняйте, что Вам религия запрещает усложнять исполнительный блок, что бы не
> тратить время.Ему запрещает. А фирме ARM или вон тем стартаперам с RISCV не запрещает. Поэтому мои бабки и получат они а не этот чудак.
> Проц со спекулятивным исполнением вполне способен протрассировать обе, если ресурсов свободных
> хватит, и сбросить не нужную после появления реальных данных, а вот
> RISC придётся стоять и ждать флага. Потому что реальные входные данные
> на момент исполнения сдвига ещё не известны, и компилятор далее в
> параллель с ним ничего зависимого расставить уже не сможет.Мне непонятно, что такого есть в RISC, что не позволит реализовать такое спекулятивное выполнение?
> Мне непонятно, что такого есть в RISCВыброси из себя оптимиста, и подумай, чего такого нет в RISC, в связи с чем такое выполнение плохо реализуемо.
(между делом, транзисторный бюджет у этого чего-то огромный внутри современных x86, и львиная доля высочайшей эффективности в совершенно разнородных задачах с плохой предсказуемостью именно им и обусловлена)
К RISC-V это некоторые пытаются присобачить, но в силу определённой прибитости гвоздями исходной архитектуры - а она не может быть не прибитой гвоздями, потому что иначе будет разброд и шатание - усилия пока немножко тщетны. На расширениях есть варианты, но это уже немножко не RISC-V получается, а её ни с чем не совместимая ветка.(я сознательно не конкретизирую детали - гуглите :) )
>> Мне непонятно, что такого есть в RISC
> Выброси из себя оптимиста, и подумай, чего такого нет в RISC, в
> связи с чем такое выполнение плохо реализуемо.Окей. Чего такого нет в RISC, что делает спекулятивное выполнение плохо реализуемым?
Полноценного планировщика операций нет. Весь пайплайнинг по сути ручной, ещё на этапе компиляции.
Просто потому, что основная прелесть RISC - как раз упрощение железного декодера и планировщика.
Да, для всякого перемножения матриц норм, где всё в кешах, и все операции предсказуемы.
Но на сложных конструкциях с кондишнлами и сильной зависимостью от входных данных всё - привет.
Малейший затык на том же пролёте с кешем - и очередь встаёт.Из исключений на слуху ныне наверное только ARM, но с ARM тема особая. Те же кортексы уже давно химера. Их даже RISC назвать уже язык не поворачивается. Там уже и кеш макроопераций появился, и обратная разбивка на сопряжённые микрооперации...
> Полноценного планировщика операций нет.А кто сказал что то что делает интель обязательно 1 хороший вариант?
> Весь пайплайнинг по сути ручной, ещё на этапе компиляции.
Как это мешает ядру трекать оба варианта бранча и префетчить потребные данные и проч?
> Просто потому, что основная прелесть RISC - как раз упрощение железного декодера и планировщика.
Это совершенно не мешает существовать разным реализациям одного и того же. Какой-нибудь A7 попроще, а A15 пожирнее. При том они совместимы. С 64-битными ядрами та же история. С RISCV аналогично. Вот так даже мк ок, а вот так это довольно жирный и шустрый 64-битник. Вы с вашим x86 переростком совсем не поняли что мир может быть не прибит на гвозди.
> Малейший затык на том же пролёте с кешем - и очередь встаёт.
Однако вон там нечто на ARM64 зарубается с EPYC. Да и RISCV свое не упустит.
> Из исключений на слуху ныне наверное только ARM, но с ARM тема
> особая. Те же кортексы уже давно химера. Их даже RISC назвать
> уже язык не поворачивается. Там уже и кеш макроопераций появился, и
> обратная разбивка на сопряжённые микрооперации...Опять же - ARM крут тем что на один набор команд есть разные реализации. Как и с RISCV. Есть большая разница между набором команд и конкретной реализацией ядра реализующего оный. В мире где более 1 implementer'а и конфигураций ядер это совершенно обычное дело.
Это кстати даже интел пробовал - в атомах. Но оказалось что ARM из них совсем никакой. И если ARM и RISCV на десктопах имеют какие-то шансы, то интель около 20 лет бредил tablet pc с нулевым успехом. И это жирная мегакорпа на минутку.
>> Просто потому, что основная прелесть RISC - как раз упрощение железного декодера и планировщика.
> Это совершенно не мешает существовать разным реализациям одного и того же. Какой-нибудь
> A7 попроще, а A15 пожирнее. При том они совместимы. С 64-битными
> Однако вон там нечто на ARM64 зарубается с EPYC. Да и RISCVТак я о том же, что "жирные" ARM'ы - это уже не RISC по сути, а химера, которая сначала RISC агрегирует в макрооперации, потом их назад бьёт до микроопераций уже ядра.
> Опять же - ARM крут тем что на один набор команд есть
Внезапно в x86 на один набор команд тоже есть разные реализации. Две основных и несколько мелких.
> из них совсем никакой. И если ARM и RISCV на десктопах
> имеют какие-то шансы, то интель около 20 лет бредил tablet pcRISCV на десктопах не имеет никаких шансов. От слова "совсем".
ARM - очень ограниченно, пока яббло играется с данной платформой.
> Так я о том же, что "жирные" ARM'ы - это уже не
> RISC по сути, а химера, которая сначала RISC агрегирует в макрооперации,
> потом их назад бьёт до микроопераций уже ядра.На третий день Зоркий Глаз заметил что деление на RISC и CISC ни разу не бинарное.
> Внезапно в x86 на один набор команд тоже есть разные реализации. Две
> основных и несколько мелких.Проблема в том что они кроме жирной реализации оказались бессмысленными и беспощадными, напомните, tabletPC уже отпраздновал 20 лет зафэйленых потуг или только собирается?
> RISCV на десктопах не имеет никаких шансов. От слова "совсем".
А вот это я уже на моем десктопе как-нибудь решу без вас.
> ARM - очень ограниченно, пока яббло играется с данной платформой.
Мне от ябла ничего не нужно.
> Полноценного планировщика операций нет. Весь пайплайнинг по сути ручной, ещё на этапе
> компиляции.Дык что мешает этот пайплайнинг запилить?
> Просто потому, что основная прелесть RISC - как раз упрощение железного декодера
> и планировщика.Ты думаешь, что если RISC-V имеет RISC в названии, то инженеры из уважения к этому названию не будут усложнять декодер и планировщик, запиливая туда спекулятивщину? Или я не правильно тебя понял?
Если же я понял правильно, то предлагаю забить на возможные идеологические причины и всё же рассматривать реальные технические причины того, почему в RISC-V невозможен сложный планировщик.
> Дык что мешает этот пайплайнинг запилить?Так же, как и с пресловутым танцором.
Вроде бы ничто не мешает - а погляди ж, они болтаются неудачно...> Ты думаешь, что если RISC-V имеет RISC в названии, то инженеры из
> уважения к этому названию не будут усложнять декодер и планировщик, запиливая
> туда спекулятивщину?Нет, я думаю, что это будет гораздо сложнее, чем построить таковые с CISC. Хотя бы в силу изначального размера команды в 32 бита сразу и относительной примитивности большинства этих команд. Придётся как в старших кортексах - сначала по заложенным паттернам мы конвертим этот RISC'овый бред в более удобоваримые для планирования макрооперации - ну, что удалось сконвертить, которые внезапно могут оказаться даже короче при записи, потом внезапно бьём это счастье назад уже на внутренние микрооперации для ядра, и только потом уже шедулим результат всей этой вакханалии. Естественно львиная доля шедулится без сбора в макрооперации, но это только дополнительно усложняет. Ещё немножко - и оно станет сложнее x86.
> Так же, как и с пресловутым танцором.Именно поэтому и есть жирные OoO реализации и ARM и RISCV.
- Ни один смертный муж не может убить меня!
- Я не муж, ха!
> Мне непонятно, что такого есть в RISC, что не позволит реализовать такое
> спекулятивное выполнение?Его даже и реализуют. Топовые армы и даже ранние RV64 даже налетели на какой-то подвид спектра, внезапно. Но омномномный эксперт по отрасли кажется не слышал о такой ерунде и с уверенным видом гонит аки олень.
Топовые армы RISC имеют только на фронтенде. Дальше жуткая химера. Посмотрите архитектуру уже.
> Топовые армы RISC имеют только на фронтенде. Дальше жуткая химера. Посмотрите архитектуру уже.Я то посмотрел, и в отличие от разогнавшегося оленя догадываюсь что деление на CISC и RISC не бинарное от слова вообще.
> Кондишнлы внезапно - это не только переходы. Даже банальный сдвиг на бит
> с использованием флага переноса является кондишнлом.У ARM с этим полный порядок например. У них очень круто сделано, в каком нибудь thumb2 возможны целые условные блоки с очень компактным кодированием условий на весь блок. В 32-бит условным может быть почти все угодно уже покомандово - это часть instruction set.
> Не говоря уже о специализированных инструкциях типа CMOVxx в x86. При работе того
> же сдвига и наличии далее зависимой от него команды - возникают две ветки исполнения.И как показал пример, утупки из интеля не умеют в undo side effects, так что безопасность лихо улетает во времена Win95. И фича резко превращается в баг.
> RISC придётся стоять и ждать флага.
Продвинутые hi-performance рисковые ядра тоже умеют спекулятивщину.
> Нет у RISC спекулятивного выполнения.
Зависит от реализации. Хотят ядро попроще и поменьше - нет. Хотят пожирнее и пошустрее - есть. "Ух ты, а что, так можно было?"
> На то он и RISC. И предсказатели переходов сложные не могут возникнуть - неоткуда.
А вот это уже на усмотрение implementer'а что он там сделает.
> Это прерогатива CISCoRISC, которые могут разложить инструкции на конвеер,
Вы уже утомили с своим vaporware. Вот вся отрасль тупая, один вы умный. Очень убедительно. Ну тогда обставьте этих лохов, не? Если вам верить это как 2 байта переслать.
> Повторюсь. Кондишнлы - это не только переходы. Нет, в RISC - в
> основном, и это как раз та причина, по которой они не взлетают в реальных условиях.Они уже мир захватили. Мобильных девайсов выпускается больше чем ваших x86 вместе взятых.
> Вы уже утомили с своим vaporware. Вот вся отрасль тупая, один вы
> умный. Очень убедительно.Ну поспорьте с x86 тогда, что-ли. На котором именно что сидит "вся отрасль".
Уделом ARM'ов так и остаётся мобильный сегмент, где чистая производительность не важна и не интересна.
И всякая эмбедовка, где оно в основном в качестве спящей системы управления.
Даже RP на магистральных роутерах ушли с MIPS/ARM/whatever на x86, к чему бы это, не подскажете? :D
Просто внезапно на эти RP нагрузка стала жёсткая...
Для чистоты скажем, что на ARM конечно можно и суперкомпьютер слепить. Под конкретную задачу, где он применим. Но универсальности по производительности там не было и не будет.
> Для чистоты скажем, что на ARM конечно можно и суперкомпьютер слепить.И даже слепили, насколько я помню.
> Ну поспорьте с x86 тогда, что-ли.Где именно? Так то вон 80-ядерный монстр за $4k c EPYC'ом спорит вроде. И по скорости, и по ценам.
> На котором именно что сидит "вся отрасль".
Которая именно?
- Мобильные системы на ARM давно. Отдельные приветы таблет-ПЦу.
- МК опять же ARM в основном, немного 8-бит, RISCV стал появляться.> Уделом ARM'ов так и остаётся мобильный сегмент, где чистая производительность не важна
> и не интересна.И всякая эмбедовка, где оно в основном в качестве спящей системы управления.Может спящей, может не спящей. Зачем мне спать если я мотор кручу? Электричества вокруг завались, реалтайм отклик важен, а пара милливаттов на фоне мотора никому погоду не делает.
> Даже RP на магистральных роутерах ушли с MIPS/ARM/whatever на x86, к чему
> бы это, не подскажете? :DДа кто его знает про какие вы там частности. Так то полно дизайнов энтерпрайз добра на чем угодно и x86 там совсем не в фаворе, просто потому что под него систему дизайнить - занятие проблемное и безблагодатное в общем случае.
> Просто внезапно на эти RP нагрузка стала жёсткая...
Это очень незначительный процент цифровых систем на планете.
Ну и да, какого конвеера-то?
Как только встретился кондишнл - всё, нет больше конвеера, ждём да/нет/не знаю (чёрный юмор) от такового.
> Ну и да, какого конвеера-то?Такого, который даже у простых RISC бывает. А у более сложных реализаций ядер и подавно.
> Как только встретился кондишнл - всё, нет больше конвеера, ждём да/нет/не знаю
> (чёрный юмор) от такового.Вам никогда не приходило в бошку что деление на CISC и RISC ни разу не черно-белое и между 2 полюсами полно опций? И формально заявленый набор команд и фактическая реализация железа ворочающего ее - разные вещи.
Ну вон ARM cortex M умеет быть neuman в железе и софте. Или neuman в софте но гарвард с ibus и dbus в железе. Софту сие однако ж никак не видно и это эпиквин: скорость гарварда без долботни с адресными пространствами и ограничениями гарварда.
> Вам никогда не приходило в бошку что деление на CISC и RISC
> ни разу не черно-белоеВнезапно это очевидно. Но проблема RISC в том, что там преднамеренно примитивизируется набор команд с целью упрощения декодирования и планировки, с переносом части таковых в статический анализ компилятором. Чтобы потом "фактически реализовать" сложное планирование - надо сначала попытаться провернуть этот фарш назад, а потом из получившейся мозайки, отдалённо напоминающей исходную собачку, попытаться нарезать аккуратные кубики для ядра. Что допустим старшие кортексы и делают, пытаясь хоть как-то догнать x86 по качеству планирования в рантайме.
> Внезапно это очевидно. Но проблема RISC в том, что там преднамеренно примитивизируется
> набор команд с целью упрощения декодирования и планировки, с переносом части
> таковых в статический анализ компилятором.И как по мне это адский EPIC WIN! Компиляторы, в отличие от мельдониевых, свои баги чинят и воркэраунды выкатывают достаточно оперативно. Без адовых кернелмод воркэраундов и туповэйтинга годами с предложением купить пофикшеный ... новый проц.
> Чтобы потом "фактически реализовать" сложное планирование - надо сначала попытаться
> провернуть этот фарш назад, а потом из получившейся мозайки, отдалённо напоминающей
> исходную собачку, попытаться нарезать аккуратные кубики для ядра.
> Что допустим старшие кортексы и делают, пытаясь хоть как-то догнать x86 по
> качеству планирования в рантайме.ЧСХ у них
- неплохо получается
- ядер на тот же кристалл больше
- tdp куда вменяемее
- меньше легаси и оверинженерии, все по делу
EPIC WIN превращается в EPIC FAIL там, где есть ветвление и зависимость от входных данных, то есть статический анализ ничего не даст. То есть чуть более, чем на всём коде, кроме линейных участков. Нет, есть задачи типа перемножения матриц, которые полностью линейны, но основная масса кода статическим анализом не оптимизируется.
> EPIC WIN превращается в EPIC FAIL там, где есть ветвление и зависимость
> от входных данных, то есть статический анализ ничего не даст.Да с хрена ли? См выше, OoO реализации - есть.
> То есть чуть более, чем на всём коде, кроме линейных участков. Нет,
> есть задачи типа перемножения матриц, которые полностью линейны, но основная масса
> кода статическим анализом не оптимизируется.Угу, угу, "а шмель об этом не знает, и поэтому летает"
Лицензия, кастомизация, всё.
Как только ты начнёшь делать микроархитектуру на основе этой архитектуры, сразу столкнёшься с кучей патентов...
Риски есть в продаже. Мипсы не шевелятся, они мертвы.
А в микортиках что тогда?
Ну и тусуйся со своими микортикахами, кто тебе мешает?
На сносных моделях - ARM, Tilera
Модели на мипсе давно пора выкинуть.
О, я помню этот порт под MIPS. Пафосные речи, графики сранивающие производительность и энергопотребление, Ainol первыми выпустившие китайский планшет на MIPS и...как это все "с треском" пошло в народ. Особенно вой вида "а почему на мой новый планшет НИЧЕГО из маркета не установить, все несовместимо?". Китайса потом дооолго продавали этот планшет на MIPS (ЧСХ, отказываясь снижать цену, лол), пока он просто морально не устарел настолько что шансов продать не осталось.
Если учесть что Google американская компания котороая может в любой момент вырубить китайцам доступ к этому, и они это на своей шкурке ощутили - а что они теряют? :)
> Если учесть что Google американская компания котороая может в любой момент вырубить
> китайцам доступ к этому, и они это на своей шкурке ощутили
> - а что они теряют? :)Неа, смысл в том что как оказалось сейчас почти весь софт под андроид идет с бинарными архитектурнозависимыми компонентами (кстати то чего Гугль изначально хотел избежать), а если оные не скомпилированы под %ваша новая модная архитетура%, то почти весь софт превращается в тыкву. И зачем вам сборка андроида под которой ничего не работает?
Впрочем, лично китайцам оно может и сгодится...
> то чего Гугль изначально хотел избежатьНаоборот, гугл планировал ушатать всё блобами. А "открытость" ведра была заманухой для погромистов, типа, вот, открытая архитектура, учите, пишите...
Бизнес гугла не завязан как таковой на блобы.
>Чем RISC-V лучше MIPS"В 1981 году коллектив под руководством Джона Хеннесси (John L. Hennessy) из Университета Стэнфорда начал работу над проектом, который получил название MIPS."
Начали разработку почти на 3 десятилетия позже, учитывая недостатки MIPS и других.
Ещё надо рисководам написать статью: "чем риск-в лучше Б3-34"... ммм... ой... а лучше ли?!
А что за GPU?
Vivante GC8000UL
Оно быстрее хотя бы Денди?
Да.
А псевдографику МК-61 тоже обгоняет?
Да.
А etnaviv эта штука цеплаяется? Впрочем с такими подходами если и не - скоро будет.
Мвободный процессор это отлично!А что на счет свободного видео и биос? Без полностью свободной борды смысла в этом немного.
Свободная ISA. Микроархитектуры камней все равно все проприетарные
Есть же вроде чистые процессоры на риск5.
https://gitlab.com/shaktiproject
Почему смысла немного? Смысла очень много.А открытые видеокарты есть, например, Project VGA (http://wacco.mveas.com/). Ты можешь сделать её даже дома, если захочешь. Или можешь купить у меня за 600 бел. рублей.
Там последние новости датированы 2008 годом.
Что поделать. Там всё открыто, можно продолжить разработку.
как обычно:
- Есть открытые ХХХ?
- Есть.
- А где они?
- Сделай сам.
Можешь купить у меня за 600 бел. рублей.
Сними видеоролик и выложи на ютуб.
> Сделай самНа вас не угодишь. Если корп сделает, доверия нет. Самому сделать неохота. Ну тогда пистолет с 1 патроном купите, говорят помогает.
Подавляющие большинство под свободными лицензиями, есть конечно проприетарные, но их меньшинство.
https://riscv.org/exchange/cores-socs/
Там по-моему только одна под _открытой_ лицензией, всё остальное проприетарщина. Большинство такое большинство.
По твоему? Там полно GLP, BSD, MIT.
> По твоему? Там полно GLP, BSD, MIT.найди мне 64 бита под гпл
> По твоему? Там полно GLP, BSD, MIT.А кстати, я ошибся, там ни одной под гпл и примерно одна поделка под бсд и одна под мит.
LGPL: https://opencores.org/projects/rv01_riscv_core
Свободный BIOS - Coreboot
> Свободный BIOS - CorebootДля новых чипов, однако, блоб-онли FSP или AGESA требуется, да и блобы ME полностью оборвать в новых интелях не получается. Их в принципе научились кастрировать малость но там все-равно надо верить джентльменам на слово что оно и правда угомонилось, а не только вид сделало.
Хрен редьки не сладче, везде будет зонд, и скрытая архитектура, что бы деньги зарабатывать, и опять у халявщиков подгорает. Этот бизнес ради денег, а не для вас халявщиков.
Не хочешь покупать фуфло - халявщик.
Микрокод
У RISC'ов обычно нет микрокода который uCode ROM. А системное фирмваре совершенно не обязано быть закрытым. Чему пример uboot и coreboot. И тут вопрос в том насколько производитель документирует свое добро, помогает разработчикам или хотя-бы не ставит палки в колеса как intel ME и amd psp
Набери в гугле microcoded risc-v, удивишься.
Ну да, реализаций RISC-V на Velilog, Chisel для загрузки в FPGA полно.
> Ну да, реализаций RISC-V на Velilog, Chisel для загрузки в FPGA полно.Как бы логично - только это "HDL" - Hardware Development Language. То что железо стало модно описывать кодом - да, а чего? У некоторых проприетариев так вообще есть трансляторы с сишки в железо, думаешь с фига ли "realtime" версия AV1 и VP9 имеет странные ограничения, вида белое не одевать, обтягиваюшее не носить, плавучку не использовать, .... ? А вот потому - они его в аппаратный блок транслируют, а вот прямо обкатав алго на компе :)
Вот только реализации эти - самые тупые, уровень студоты. Microcoded risc-v работает медленнее черепахи.
И вообще то их навалом готовых. Бери и используй.
https://riscv.org/exchange/cores-socs/
Каждый студент может такое нарисовать... Никакой ценности в этом нет. Все эти "ядра" - тупейшая схемотехника, даже первые ПМК и то намного сложнее были.
> Каждый студент может такое нарисовать... Никакой ценности в этом нет. Все эти
> "ядра" - тупейшая схемотехника, даже первые ПМК и то намного сложнее были.Что представляет ценность - решает не какой-то левый аноним на форумах а рынок. И судя по резкому взлету стартапов на RISCV и многочисленным анонсам RISCV чипов, аноним с своим 486 вортексом может бамбук курить...
> StarFive VIC7100 работает на частоте 1.5GHz, включает MMU и другие компоненты, необходимые для работы полноценных Linux-дистрибутивов
> поддерживает аппаратные кодировщики/декодировщики H264/H265/JPEG (4K@60FPS)
> оснащена 8 ГБ ОЗУ, WiFi, Bluetooth, 4 портами USB 3.0, USB-C, гигабитным Ethernet, HDMI 1.4
> В качестве поддерживаемого программного обеспечения заявлены FreeRTOS, Debian и Fedora
> Плата будет продаваться по цене 150 долларовА чего так дешево? В чём подвох? Из-за того, что не нужно платить никаких лицензионных отчислений?
Да, из-за этого. Иначе она бы стоила 165 $.
Будет ещё дешевле, $12: https://cnx-software.ru/2020/11/09/proczessor-allwinner-risc.../
Ноуты от $200 начинаются, у которых, помимо платы, есть ещё и корпус, аккумулятор, монитор...
РИСКи это открытое аппаратное обеспечение.
И? Чем тебе поможет, что набор команд по открытой лицензии?
Ты ведь сам не будешь проектировать микроархитектуру и паять транзисторы в кремниевой пластине? Нет? Ты ведь купишь ГОТОВЫЙ проц, точно такой же готовый, как интел, stm и пр., у которых отлично документированы команды. Дак и на кой тогда тебе сдалась открытость набора команд?
Может знаю Верилог и занимаюсь FPGA, а может и нет.
А с другой стороны не понимаю скепсис в отношении открытого железа. Я могу предположить два типа: те кто производит железо с закладками или те кто эти закладки юзает по долгу службы.
Да не железо открыто, а всего лишь набор команд. Ты хоть понимаешь разницу между набором команд и микросхемой?
> Да не железо открыто, а всего лишь набор команд. Ты хоть понимаешь
> разницу между набором команд и микросхемой?Для RISCV есть куча вариантов открытых реализаций. И на HDL, и на chisel некоем чудесатом, который чуть не ява.
> куча вариантов открытых реализаций.Дерьмище это, а не реализации. Б3-34 и то быстрее считает.
> Дерьмище это, а не реализации. Б3-34 и то быстрее считает.Ну, ты считай на Б3-34 - а я буду на чем-нибудь другом, включая и RISCV.
А какие еще реальные опции у меня есть? Если арм сольется нвидии, это задник и для меня и для отрасли. Да и проприетарии они, наглеют временами, что ни говори, как с MALI. Блобота и бэкдоры x86 - элементарно задолбали и мне нужны системы где ME и PSP нет. Я даже не прочь денег отсыпать на краудинговых площадках тем кто это сделает. С моей стороны спрос на то чтобы послать зарвавшизся проприетариев, что в этой схеме вам не понятно? Кроме перфоманса у системы есть много других свойств и атрибутов.
И вообще то их навалом готовых. Бери, заказывай производство.
https://riscv.org/exchange/cores-socs/
И что ты за чушь вывалил? Верилог?! Это тебе любой студент за неделю напишет. Хер ты с этим в производство сунешься.
Прекрасно сунешься. Почитай про RTL.
Но, само собой разумеется, с заказом меньше чем на сотню килобаксов никто с тобой связываться не будет.
> И что ты за чушь вывалил? Верилог?! Это тебе любой студент за
> неделю напишет. Хер ты с этим в производство сунешься.Вообще-то навалом тех кто залил это в FPGA или доделал и сунулся. Проприетари таки смогли всех достать и с железом, нвидия vs arm было последней каплей, имхо.
Вот и получается, недопроц для игрушек. Вроде и считает, если надо пару числе в час складывать.
> Вот и получается, недопроц для игрушек. Вроде и считает, если надо пару
> числе в час складывать.Вон ту quad-core игрушку с pcie из соседней линки на том же краундфандере я себе пожалуй даже прикуплю. Это гораздо интереснее гадской интелской блоботы выглядит и подкинет денег тем кто двигат отрасль в нужную мне сторону.
> как интел, stm и пр., у которых отлично документированы команды.А потом интел запихнет всем ME, nvidia скупит ARM, ... а потом еще кого-нибудь объявят врагами народа с которыми иметь дело нерукопожатно. Так то оно смешно, конечно - если это не про вас.
> Дак и на кой тогда тебе сдалась открытость набора команд?
Потому что кое-что прижатое закрывшейся проприетарной дверью очень уж свербит. Открытая технология никуда не денется, проприетарная - как повезет. Ну, как, если у меня есть исходник в HDL, хочу в fpga заливаю, хочу на фабу. А если фирма ARM сказала что лицензировать больше не будет - тогда чего? К тому же нвидия может всех нагнуть даже не потому что CAATSA и торговые войны, а потому что нехрен конкурентам жировать.
И поэтому все "почему-то" юзают закрытые интелы и армы, а вот у "открытых" риск-в что-то не складывается никак... Наверно потому, что открытость набора команд - она в ж* никому не упёрлась? Если я имею навык "хочу в fpga заливаю", я себе проц безо всяких риск-в сделаю за пару дней. Это настолько уже дубовая тема, что на всяких курсах за презентацию рисуется готовый проц.
> И поэтому все "почему-то" юзают закрытые интелы и армы,Как минимум вполне конкретный я не уполномачивал вас расписываться за меня. Поэтому про "всех" вы уже соврали. В смысле я конечно пользуюсь перечисленными. Пока. Но с удовольствием перестану, учитвая подходы этих замечательных фирм и недавние истории.
> а вот у "открытых" риск-в что-то не складывается никак...
В том что вы дико гоните можно убедиться тупо пощелкав ссылки на краудсаппли, он там что-то типа похожих проектов выдает и там этого "никак" успешно собравшего бабки, а то уже и выполнивших заказы почему-то есть.
> Наверно потому, что открытость набора команд - она в ж* никому не упёрлась?
Да вот пример нвидии vs arm как-то резко открыл всем глаза на тему кому и чего уперлось. Неудобно, видите ли, когда конкурент может прибить вам весь бизнес одной удачной сделкой. И вот тут ж* начинает подгорать даже у вчерашних убежденных проприетариев.
А прикиньте, фирма нвидия может взять да и сказать квалкому, броадкому и прочим самсунгам что ХРЕН ВАМ ВСЕМ, ТЕПЕРЬ ПОКУПАЙТЕ ЧИПЫ У НАС. Теоретически можно в суде попинаться на тему монополий, практически фирма за время суда может просто сдохнуть из-за проблем ведения бизнеса.
> Если я имею навык "хочу в fpga заливаю", я себе проц безо всяких риск-в сделаю за пару дней.
Ну во первых, сравнимое с RV - скорее таки за пару лет.
Во вторых, врядли у вас будет портфолио более-менее совместимых чипов на разные оказии.
В третьих, допустим, сделали - и дальще чего? Кому и зачем надо проц без кода? А где код под ваш супер-проц брать?> Это настолько уже дубовая тема, что на всяких курсах за презентацию рисуется готовый проц.
Есть некоторая разница между продакшн-риди решением и лабораторным макетом на столе.
> если у меня есть исходник в HDL ... хочу на фабу.Ну да, конечно, у каждой домохозяйки есть миллионы и доступ к фабе :)
> Ну да, конечно, у каждой домохозяйки есть миллионы и доступ к фабе :)Вон там домохозяйки на crowdsupply деньги на запуск производства стреляют. И несколько SoC уже выкатили. Так что походу - есть. Сейчас чипы делают мелкие нонейм стартапы, про которые вы год назад и не слышали.
Какие?
С кнопочками такие, чёрненькие. У них ещё экран открывается, как крышка твоего погреба. Там клавиатура под экраном... Хотя тебе сложно понять, конечно, как ноут выглядит.
Может, когда-нибудь, ты ещё увидишь не только чёрненькие, но и металлическим блеском.
А как ещё рассказать челу, какие-такие эти ноуты?!
>не налагая условий на использование.Не знаком с темой, но если совсем никаких - то пахнет махровой проприетарщиной и еее.
Ну корпус то сделают или так и будут поставлять кусок железной платы?
зачем оно вообще за $150?! ни корпуса, ни аккумулятора, ни дисплея... Когда ноут можно за $200 купить.
Какой?Платы RISC-V нужны для мультимедийных устройств и умных телевизоров.
Собрался дома телевизор паять?
Мультимедийное устройство.
Возьми Нокию старую и воткни в неё колонку - вот всё, что тебе достаточно. Хочешь - на жабе пиши, хочешь - будь сплюснутым.
> Возьми Нокию старую и воткни в неё колонку - вот всё, что
> тебе достаточно. Хочешь - на жабе пиши, хочешь - будь сплюснутым.Не является восппроизводимым решением. На яве к тому же постоянными запросами разрешений дико заколебывает, юзабилити такой колонки полное дно.
> На яве к тому же постоянными запросами разрешенийЭто ты, деточка, просто не знаешь, как сертификат делать к приложению. Сразу понятно, никогда ничего не делал подобного, только свистеть умеешь.
> Это ты, деточка, просто не знаешь, как сертификат делать к приложению. Сразу
> понятно, никогда ничего не делал подобного, только свистеть умеешь.Я лучше потрачу мое время на изучение каких-то более актуальных и полезных знаний чем борьба с кривой (и абсолютно дохлой) проприетарщиной.
А какой мне так по жизни будет профит со всей этой академической гребли? Я даже вторую такую же штуку по заявкам слушателей напрягусь собрать, это надо еще один кусок нокиевского хлама где-то искать. Ну и зачем мне тратить время на эти извращения?
> RISC-V нужны для мультимедийныхА что, никто из не-риск-в не может в мультимедиа?! Вот прям никто-никто? И только один риск-в может?!
Могут, но дороже.
Вот ты свистишь, тут недориск по цене ноутбука предлагают...
Какого ноутбука?
WD считает, что и в полках и хардах с SSD оно себя неплохо чует.
Когда работал лет 20 назад в разработке встройки. Сам процессор стоил $5. Отладочная плата $350. Это не для конечного юзера продукт.
> Когда работал лет 20 назад в разработке встройки. Сам процессор стоил $5.
> Отладочная плата $350. Это не для конечного юзера продукт.Мир изменился, это добро подешевело.
BeagleV - Ну что за провал. Какие-то нелепые интерфейсы! нет бы вывести SATA и PCI-E на плате.
Закажи HiFive Unmatched, её начнут отправлять 28 февраля.
Эту? https://www.crowdsupply.com/sifive/hifive-unmatched
Но где на ней SATA? Слоты под SSD есть, но кому-то нужен HDD.
> Эту? https://www.crowdsupply.com/sifive/hifive-unmatched
> Но где на ней SATA? Слоты под SSD есть, но кому-то нужен HDD.Ну так воткнуть его в usb3-коробку. Ну или выдрать из коробки плату и пристыковать к HDD, плата мизерная, с 1 чипом, можно прямтак привинтить куда там надо было.
Beagle хорошо себя в станках чувствовал.
Android - шпионск0-рекламная платформа,
прикидывающаяся телефоном и недо-коплюктером.
Спасибо за ваше мнение, оно очень важно.
> Спасибо за ваше мнение, оно очень важно.Что-то кэпу сегодня фишка не прет, хомячки его сливают. Что, подгорает, никчемности? А ну на вакцинацию, мыши лабораторные!
А RISC-V - еще даже не взвлетевшая
аппаратная платформа
Именно поэтому ARM запускала сайт, который пытался (довольно безуспешно) подчеркнуть предполагаемые преимущества ARM над RISC-V (сайт уже закрыт)?https://abopen.com/news/rattled-arm-launches-anti-risc-v-mar.../
> преимущества ARM над RISC-VДак это даже баранам понятно.
Только баранам это и «понятно».
Неудивительно, что тебе не понятно.
По-моему тут все понятно:
Its claims, though, are not backed by any publicly-available data, and in many cases appear to be based on little more than marketing puffery.
> Дак это даже баранам понятно.Даже баранам понятно что у ARM есть коммерческий интерес в подобных декларациях, завязанный на их бизнес-модели. Понятно что когда кастомеры начинают драпать - это заставляет дергаться и гетзефаксы публиковать. Но на фоне истории с нвидией арму гетзефаксы уже не помогут.
> RISC-V - еще даже не взвлетевшаяА как она взлетит, если от рождения жирная? Вот типичная операция array[index]: на x86/arm занимает 1 (одну) команду, а на risc-v - 3 (три)!
>> RISC-V - еще даже не взвлетевшая
> А как она взлетит, если от рождения жирная? Вот типичная операция array[index]:
> на x86/arm занимает 1 (одну) команду, а на risc-v - 3
> (три)!На AMD64 тоже 3 выходит, если элемент размером больше 8 байт. На IA32 типовой размер 4 байта, поле Scale байта SIB имело запас, позволяющий хранить пару значений в элементе массива.
> тоже 3 выходит, еслигде ты третью нашёл?!
Была статья от инженера конторы Arm. На хабре был перевод. RISC-V это пока замена MIPS/AVR/8051. Но не cortex с его уже не совсем RISC архитектурой.
> RISC-V это пока замена MIPS/AVR/8051Это сразу было понятно, что доисторический шлак свелосипедили.
> Это сразу было понятно, что доисторический шлак свелосипедили.Нихрена, они скорее идеи атм собезьянили, можно мелкое и обкоцаное, а можно вон тех опций донавернуть и ядро OoO сделать. Так оно микрконтроллер, а так - апликушник почтенный. А так нечто среднее, иногда тоже надо.
А 8051 никогда RISCом и не был.
Имелась в виду сфера применения. У поздних хз что в ядре стоит - возможно тот-же RISC с декодером.
> Имелась в виду сфера применения. У поздних хз что в ядре стоит
> - возможно тот-же RISC с декодером.Тем не менее еще один архитектурный уродец. За что и сожран с потрохами ARM. А теперь и RISCV слегка. Кстати да, хорошие вещи должны масшатироваться, по соображениям экосистемы. ARM просек и добился успехов :)
> Была статья от инженера конторы Arm.Так не катит. Выдавать реалистичные заявления может только кто-нибудь нейтральный, без шкурного интереса. А тут явно не этот случай.
> Была статья от инженера конторы Arm. На хабре был перевод.В статье половина - вкусовщина или устарело, из остатка ещё половина спорна. Фактически, единственное что похоже на повод задуматься это таки отсутствие адресации base+index*scale+offset. И то, практика показывает, что случаев необходимости в такой адресации реально ну очень мало.
Практический же код под RISC-V (64) оказывается даже компактнее, чем под AArch64.
Зато вот эта статья - повод задуматься: https://habr.com/ru/company/vdsina/blog/534542/> RISC-V это пока замена MIPS/AVR/8051. Но не cortex с его уже не совсем RISC архитектурой.
Пока что видна тенденция на соревнование другими методами.
>> тоже 3 выходит, если
> где ты третью нашёл?!С запасом взял, что бы сошлись на 2-х в среднем.) Индекс может где-то еще использоваться, тогда его приходится копировать или хранить в 2-х регистрах в различном представлении (помноженный на 2, либо в виде адреса).
Вообще это нормально для чистых RISC процов. У них нет декодера - так что фактически тот-же ARM/x86 выполнит те-же три команды после декодера, просто это синтаксический сахар.
> тот-же ARM/x86 выполнит те-же три командыи выполнит быстрее, чем пока risc-v будет ковыряться в трёх соснах.
> просто это синтаксический сахарНу ты сам-то посчитай... У x86 - 1 команда на 3 байта, у ARM - 1 команда на 4 байта, у RISC-V - 3 команды на 12 (!) байт. Затык по памяти у risc-v в 3..4 раза больше. Это раз. Далее - выборка команд, x86/arm сделают это за такт (опускаем пока, что x86 может вообще кучу команд сдекодить за раз). А вот risc-v сделает это за 3 такта (но после того, как пережуёт в 3..4 раза больше памяти). Это два. Всё, уже приплыли. И третий этап - конвейер, у нормальных будет результат на каждый такт, у risc-v - никак эти 3 команды не слепятся в одну. Ты удивишься, но операция base+scale*index выполняется за раз, а не в два приёма, как ты подумал.
>> просто это синтаксический сахар
> Ну ты сам-то посчитай... У x86 - 1 команда на 3 байта,
> у ARM - 1 команда на 4 байта, у RISC-V -У x86 команда от байта до 4, еще и параметры хз сколько займут. Из-за этого и геморрой с этой помесью велосипеда с осьминогом. Там декодер просто переуплотнен.
>>у RISC-V - 3 команды на 12 (!) байт.
Да пофиг реально. Никак не повлияет,
>>А вот risc-v сделает это за 3 такта
С чего бы? Даже AVR спокойно по 4 команды за такт кушал.
>>Ты удивишься, но операция base+scale*index выполняется за раз, а не в два приёма, как ты подумал.
Я ничего не думал. Операция обращения в RAM зависит только от RAM, чего там процессор в смещении насчитал сугубо его проблемы.
> У x86 команда от байта до 4, еще и параметры хз сколько займутНе тупи, команда x86 base+scale*index кодируется ТРЕМЯ байтами.
>А как она взлетит, если от рождения жирная? Вот типичная операция array[index]: на x86/arm занимает 1 (одну) команду, а на risc-v - 3 (три)!Либо дурак, либо тонкий тролль.
RISC - это Reduced Instruction Set Computer, то есть компьютер с упрощённым набором команд. Поскольку команды упрощены, для выполнения тех же операций требуется выполнить больше команд. Но за счёт этого процессор получается проще, команды выполняются быстрее и их проще выполнять конвейерным способом: несколько последовательных инструкций выполняются одновременно, каждая на своём этапе.
Ну и чтобы было понимание: x86 и arm внутри себя имеют RISC-ядра. Одна большая внешняя команда транслируется в несколько простых команд внутри процессора для исполнения их на RISC-ядре. Инструкции RISC при этом остаются неизменными, т.к. "отлиты в железе", а вот транслятор можно настраивать при помощи микрокода: прошивки для процессора. Можно заливкой новой прошивки реализовывать новые инструкции или управлять тем, в какие инструкции для RISC-ядра транслируются внешние большие инструкции.
ARM перестал быть RISC? ARM - Advanced RISC Machine, как бы.
> ARM перестал быть RISC? ARM - Advanced RISC Machine, как бы.Он перестал быть удобной компанией у которой можно просто лицензировать процессорные ядра. Остальное при этом уже не важно. Они урыли свой главный ассет своими фокусами с нвидией. Статус-кво нарушен.
Бла-бла-бла... Кроме академических слов ничего не знаешь про реальные архитектуры.
> А как она взлетит, если от рождения жирная? Вот типичная операция array[index]:
> на x86/arm занимает 1 (одну) команду, а на risc-v - 3
> (три)!Потому что заботливый декодер внутри её разложит как надо по исполнительным модулям.
Что для RISC вещь несуществующая - тут да, придётся заранее компилятором раскладывать
А если декодер знает, что у него ещё свободные модули остаются - он ещё и пару следующих команд на остаток разложит, и зависимости протегирует для внеочередного исполнения.
В случае RISC это опять делается компилятором.Почему бы не делать компилятором - это же так можно, да?
Да можно, и даже не менее эффективно, но... До первого conditional'а. Когда на RISC компилятору придётся не раскладывать ничего, кроме этого самого conditional'а, и только после получения результата дальше в новой цепочке раскладывать, потому что компилятор не знает, что там в источнике для условия, какие данные, и знать не может. А вот декодер CISCoRISC вполне может знать - и разложит "вперёд", занимая свободные модули. Если совсем не знает - разложит обе цепочки спекулятивно, и одну выкинет.
А самое весёлое начинается когда у тебя число например исполнительных модулей изменилось от ревизии проца к ревизии проца. CISCoRISC старый код выполнит, и даже возможно более оптимально разложит. А вот в случае чистого RISC ты в общем случае идёшь компилять всё заново :D
Спасибо, все уже видели чего и куда интеловский декодер и микрокод раскладывают своим мельдонием. И потом хрен дождешься патченый микрокод, новый проц, дескать, лучше купите для починки интельской криворукости. Ага, отлично. А может лучше тогда денег кому-то другому дать? А то еще и отдельно платить за то чтобы процы не глюкавые были - это уже вообще оборзение в терминальной стадии у фирмы. Management Engine, значит, у этих сволочей время кодить есть, а свои косяки чинить - нет? А зачем такой производитель нужен?
> А самое весёлое начинается когда у тебя число например исполнительных модулей изменилось
> от ревизии проца к ревизии проца. CISCoRISC старый код выполнит, и
> даже возможно более оптимально разложит. А вот в случае чистого RISC
> ты в общем случае идёшь компилять всё заново :DЭто такая наркомания, что я вообще не знаю, как цензурно комментировать ;\
RISC не EPIC, в нём никаких подобных ограничений. Нормальный out-of-order заводится на нём не хуже чем на CISC, а то и лучше - декодер проще, не нужно регенерации потока микрокоманд. Уже старшие MIPS тому пример.
> а то и лучше - декодер проще, не нужно регенерации потока микрокомандОставим в покое MIPS, который ни жив ни мёртв. Давай за ARM, у которого таки и настоящее повеселее, и будущее не так печально.
То-то новые кортексы из фарша RISC сначала макрокоманды собирают (ну, не из всего, конечно), и даже кешируют, а потом решедулят на ядро, заново разобрав. Мужики-то не знали, что оно и проще, и не хуже, и нагородили вот такой огород, чтобы хоть как-то сделать вид, что умеют планировать не хуже CISC'ов.
Про EPIC и VLIW речи не шло. Там вообще никаким OOO близко не пахнет. В итанике попробовали, но вышло так себе.
> Оставим в покое MIPS, который ни жив ни мёртв. Давай за ARM,
> у которого таки и настоящее повеселее, и будущее не так печально.
> То-то новые кортексы из фарша RISC сначала макрокоманды собирают (ну, не из
> всего, конечно), и даже кешируют, а потом решедулят на ядро, заново
> разобрав.Давай. Что именно они разбирают и складывают заново? Подробности в студию. Давай напророчу: в первую очередь это замена всяких cmp+bne на одну операцию. Потому что для OoO узкое место в виде одного регистра флагов на всё это гиря на ноге - и это у ARM таки общее с x86.
Или ты просто про раскладку по параллельным исполнительным блокам после разделения независимых операций и регистровых значений? Так это как раз не требует сложной подготовки при компиляции, и идентично переносится на RISC-V, MIPS, Power, и прочая и прочая.
> Мужики-то не знали, что оно и проще, и не хуже,
> и нагородили вот такой огород, чтобы хоть как-то сделать вид, что
> умеют планировать не хуже CISC'ов.Предварительно ввернув один из главных CISCʼовских костылей (см. выше)? Ну да, самоисполняющееся пророчество.
> Предварительно ввернув один из главных CISCʼовских костылей (см. выше)? Ну да, самоисполняющееся пророчество.Именно так. Потому что без этого костыля оно так себе.
>> Предварительно ввернув один из главных CISCʼовских костылей (см. выше)? Ну да, самоисполняющееся пророчество.
> Именно так. Потому что без этого костыля оно так себе.Ну вот тогда у RISC-V как у архитектуры, где этот костыль с одним регистром на всех не нужен, а условием перехода становится наличный прямо сейчас явный результат, получается преимущество.
Ещё одно преимущество - так как передовые компиляторы сейчас на SSA, команды сравнения с немедленным переходом требуют меньше укладки на целевую ISA, чем те, которые зажаты одним регистром условий. (Вот интересно бы почитать, какая эффективность этого на Power - что-то быстро не могу найти такого анализа.)
>NVDLA (Nvidia Deep Learning Accelerator) для ускорения систем машинного обученияА эта фиговина, наверняка, заблобирована по самые не балуйся.
Засадить блобы глубже и качественней чем в малину - наверное невозможно в принципе.. вас же от малины не тошнит?
а процесс загрузки малины- он знаете ли вам не принадлежит...
Тошнит от третьей. Про процесс загрузки четвёртой не знаю.
opennets, какой seeed studios?
А тебе зачем? Производитель всякой мелочевки на arduiono/beagle и прочих шилдов. Даже что-то своё клепал.
Via заметил, что это Seeed Studio, но постеснялся исправить новость. Via, внизу и справа от текста новости есть кнопка «исправить».
Понял, что не понял юмора.
Спасибо.
Это не для широких масс, так для гиков не более того.
для розовых пони... кода на risc-v получается в разы больше, чем для arm. Сама архитектура risc-v - тормознутая, многое надо лапками делать (нет флагов, исключений для арифметики). Типичный пример - при суммировании перенос между частями сложного числа... в risc-v переноса нету! как хочешь, так и тискайся.
> для розовых пони... кода на risc-v получается в разы больше, чем для arm.Да сейчас, рисковский аналог thumb2 лишь немного более рыхлый. Процентов 20 едва ли. И когда альтернативой кончина апстрима и злобная нвидия, кого такие мелочи вообще волнуют, право? :)
> для розовых пони... кода на risc-v получается в разы больше, чем для
> arm.Не-розовые пони нагло врут.
Беру набор компиляторов из убунты (GCC близких версий, опция -O2), только под RV самосборный, и сверяем. Объект - кастомный прокси FIX протокола, простой C++11 без наворотов.
amd64: 199368 байт
aarch64: 207552 байта
rv64 без compressed команд: 200448 байт
rv64 с compressed командами: 167680 байтто есть даже без "C" (compressed) набора он только на 1% толще amd64 (и уже тоньше арма).
> Сама архитектура risc-v - тормознутая, многое надо лапками делать (нет
> флагов, исключений для арифметики).AArch64 тоже молча проглатывает деление на 0 (причём в отличие от RISC-V возвращает частным 0). Анонимы, которые зациклились на нём, не смогли прочитать документацию дальше названия.
> Типичный пример - при суммировании перенос между
> частями сложного числа... в risc-v переноса нету! как хочешь, так и
> тискайся.Этот случай занимает жалкие доли процента от всех использований add. Но для криптографии, может, и доработают.
> то есть даже без "C" (compressed) набора он только на 1% толще
> amd64 (и уже тоньше арма).А так он еще в кэш чаще умещаться будет чего доброго, не? Как насчет перфоманс "C" vs "usual" померять? Интересно же.
> возвращает частным 0). Анонимы, которые зациклились на нём, не смогли прочитать
> документацию дальше названия.Ононимы зациклились на каких-то CISC-o-RISC в вакууме - забыв посмотреть на мир вокруг себя, чтобы обнаружить что большая часть их идей уже давно уперта другими, при том они даже пользолвались машиной времени, так что воевать с ними бесполезно - они уже все улучшения процессоров от ононима давно просекли, на 25 лет его потуг вперед.
> Этот случай занимает жалкие доли процента от всех использований add. Но для
> криптографии, может, и доработают.А не проще будет simd вариант какой-нибудь сделать?