The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Android портирован для плат на архитектуре RISC-V, opennews (??), 23-Янв-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


21. "Android портирован для плат на архитектуре RISC-V"  –2 +/–
Сообщение от Сейд (ok), 23-Янв-21, 14:11 
Продуманной архитектурой расширения.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

73. "Android портирован для плат на архитектуре RISC-V"  –1 +/–
Сообщение от Аноним (92), 23-Янв-21, 21:44 
Убожество, а не архитектура... Флагов нет, исключений нет (деление на 0, переполнение), всё надо ПРОГРАММНО делать.
Ответить | Правка | Наверх | Cообщить модератору

79. "Android портирован для плат на архитектуре RISC-V"  –1 +/–
Сообщение от Сейд (ok), 23-Янв-21, 22:17 
У MIPS многие регистры не общие, имеют на сегодняшний день странные ограничения, RISC-V это исправил и это прекрасно.
Ответить | Правка | Наверх | Cообщить модератору

82. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (92), 23-Янв-21, 23:28 
> RISC-V это исправил

...путём кастрации :)

> и это прекрасно.

...без бубенчиков. Приходится всё лапками делать.

Ответить | Правка | Наверх | Cообщить модератору

83. "Android портирован для плат на архитектуре RISC-V"  –2 +/–
Сообщение от Сейд (ok), 23-Янв-21, 23:52 
Расширения в RISC-V сделаны в формате большого количества свободных и специально по функциональности сгруппированных регистров, и каждая разработка в рамках того группирования может делать как ей больше выгодно, не боясь конфликтов с функциональностью других групп (обработка исключения в MIPS — это та ещё радость).
Ответить | Правка | Наверх | Cообщить модератору

90. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (92), 24-Янв-21, 02:03 
> может делать как ей больше выгодно

Всё свелось к тому, что нужно просто послать риск-V в ж* и делать самому.

Ответить | Правка | Наверх | Cообщить модератору

129. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 24-Янв-21, 13:30 
> Всё свелось к тому, что нужно просто послать риск-V в ж* и делать самому.

И как, много процессоров то понаделали? А, целый эльбрус, под который даже компилера нормального нет?

Ответить | Правка | Наверх | Cообщить модератору

208. "Android портирован для плат на архитектуре RISC-V"  –2 +/–
Сообщение от Аноним (185), 25-Янв-21, 02:53 
x86, arm... Тебе мало?! Плешивый вечно про какой-то эльбрус вспомнит. Возьми вортекс вместо риск-в.
Ответить | Правка | Наверх | Cообщить модератору

232. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Аноним (-), 25-Янв-21, 08:57 
> x86,

Ну уж не этому уродцу учить других как процессоры делать.

> arm...

А оно "сделать самому" видите ли только для непонятно кого, кто пошел по рукам, и норовит нвидии солиться. Ядра то у них неплохие, а в последнее время они даже неплохо стали интегрироваться с открытой экосистемой, пиляя девтулсы и даже всякие штуки типа опенсорсной ATF и проч.

И все же, хоть линуксоиды и не злопамятные, но за MALI и многолетнее делание нам мозга они все же должны ответить. А когда их вот-вот сожрет нвидия - так она не будет ядра конкурентам лицензировать. Это заставляет немало компаний гадить кирпичами, от китайских фаблес подвалов с 5 разработчиками до транснациональных корпораций. Так что RISCV получил нефиговое развитие на фоне новостей о сделке.

> Тебе мало?! Плешивый вечно про какой-то эльбрус вспомнит. Возьми вортекс
> вместо риск-в.

Ну так то ж не у "вас", а у толи softbank, толи нвидии. И если фирма ARM откажется лицензировать вам очередное ядро - тогда, собственно, чего? При том такой маневр заставил напрячься даже тех на кого CAATSA и близко не распостряняется. Кроме нее видите ли еще конкуренция есть.

Ответить | Правка | Наверх | Cообщить модератору

314. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 27-Янв-21, 16:02 
p.s. а зачем мне ваш вортекс угробищный? У меня 486 был в 90-е какие-то, тогда это имело смысл. А сейчас в этом смысла - ноль.
Ответить | Правка | Наверх | Cообщить модератору

101. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Аноним (-), 24-Янв-21, 07:09 
> ...путём кастрации :)

Как показал пример RISC вообще и ARM в частности, если оборвать всякую оверинженерию, сделать маленькое, крутое и эффективное ядро - при масштабировании всего этого можно получить довольно интересные результаты.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

111. "Android портирован для плат на архитектуре RISC-V"  –3 +/–
Сообщение от Аноним (185), 24-Янв-21, 08:39 
> сделать маленькое, крутое и эффективное ядро

в случае risc-v получилось маленькое, некрутое, неэффективное...

Ответить | Правка | Наверх | Cообщить модератору

131. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Аноним (131), 24-Янв-21, 13:43 
> в случае risc-v получилось маленькое, некрутое, неэффективное...

Вон те штуки с 4 64-ядрами уже не такие маленькие. Или вам все что меньше EPYC'а за $4k - не процессор? :)

Ответить | Правка | Наверх | Cообщить модератору

175. "Android портирован для плат на архитектуре RISC-V"  –2 +/–
Сообщение от Аноним (185), 24-Янв-21, 21:36 
> уже не такие маленькие

Ой, да, извини... risc-v получилось ОЖИРЕВШЕЕ, некрутое, неэффективное...

Ответить | Правка | Наверх | Cообщить модератору

233. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Аноним (-), 25-Янв-21, 09:01 
> Ой, да, извини... risc-v получилось ОЖИРЕВШЕЕ, некрутое, неэффективное...

В смысле - ожиревшее? Оно под задачу конфигуряется, на манер ARM. Есть хренова куча реализаций, кому жирные и производительные, кому мелкие и экономные. И со всеми этими историями с нвидией арм очень сильно нарывается. Уже, имхо, нарвался. Такой всплеск активности по RISCV попер со всех направлений что охренеть просто. Много людей вдруг осознало что им неудобно когда кое-что зажато дверью, целиком управляемой их конкурентом. Или компанией не вхожей в отрасль - нвидия микроконтроллеры не делает и не в курсе специфики.

Ответить | Правка | Наверх | Cообщить модератору

116. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 24-Янв-21, 11:37 
> Флагов нет, исключений нет (деление на 0, переполнение), всё надо ПРОГРАММНО делать.

RISC вообще недружелюбны к любителям писать программы в машинном коде. Хочешь писать в машинном коде, пиши под 8086, или под PDP-11. Там хорошо получается. А, я б ещё порекомендовал глянуть на Сетунь, судя по слухам, там реально ассемблер был не нужен, потому что троичные машинные коды читались как ассемблер.

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

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

144. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Аноним (-), 24-Янв-21, 15:37 
> RISC вообще недружелюбны к любителям писать программы в машинном коде.

Мнение полного профана в вопросе. Ты вообще на ассемблере программировать умеешь? Посмотри на ARMовский ассемблер, например. Только стоит честно предупредить: попробовав это врядли ты захочешь когда-нибудь еще програмить для x86. Классная, симметричная система команд, нормальные режимы адресации, крутой компактный и эффективный код без сложного декодера. Вот это - работа настоящих профессионалов.

RISCV немного более дурацкий: из-за излишней академичности авторов они были не везде в курсе проблем реального мира, а ЧСВ не позволило им посмотреть на то что сделали другие. Поэтому бутануть cortex-M одними сями - легко. А вот RISCV таки все же потребует небольшой но все же асмовый стартап, увы и ах.

> Хочешь писать в машинном коде, пиши под 8086, или под PDP-11. Там хорошо получается.

Попробовав програмить под ARM прогать под х86 нормальному ассемлерщику немедленно расхочется. Потому что все познается в сравнении. И это древнее легаси обвешаное костылями не выдерживает никакого сравнения с современным аккуратным ядром сделаным теми кому надо чтобы его у них еще и лицензировал бы кто-нибудь, в отличие от интела.

Самое логичное описание ARM: если x86 это такой потомок 8080, то ARM - потомок 6502. Крутой и правильный потомок. Пример того как его надо было делать с самого начала.

Ответить | Правка | Наверх | Cообщить модератору

155. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 24-Янв-21, 18:52 
>> RISC вообще недружелюбны к любителям писать программы в машинном коде.
> Мнение полного профана в вопросе.

Ох, тут анонимный специалист нарисовался? Наконец-то. А то как не глянешь вокруг, никто из анонимов не понимает, о чём пишет.

> Ты вообще на ассемблере программировать умеешь?

А почему вы спг’ашиваете?

> Посмотри на ARMовский ассемблер, например.

Чё на него смотреть? RISC как RISC. С этой дурацкой манерой выполнять операции исключительно над регистрами, необходимостью в две-три команды грузить полное значение регистра из immediate операнда. На это похрен, когда этим компилятор занимается, но вручную я этим заниматься не буду.

> Только стоит честно предупредить: попробовав это врядли
> ты захочешь когда-нибудь еще програмить для x86.

Хаха.

> Классная, симметричная система команд,
> нормальные режимы адресации, крутой компактный и эффективный код без сложного декодера.
> Вот это - работа настоящих профессионалов.

Ну вот у RISC-V декодер ещё проще. Плюс система команд разработана с мыслью о том, что команды конвееризировать, и что конвееров может быть больше одного.

> RISCV немного более дурацкий: из-за излишней академичности авторов они были не везде
> в курсе проблем реального мира, а ЧСВ не позволило им посмотреть
> на то что сделали другие.

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

> Поэтому бутануть cortex-M одними сями -
> легко. А вот RISCV таки все же потребует небольшой но все
> же асмовый стартап, увы и ах.

Ты так говоришь, будто это что-то плохое.

Ответить | Правка | Наверх | Cообщить модератору

158. "Android портирован для плат на архитектуре RISC-V"  +2 +/–
Сообщение от Аноним (-), 24-Янв-21, 19:46 
> никто из анонимов не понимает, о чём пишет.

Тот Аноним прогал на штуках пяти разных ассемблерах. И 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 таки все же потребует
>> небольшой но все же асмовый стартап, увы и ах.
> Ты так говоришь, будто это что-то плохое.

Да, я считаю что написать фирмаварь на си без единого бита асма - это прикольно придумали. Правда, в паре мест - только подумайте - тоже наследие легаси - и они таки тоже протупили.

Ответить | Правка | Наверх | Cообщить модератору

162. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 24-Янв-21, 20:26 
> С другой стороны - не особо продумано насчет микроконтроллеров и проч где
> суперскорость нафиг не надо, надо максимальную предсказуемость по времянкам. И вот
> тут простой и быстрый набор команд оказывается 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 мало сказываются. Если вообще сказываются.

Ответить | Правка | Наверх | Cообщить модератору

174. "Android портирован для плат на архитектуре RISC-V"  –2 +/–
Сообщение от Аноним (185), 24-Янв-21, 21:24 
> нарисуй себе ... Собирая себе ...

Вот и получается, что проще сразу сделать свой проц, чем торкаться с риск-в.

Ответить | Правка | Наверх | Cообщить модератору

193. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Ordu (ok), 24-Янв-21, 22:19 
>> нарисуй себе ... Собирая себе ...
> Вот и получается, что проще сразу сделать свой проц, чем торкаться с
> риск-в.

Ты забываешь про:

1. github, откуда ты можешь таскать готовый verilog. Плюс к этому прилагается куча опыта тех, кто уже нарисовал, то есть если ты захочешь нарисовать свой с нуля, ты сможешь за неделю-две узнать где лежат грабли, почитав других, и обойти их.

2. Тулчейны. Под свой проц придётся попыхтеть, под risc-v ты можешь взять любой компилятор на llvm (и возможно gcc), и использовать его, лишь передав ему флагов, говорящих о том, какие блоки системы команд доступны в процессоре.

Ответить | Правка | Наверх | Cообщить модератору

241. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Аноним (-), 25-Янв-21, 10:35 
> Вот и получается, что проще сразу сделать свой проц, чем торкаться с риск-в.

Так много процов то понаделали, если это проще? А то кучка SoC с RISCV которые уже выпускаются или на грани этого вон там по ссылкам рядом с новостью на краудсаппли без проблем.

А вы там есть? И если да - как у вас с поддержкой линукса? Опенсорсными бутлоадерами и поддержкой системы команд gcc? А то может мне и вам тоже денег насыпать? А если вы хотели сказать что у вас всего этого нет - ну тогда вы и денег с меня ни копья не получите. Вот такой простой и понятный любому комерсу аргумент. С моей стороны запрос на вот такой фичесет. Кто ему соответствует - получает мои бабки.

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

234. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 25-Янв-21, 09:40 
> 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) довольно неудобно. Хоть и делается.

Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

290. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 26-Янв-21, 00:09 
> Тот Аноним прогал на штуках пяти разных ассемблерах. И x86 был наиболее
> блевотным из таковых

Блевотный какой-то аноним.
Если рейтинговать по блевотности, то в лидеры скорее выбьется как раз таки обожаемый ARM.

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

310. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 27-Янв-21, 15:26 
> Если рейтинговать по блевотности, то в лидеры скорее выбьется как раз таки
> обожаемый ARM.

Его в отличие от интела делали профессионалы, а не маркетологи, до последнего камлавшие на свой win32'tel убогий, происходящий из эпохи когда каждый транзистор был на счету, так что убогий регистровый файл имел хоть какое-то оправдание. Но это закончилось 20+ лет назад, и уж выделить транзисторов на нормальный набор регистров и человесческую адресацию наверное все-таки уже можно. И было уже можно четверть века назад. ARM об этом догадался - и не интелу учить их транзисторы экономить, кстати :)

Ответить | Правка | Наверх | Cообщить модератору

320. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 27-Янв-21, 21:03 
Ну ладно Acorn, VLSI - тут да. Но свежак то после...

Apple
Инженеры

Блеванул.

Ответить | Правка | Наверх | Cообщить модератору

327. "Android портирован для плат на архитектуре RISC-V"  +1 +/–
Сообщение от Аноним (327), 27-Янв-21, 21:31 
> Ну ладно Acorn, VLSI - тут да. Но свежак то после...

По сравнению с Acorn'овскими - Cortex'ы как летающий делореан супротив винтажных драндулетов. Клевые, логичные, продуманые ядра. Где легаси эпохи акорнов немного повытрясли и как раз сделали как логичнее, удобнее и лучше работает, а не что-нибудь еще. А будучи инженерами а не маркетологами еще и придумали как сделать все это компактно и эффективно. Иначе кто бы в здравом уме это у них лицензировал?!

> Apple
> Инженеры
> Блеванул.

"Эксперт" походу ваще не читает тематические новости и не в курсе что эти дезигнеры между делом сманили у ряда кондовых чипмейкеров типа амд и интеля инженеров процессорного направления. А таки да, теперь ябл может и довольно глубокий дизайн чипов сам. И самсуня они таки послали с этим, теперь это уже не малость допиленый заказной exynos а вполне себе свои чипы.

Ответить | Правка | Наверх | Cообщить модератору

322. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 27-Янв-21, 21:10 
> больше простора компилятору для оптимизаций

Вся проблема RISC в том, что там нет рантайм-оптимизации. Которая вполне себе есть в CISCoRISC'ах.
Она просто невозможна потому, что компилятор ничего не знает о входных данных, которые коду придут в каждую конкретную единицу времени.

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

328. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (327), 27-Янв-21, 21:35 
> Вся проблема RISC в том, что там нет рантайм-оптимизации. Которая вполне себе
> есть в CISCoRISC'ах.

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

Вот это - не инженеры. Это - жулики от маркетинга. И с TDP у интелья отродясь та же история.

> Она просто невозможна потому, что компилятор ничего не знает о входных данных,
> которые коду придут в каждую конкретную единицу времени.

Компилятор отлично в курсе аргументов функции, допустим. А то что интель там пытается спекулировать - блин, доспекулировались, undo спекуляций глюкав донельзя получился.

Ответить | Правка | Наверх | Cообщить модератору

330. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 27-Янв-21, 21:48 
Компилятор вообще ничего не знает о том, какие аргументы в эту функцию придут, если они не статические.
В этом и вся проблема.
Ответить | Правка | Наверх | Cообщить модератору

336. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (336), 28-Янв-21, 02:56 
> Компилятор вообще ничего не знает о том, какие аргументы в эту функцию
> придут, если они не статические.

А что в вашем понимании - не статические? А то в большинстве случаев они как раз именно такие. Нет, ну при желании variadic сделать можно, но вот это уже малость экзотика.

И как угодно но я смотрел что gcc для cortex M делает и там вполне зачетный код. А с глобальными оптимизациями типа LTO он временами очень лихо заворачивает, так что ассемблерщик то не сразу допрет так выпендриться.

> В этом и вся проблема.

Хызы, куча ARMов у меня уже работают и никаких особых проблем я по этой части не имею. Больше всего у меня проблем с x86 системами, радующими глюками проприетарной фирмвари и прочих acpi вокруг. Отделаться от этого "счастья" очень хочется. И платить за ME и PSP из своего кармана мне "религия не позволяет", если так угодно. Я лучше эти деньги отдам стартаперу который направление открытых и опенсорс френдли систем раскручивает чем о...вшему в край мегакорпу удумавшему мне бэкдоры за мои бабки всучивать.

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

Ответить | Правка | Наверх | Cообщить модератору

338. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 28-Янв-21, 07:38 
> А что в вашем понимании - не статические? А то в большинстве
> случаев они как раз именно такие.

То есть у вас все вызовы функций с константами? Никакого пользовательского ввода?
Ну там processMyData(2, 5, 'ohmygod')?
Везёт :D

В реальном мире же в основном аргументы приходят из пользовательского ввода, с сети, с файлов и т.п.
Они заранее не известны. Соответственно компилятор не может предсказать, что будет на входе того или иного участка кода в тот или иной момент. Финальную оптимизацию разных условий делает именно что планировщик CISC в сложных CPU. Ну а простым RISC приходится перетаптываться - в синтетических бенчмарках и на отдельных хорошо оптимизируемых без конвееров алгоритмах они как правило выдают прекрасные цифры, в реальных задачах - начинают сливать, потому что выполнение реального кода получается куда менее оптимальным.

Ответить | Правка | Наверх | Cообщить модератору

351. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 29-Янв-21, 23:57 
> То есть у вас все вызовы функций с константами? Никакого пользовательского ввода?

И тем не менее, 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 им надоели.

Ответить | Правка | Наверх | Cообщить модератору

331. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 27-Янв-21, 21:51 
>> больше простора компилятору для оптимизаций
> Вся проблема RISC в том, что там нет рантайм-оптимизации. Которая вполне себе
> есть в CISCoRISC'ах.

Что это значит, ты можешь объяснить? Можешь привести пример ситуации, в которой то, что ты называешь "рантайм-оптимизацией" дало бы возможности выполнять код быстрее, чем тот же код скомпилированный для risc-v?

Может быть я чего-то не понимаю, но склоняюсь к мысли, что не понимаешь ты. Рантайм оптимизация строится вокруг параллельного выполнения команд во многих конвеерах, идея в том, чтобы иметь много исполняющих устройств для каких-то элементарных операций, и потом максимально загружать эти исполняющие устройства работой в рантайме. Но если ты присмотришься, то ты увидишь, что во-первых, для того, чтобы это работало приемлимо нужны костыли типа branch-prediction или out-of-order-execution, которые потребляют ватты и занимают драгоценные транзисторы, во-вторых, существенная часть работы выполняется в компайл-тайме компилятором, который, зная алгоритмы этой рантайм "оптимизации", подбирает инструкции и располагает их так, чтобы они нужным образом разложились бы по конвеерам, а потом по исполняющим устройствам. Втыкает, например, nop'ов, чтобы занять чем-нибудь конвеер, чтобы тот не воткнулся в бранчевание не вовремя и не сбросился бы. Или скажем атрибут unlikely для условия -- это же подсказка компилятору как расположить в памяти бранчи, дабы рантайм "оптимизация" не спотыкалась бы на этом условии. Или PGO -- топовое достижение "рантайм оптимизации": давайте соберём профайлером данные о том, как выполняется код, а потом скомпилируем его так, чтобы он хорошо "оптимизировался" бы в рантайме.

Последняя фраза не вызывает когнитивного диссонанса? Рантайм оптимизация в компайл-тайме -- как тебе?

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

Ответить | Правка | К родителю #322 | Наверх | Cообщить модератору

332. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 27-Янв-21, 23:48 
Именно так. OOO, предсказание переходов, спекулятивное выполнение.
На уровне компилятора это НЕ делается.
Хоть с likely, хоть с unlikely, хоть с highly likely.
Потому что реальные данные известны только на момент выполнения, соответственно и результат кондишнла.
Ответить | Правка | Наверх | Cообщить модератору

334. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 28-Янв-21, 00:34 
> Именно так. 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 переходы под этот тупой предсказатель, без инверсии условия, которая требует ещё одной команды". Там не нужна ещё одна команда, можно инвертировать условие команды условного перехода. То есть я вообще без идей, зачем это надо.

Ответить | Правка | Наверх | Cообщить модератору

339. "Android портирован для плат на архитектуре RISC-V"  –1 +/–
Сообщение от Онаним (?), 28-Янв-21, 07:47 
> Глупости. Процессор знаешь как делает? Он декодирует инструкцию условного перехода, он не может её выполнить сразу

Кондишнлы внезапно - это не только переходы. Даже банальный сдвиг на бит с использованием флага переноса является кондишнлом. Не говоря уже о специализированных инструкциях типа CMOVxx в x86. При работе того же сдвига и наличии далее зависимой от него команды - возникают две ветки исполнения.

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

> Нет, не ждём, а включаем предсказания и спекулятивное выполнение.

Нет у RISC спекулятивного выполнения. На то он и RISC. И предсказатели переходов сложные не могут возникнуть - неоткуда.

Это прерогатива CISCoRISC, которые могут разложить инструкции на конвеер, выбрать свободные регистры, протегировать, и запустить на хорошо известном планировщику RISC-ядре в параллель.

> Реальные данные могут изменить лишь то, что unlikely переходы

Повторюсь. Кондишнлы - это не только переходы. Нет, в RISC - в основном, и это как раз та причина, по которой они не взлетают в реальных условиях.

Ответить | Правка | Наверх | Cообщить модератору

340. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 28-Янв-21, 07:51 
Да что там блин далеко ходить.
Сложение с переносом банальное - кондишнл.

Псевдокод (целевой аргумент - левый):
ADD v,w
ADC x,y
MOV [mem],x

Всё. RISC вот этот вот примитив будет в линеечку выполнять, и никак иначе.
Хотя как минимум ADC вполне можно спекулятивно запустить.

Ответить | Правка | Наверх | Cообщить модератору

342. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от n00by (ok), 28-Янв-21, 17:05 
> Да что там блин далеко ходить.
> Сложение с переносом банальное - кондишнл.
> Псевдокод (целевой аргумент - левый):
> ADD v,w
> ADC x,y
> MOV [mem],x
> Всё. RISC вот этот вот примитив будет в линеечку выполнять, и никак
> иначе.
> Хотя как минимум ADC вполне можно спекулятивно запустить.

Как ADC запустить, когда там зависимость по данным? На двух исполнителях с разным carry и один из результатов отбросить?

Ответить | Правка | Наверх | Cообщить модератору

343. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 29-Янв-21, 21:13 
Примерно это и делает планировщик в CISCoRISC'ах.
Ты можешь это попытаться делать в компилере - но нужна поддержка исполнительного железа. Которой нет.

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

Ответить | Правка | Наверх | Cообщить модератору

358. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от n00by (ok), 30-Янв-21, 08:32 
> Примерно это и делает планировщик в CISCoRISC'ах.

Почему же Вы не указали причины, по которым "примерно это" не может делать "планировщик" в "RISCoRISC"'ах?

Ответить | Правка | Наверх | Cообщить модератору

367. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 11:15 
Потому что исходный спектр команд достаточно куцый - на то он и RISC, и разбирается на более мелкие независимые операции весьма посредственно. Особенно извращённые комбо, которые тут приводили - группировка условий на целый блок команд и т.п.
Ответить | Правка | К родителю #358 | Наверх | Cообщить модератору

371. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от n00by (ok), 30-Янв-21, 12:03 
> Потому что исходный спектр команд достаточно куцый

Найдите структурную схему процессора. Посмотрите, где там декодер и где ALU. Это разные блоки. К мантре "R в RISC означает религия" они отношения не имеют.

Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

372. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 12:05 
> R в RISC означает религия

Спасибо. Я теперь знаю что ответить любому ратующему за RISC во все поля.

Ответить | Правка | К родителю #371 | Наверх | Cообщить модератору

374. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от n00by (ok), 30-Янв-21, 12:33 
Заодно уточняйте, что Вам религия запрещает усложнять исполнительный блок, что бы не тратить время.
Ответить | Правка | К родителю #372 | Наверх | Cообщить модератору

383. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 31-Янв-21, 00:37 
> Заодно уточняйте, что Вам религия запрещает усложнять исполнительный блок, что бы не
> тратить время.

Ему запрещает. А фирме ARM или вон тем стартаперам с RISCV не запрещает. Поэтому мои бабки и получат они а не этот чудак.

Ответить | Правка | К родителю #374 | Наверх | Cообщить модератору

341. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 28-Янв-21, 14:30 
> Проц со спекулятивным исполнением вполне способен протрассировать обе, если ресурсов свободных
> хватит, и сбросить не нужную после появления реальных данных, а вот
> RISC придётся стоять и ждать флага. Потому что реальные входные данные
> на момент исполнения сдвига ещё не известны, и компилятор далее в
> параллель с ним ничего зависимого расставить уже не сможет.

Мне непонятно, что такого есть в RISC, что не позволит реализовать такое спекулятивное выполнение?

Ответить | Правка | К родителю #339 | Наверх | Cообщить модератору

344. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 29-Янв-21, 21:14 
> Мне непонятно, что такого есть в RISC

Выброси из себя оптимиста, и подумай, чего такого нет в RISC, в связи с чем такое выполнение плохо реализуемо.


Ответить | Правка | Наверх | Cообщить модератору

345. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 29-Янв-21, 21:19 
(между делом, транзисторный бюджет у этого чего-то огромный внутри современных x86, и львиная доля высочайшей эффективности в совершенно разнородных задачах с плохой предсказуемостью именно им и обусловлена)
Ответить | Правка | Наверх | Cообщить модератору

346. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 29-Янв-21, 21:44 
К RISC-V это некоторые пытаются присобачить, но в силу определённой прибитости гвоздями исходной архитектуры - а она не может быть не прибитой гвоздями, потому что иначе будет разброд и шатание - усилия пока немножко тщетны. На расширениях есть варианты, но это уже немножко не RISC-V получается, а её ни с чем не совместимая ветка.

(я сознательно не конкретизирую детали - гуглите :) )

Ответить | Правка | К родителю #344 | Наверх | Cообщить модератору

348. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 29-Янв-21, 22:08 
>> Мне непонятно, что такого есть в RISC
> Выброси из себя оптимиста, и подумай, чего такого нет в RISC, в
> связи с чем такое выполнение плохо реализуемо.

Окей. Чего такого нет в RISC, что делает спекулятивное выполнение плохо реализуемым?

Ответить | Правка | К родителю #344 | Наверх | Cообщить модератору

350. "Android портирован для плат на архитектуре RISC-V"  –1 +/–
Сообщение от Онаним (?), 29-Янв-21, 23:53 
Полноценного планировщика операций нет. Весь пайплайнинг по сути ручной, ещё на этапе компиляции.
Просто потому, что основная прелесть RISC - как раз упрощение железного декодера и планировщика.
Да, для всякого перемножения матриц норм, где всё в кешах, и все операции предсказуемы.
Но на сложных конструкциях с кондишнлами и сильной зависимостью от входных данных всё - привет.
Малейший затык на том же пролёте с кешем - и очередь встаёт.

Из исключений на слуху ныне наверное только ARM, но с ARM тема особая. Те же кортексы уже давно химера. Их даже RISC назвать уже язык не поворачивается. Там уже и кеш макроопераций появился, и обратная разбивка на сопряжённые микрооперации...

Ответить | Правка | Наверх | Cообщить модератору

354. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 30-Янв-21, 00:19 
> Полноценного планировщика операций нет.

А кто сказал что то что делает интель обязательно 1 хороший вариант?

> Весь пайплайнинг по сути ручной, ещё на этапе компиляции.

Как это мешает ядру трекать оба варианта бранча и префетчить потребные данные и проч?

> Просто потому, что основная прелесть RISC - как раз упрощение железного декодера и планировщика.

Это совершенно не мешает существовать разным реализациям одного и того же. Какой-нибудь A7 попроще, а A15 пожирнее. При том они совместимы. С 64-битными ядрами та же история. С RISCV аналогично. Вот так даже мк ок, а вот так это довольно жирный и шустрый 64-битник. Вы с вашим x86 переростком совсем не поняли что мир может быть не прибит на гвозди.

> Малейший затык на том же пролёте с кешем - и очередь встаёт.

Однако вон там нечто на ARM64 зарубается с EPYC. Да и RISCV свое не упустит.

> Из исключений на слуху ныне наверное только ARM, но с ARM тема
> особая. Те же кортексы уже давно химера. Их даже RISC назвать
> уже язык не поворачивается. Там уже и кеш макроопераций появился, и
> обратная разбивка на сопряжённые микрооперации...

Опять же - ARM крут тем что на один набор команд есть разные реализации. Как и с RISCV. Есть большая разница между набором команд и конкретной реализацией ядра реализующего оный. В мире где более 1 implementer'а и конфигураций ядер это совершенно обычное дело.

Это кстати даже интел пробовал - в атомах. Но оказалось что ARM из них совсем никакой. И если ARM и RISCV на десктопах имеют какие-то шансы, то интель около 20 лет бредил tablet pc с нулевым успехом. И это жирная мегакорпа на минутку.

Ответить | Правка | К родителю #350 | Наверх | Cообщить модератору

359. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 10:47 
>> Просто потому, что основная прелесть RISC - как раз упрощение железного декодера и планировщика.
> Это совершенно не мешает существовать разным реализациям одного и того же. Какой-нибудь
> A7 попроще, а A15 пожирнее. При том они совместимы. С 64-битными
> Однако вон там нечто на ARM64 зарубается с EPYC. Да и RISCV

Так я о том же, что "жирные" ARM'ы - это уже не RISC по сути, а химера, которая сначала RISC агрегирует в макрооперации, потом их назад бьёт до микроопераций уже ядра.

> Опять же - ARM крут тем что на один набор команд есть

Внезапно в x86 на один набор команд тоже есть разные реализации. Две основных и несколько мелких.

> из них совсем никакой. И если ARM и RISCV на десктопах
> имеют какие-то шансы, то интель около 20 лет бредил tablet pc

RISCV на десктопах не имеет никаких шансов. От слова "совсем".
ARM - очень ограниченно, пока яббло играется с данной платформой.

Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

376. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (376), 30-Янв-21, 21:11 
> Так я о том же, что "жирные" ARM'ы - это уже не
> RISC по сути, а химера, которая сначала RISC агрегирует в макрооперации,
> потом их назад бьёт до микроопераций уже ядра.

На третий день Зоркий Глаз заметил что деление на RISC и CISC ни разу не бинарное.

> Внезапно в x86 на один набор команд тоже есть разные реализации. Две
> основных и несколько мелких.

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

> RISCV на десктопах не имеет никаких шансов. От слова "совсем".

А вот это я уже на моем десктопе как-нибудь решу без вас.

> ARM - очень ограниченно, пока яббло играется с данной платформой.

Мне от ябла ничего не нужно.

Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

356. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Ordu (ok), 30-Янв-21, 00:28 
> Полноценного планировщика операций нет. Весь пайплайнинг по сути ручной, ещё на этапе
> компиляции.

Дык что мешает этот пайплайнинг запилить?

> Просто потому, что основная прелесть RISC - как раз упрощение железного декодера
> и планировщика.

Ты думаешь, что если RISC-V имеет RISC в названии, то инженеры из уважения к этому названию не будут усложнять декодер и планировщик, запиливая туда спекулятивщину? Или я не правильно тебя понял?

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

Ответить | Правка | К родителю #350 | Наверх | Cообщить модератору

360. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 10:56 
> Дык что мешает этот пайплайнинг запилить?

Так же, как и с пресловутым танцором.
Вроде бы ничто не мешает - а погляди ж, они болтаются неудачно...

> Ты думаешь, что если RISC-V имеет RISC в названии, то инженеры из
> уважения к этому названию не будут усложнять декодер и планировщик, запиливая
> туда спекулятивщину?

Нет, я думаю, что это будет гораздо сложнее, чем построить таковые с CISC. Хотя бы в силу изначального размера команды в 32 бита сразу и относительной примитивности большинства этих команд. Придётся как в старших кортексах - сначала по заложенным паттернам мы конвертим этот RISC'овый бред в более удобоваримые для планирования макрооперации - ну, что удалось сконвертить, которые внезапно могут оказаться даже короче при записи, потом внезапно бьём это счастье назад уже на внутренние микрооперации для ядра, и только потом уже шедулим результат всей этой вакханалии. Естественно львиная доля шедулится без сбора в макрооперации, но это только дополнительно усложняет. Ещё немножко - и оно станет сложнее x86.


Ответить | Правка | К родителю #356 | Наверх | Cообщить модератору

377. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (376), 30-Янв-21, 21:13 
> Так же, как и с пресловутым танцором.

Именно поэтому и есть жирные OoO реализации и ARM и RISCV.
- Ни один смертный муж не может убить меня!
- Я не муж, ха!

Ответить | Правка | К родителю #360 | Наверх | Cообщить модератору

353. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 30-Янв-21, 00:11 
> Мне непонятно, что такого есть в RISC, что не позволит реализовать такое
> спекулятивное выполнение?

Его даже и реализуют. Топовые армы и даже ранние RV64 даже налетели на какой-то подвид спектра, внезапно. Но омномномный эксперт по отрасли кажется не слышал о такой ерунде и с уверенным видом гонит аки олень.

Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

364. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 11:06 
Топовые армы RISC имеют только на фронтенде. Дальше жуткая химера. Посмотрите архитектуру уже.
Ответить | Правка | Наверх | Cообщить модератору

378. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (376), 30-Янв-21, 21:15 
> Топовые армы RISC имеют только на фронтенде. Дальше жуткая химера. Посмотрите архитектуру уже.

Я то посмотрел, и в отличие от разогнавшегося оленя догадываюсь что деление на CISC и RISC не бинарное от слова вообще.

Ответить | Правка | Наверх | Cообщить модератору

352. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 30-Янв-21, 00:09 
> Кондишнлы внезапно - это не только переходы. Даже банальный сдвиг на бит
> с использованием флага переноса является кондишнлом.

У ARM с этим полный порядок например. У них очень круто сделано, в каком нибудь thumb2 возможны целые условные блоки с очень компактным кодированием условий на весь блок. В 32-бит условным может быть почти все угодно уже покомандово - это часть instruction set.

> Не говоря уже о специализированных инструкциях типа CMOVxx в x86. При работе того
> же сдвига и наличии далее зависимой от него команды - возникают две ветки исполнения.

И как показал пример, утупки из интеля не умеют в undo side effects, так что безопасность лихо улетает во времена Win95. И фича резко превращается в баг.

> RISC придётся стоять и ждать флага.

Продвинутые hi-performance рисковые ядра тоже умеют спекулятивщину.

> Нет у RISC спекулятивного выполнения.

Зависит от реализации. Хотят ядро попроще и поменьше - нет. Хотят пожирнее и пошустрее - есть. "Ух ты, а что, так можно было?"

> На то он и RISC. И предсказатели переходов сложные не могут возникнуть - неоткуда.

А вот это уже на усмотрение implementer'а что он там сделает.

> Это прерогатива CISCoRISC, которые могут разложить инструкции на конвеер,

Вы уже утомили с своим vaporware. Вот вся отрасль тупая, один вы умный. Очень убедительно. Ну тогда обставьте этих лохов, не? Если вам верить это как 2 байта переслать.

> Повторюсь. Кондишнлы - это не только переходы. Нет, в RISC - в
> основном, и это как раз та причина, по которой они не взлетают в реальных условиях.

Они уже мир захватили. Мобильных девайсов выпускается больше чем ваших x86 вместе взятых.

Ответить | Правка | К родителю #339 | Наверх | Cообщить модератору

362. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 10:59 
> Вы уже утомили с своим vaporware. Вот вся отрасль тупая, один вы
> умный. Очень убедительно.

Ну поспорьте с x86 тогда, что-ли. На котором именно что сидит "вся отрасль".
Уделом ARM'ов так и остаётся мобильный сегмент, где чистая производительность не важна и не интересна.
И всякая эмбедовка, где оно в основном в качестве спящей системы управления.
Даже RP на магистральных роутерах ушли с MIPS/ARM/whatever на x86, к чему бы это, не подскажете? :D
Просто внезапно на эти RP нагрузка стала жёсткая...

Ответить | Правка | Наверх | Cообщить модератору

368. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 11:17 
Для чистоты скажем, что на ARM конечно можно и суперкомпьютер слепить. Под конкретную задачу, где он применим. Но универсальности по производительности там не было и не будет.
Ответить | Правка | Наверх | Cообщить модератору

380. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (376), 30-Янв-21, 21:22 
> Для чистоты скажем, что на ARM конечно можно и суперкомпьютер слепить.

И даже слепили, насколько я помню.

Ответить | Правка | Наверх | Cообщить модератору

379. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (376), 30-Янв-21, 21:21 
> Ну поспорьте с x86 тогда, что-ли.

Где именно? Так то вон 80-ядерный монстр за $4k c EPYC'ом спорит вроде. И по скорости, и по ценам.

> На котором именно что сидит "вся отрасль".

Которая именно?
- Мобильные системы на ARM давно. Отдельные приветы таблет-ПЦу.
- МК опять же ARM в основном, немного 8-бит, RISCV стал появляться.

> Уделом ARM'ов так и остаётся мобильный сегмент, где чистая производительность не важна
> и не интересна.И всякая эмбедовка, где оно в основном в качестве спящей системы управления.

Может спящей, может не спящей. Зачем мне спать если я мотор кручу? Электричества вокруг завались, реалтайм отклик важен, а пара милливаттов на фоне мотора никому погоду не делает.

> Даже RP на магистральных роутерах ушли с MIPS/ARM/whatever на x86, к чему
> бы это, не подскажете? :D

Да кто его знает про какие вы там частности. Так то полно дизайнов энтерпрайз добра на чем угодно и x86 там совсем не в фаворе, просто потому что под него систему дизайнить - занятие проблемное и безблагодатное в общем случае.

> Просто внезапно на эти RP нагрузка стала жёсткая...

Это очень незначительный процент цифровых систем на планете.

Ответить | Правка | К родителю #362 | Наверх | Cообщить модератору

333. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 27-Янв-21, 23:49 
Ну и да, какого конвеера-то?
Как только встретился кондишнл - всё, нет больше конвеера, ждём да/нет/не знаю (чёрный юмор) от такового.
Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

355. "Android портирован для плат на архитектуре RISC-V"  +2 +/–
Сообщение от Анонис (?), 30-Янв-21, 00:23 
> Ну и да, какого конвеера-то?

Такого, который даже у простых RISC бывает. А у более сложных реализаций ядер и подавно.

> Как только встретился кондишнл - всё, нет больше конвеера, ждём да/нет/не знаю
> (чёрный юмор) от такового.

Вам никогда не приходило в бошку что деление на CISC и RISC ни разу не черно-белое и между 2 полюсами полно опций? И формально заявленый набор команд и фактическая реализация железа ворочающего ее - разные вещи.

Ну вон ARM cortex M умеет быть neuman в железе и софте. Или neuman в софте но гарвард с ibus и dbus в железе. Софту сие однако ж никак не видно и это эпиквин: скорость гарварда без долботни с адресными пространствами и ограничениями гарварда.

Ответить | Правка | Наверх | Cообщить модератору

363. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 30-Янв-21, 11:04 
> Вам никогда не приходило в бошку что деление на CISC и RISC
> ни разу не черно-белое

Внезапно это очевидно. Но проблема RISC в том, что там преднамеренно примитивизируется набор команд с целью упрощения декодирования и планировки, с переносом части таковых в статический анализ компилятором. Чтобы потом "фактически реализовать" сложное планирование - надо сначала попытаться провернуть этот фарш назад, а потом из получившейся мозайки, отдалённо напоминающей исходную собачку, попытаться нарезать аккуратные кубики для ядра. Что допустим старшие кортексы и делают, пытаясь хоть как-то догнать x86 по качеству планирования в рантайме.

Ответить | Правка | Наверх | Cообщить модератору

381. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (381), 30-Янв-21, 21:26 
> Внезапно это очевидно. Но проблема RISC в том, что там преднамеренно примитивизируется
> набор команд с целью упрощения декодирования и планировки, с переносом части
> таковых в статический анализ компилятором.

И как по мне это адский EPIC WIN! Компиляторы, в отличие от мельдониевых, свои баги чинят и воркэраунды выкатывают достаточно оперативно. Без адовых кернелмод воркэраундов и туповэйтинга годами с предложением купить пофикшеный ... новый проц.

> Чтобы потом "фактически реализовать" сложное планирование - надо сначала попытаться
> провернуть этот фарш назад, а потом из получившейся мозайки, отдалённо напоминающей
> исходную собачку, попытаться нарезать аккуратные кубики для ядра.
> Что допустим старшие кортексы и делают, пытаясь хоть как-то догнать x86 по
> качеству планирования в рантайме.

ЧСХ у них
- неплохо получается
- ядер на тот же кристалл больше
- tdp куда вменяемее
- меньше легаси и оверинженерии, все по делу

Ответить | Правка | Наверх | Cообщить модератору

384. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Онаним (?), 31-Янв-21, 12:38 
EPIC WIN превращается в EPIC FAIL там, где есть ветвление и зависимость от входных данных, то есть статический анализ ничего не даст. То есть чуть более, чем на всём коде, кроме линейных участков. Нет, есть задачи типа перемножения матриц, которые полностью линейны, но основная масса кода статическим анализом не оптимизируется.
Ответить | Правка | Наверх | Cообщить модератору

386. "Android портирован для плат на архитектуре RISC-V"  +/–
Сообщение от Аноним (-), 01-Фев-21, 04:26 
> EPIC WIN превращается в EPIC FAIL там, где есть ветвление и зависимость
> от входных данных, то есть статический анализ ничего не даст.

Да с хрена ли? См выше, OoO реализации - есть.

> То есть чуть более, чем на всём коде, кроме линейных участков. Нет,
> есть задачи типа перемножения матриц, которые полностью линейны, но основная масса
> кода статическим анализом не оптимизируется.

Угу, угу, "а шмель об этом не знает, и поэтому летает"

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру