The OpenNET Project / Index page

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



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

Оглавление

Microsoft открыл CHERIoT, аппаратное решение для повышения безопасности кода на языке Си, opennews (??), 01-Мрт-23, (0) [смотреть все]

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


229. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от Nope (?), 02-Мрт-23, 13:11 
Главный прогиб под C - это RISC-V, где нет флагов.
Соответственно весь тот геморой, который нужен для сложения числе размера в два раза больше слова реализуется один в один как C код, сложение, сравнение и т.д., без всяких add adc
Ответить | Правка | Наверх | Cообщить модератору

230. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (235), 02-Мрт-23, 13:21 
Уже объясняли о вреде этих флагов на переупорядочивание выполнения команд.
Ответить | Правка | Наверх | Cообщить модератору

244. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от непох2 (?), 02-Мрт-23, 14:43 
> Уже объясняли о вреде этих флагов на переупорядочивание выполнения команд.

Стоит уточнить, что мешают не флаги, а только когда эти флаги общие и/или помещены в один логический регистр (который можно push/pop/load/store/move).

А вот отсутствие ADC, SBB и т.п. в RISC-V = это просто сознательная ущербность ради экономии "на спичках", что действительно было разумно для исходного целевого сегмента этой ISA (low-end ЦПУ и микроконтроллеров).

Технически ADC/SBB и прочее прекрасно реализуется без общего флага переноса, просто дополнением каждого регистра своими carry/overflow флагами.
Соответственно, тогда ADD/SUB всегда формируют carry в целевом регистре, а ADC/SBB берут его из источников.
MOV копирует между регистрами, а LOAD очищает...

Поэтому, RISC-V ISA - это недодуманное, недопеределанное УГ, которое более-менее подходит для low-end, а его натягивание на широкий сегмент и high-end создаст массу проблем лет на 20 (как было c x86), в том числе с безопасностью/дырявостью.

Кто-то это уже это понял, но большинство просто потребляют рекламную информацию.

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

246. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Вечно недовольный аноним (?), 02-Мрт-23, 15:31 
> просто дополнением каждого регистра своими carry/overflow флагами.

Это ваши фантазии или это где-то так сделано?

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

251. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от x3who (?), 02-Мрт-23, 19:03 
Если это нигде не сделано - это не значит, что не нужно. Реализация этих флагов проста, а выподвыверты чтобы их обойти будут стоить дополнительных тактов ЦПУ.
Ответить | Правка | Наверх | Cообщить модератору

297. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от аффтар (?), 03-Мрт-23, 12:53 
Штеуд сделал это 10 лет назад в таком виде https://en.wikipedia.org/wiki/Intel_ADX

Как-то иначе в рамках x86 примерно не возможно.

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

307. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (307), 04-Мрт-23, 09:13 
Ты сам-то эту страницу читал? Где там написано про бред анона с кэри\оверфлоу флагом для каждого регистра.
Ответить | Правка | Наверх | Cообщить модератору

331. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 08:43 
> Ты сам-то эту страницу читал? Где там написано про бред анона с
> кэри\оверфлоу флагом для каждого регистра.

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

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

272. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от _kp (ok), 02-Мрт-23, 21:29 
Ну и много ли хотя бы  в 32х битном коде на ассемблере работы с флагами вне операций сравнения? Если без них можно обойтись, то и проблемы нет.

Для многих процессоров, возьмем для примера cortex m3 stm33, можно написать весь код на Си, включая таблицы векторов прерываний. Единственное останется несколько ассемблерных макросов для барьеров, прерываний, и подобных мелочей.

Сейчас на ассемблере не пишут, и вполне можно оптимизировать процессор под код из под компилятора.

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

296. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от аффтар (?), 03-Мрт-23, 12:49 
Как уже многократно было сказано: RISC-V ISA исходно проектировалась для low-end ЦПУ и микроконтроллеров.
Для этого она (система команд) неплохо.
Собственно, привыкши к мопедам m3 и stm, вы не видите проблем и не чувствуете дискомфорта.

Но для high-end ЦПУ, без необходимости экономии на спичках, система команд RISC-V неудобна, мягко говоря. И жизнь продолжает это иллюстрировать/доказывать.

--

Ассемблер тут не критерий, и по-сути вообще не причем.
В актуальных компиляторах есть развитые интринсики, поэтому всё чаще можно написать переносимый код, при этом не менее эффективный/быстрый чем на asm.

Аналогично с флагами - важны не сами флаги, а наличие в ISA и железе эффективного механизма контроля переполнений, сложения/вычитания "столбиком" (с переносом/заёмом), широкого умножения и деления. Поэтому у штеуда, кроме унаследованной ADC есть новая ADX, а в компиляторах всяческие __builtin_add_overflow(), __builtin_addcll() и _addcarry_u64().

Но обойтись можно, проблем нет, просто работает медленнее.
В этом весь RISC-V = много чего недодумано, недопеределано, а тут мы рыбу заворачивали, но хайпово...

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

332. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 08:47 
> Но для high-end ЦПУ, без необходимости экономии на спичках, система команд RISC-V
> неудобна, мягко говоря. И жизнь продолжает это иллюстрировать/доказывать.

Для high-end cpu мы никогда не видим их систему команд и нам так то похрен. И для компилера это лишь некий интерфейс а реально это бэкэнд. И никакие carry флаги нам нахрен не вперлись, их проверка требует команды добавлять и код тормозит.

> код, при этом не менее эффективный/быстрый чем на asm.

Ну и вот у RISCV тоже всякие SIMD расширения появляются.

> ADC есть новая ADX, а в компиляторах всяческие __builtin_add_overflow(), __builtin_addcll()
> и _addcarry_u64().

Нюансик в том что это __builtin* напрочь не портабельно, еще хуже интринсиков.

> В этом весь RISC-V = много чего недодумано, недопеределано, а тут мы
> рыбу заворачивали, но хайпово...

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

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

341. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от аффтар (?), 08-Мрт-23, 23:43 
> Для high-end cpu мы никогда не видим их систему команд и нам
> так то похрен. И для компилера это лишь некий интерфейс а
> реально это бэкэнд. И никакие carry флаги нам нахрен не вперлись,
> их проверка требует команды добавлять и код тормозит.

Не стоит повторять/пересказывать чужие пояснения, не понимая их сути и/или контекста.

Без carry и overflow флагов вы не сможете эффективно реализовать ни арифметику с широкими числами, ни контроль переполнения.
Конечно можно с дополнительными командами, проверками и ветвлениями - просто медленнее.
Либо можно сказать что это редкие кейсы и нам на них плевать, и для low-end и микроконтроллеров это действительно почти не нужно.

И мешают флаги OoO-выполнению, только если являются общими, т.е. вносят дополнительные "спайки" в зависимости.
Если же флаги персонализировать для каждого регистра (в ISA, либо в микроархитектуре), то никакой код они тормозить не будут (кроме явных зависимостей, например при условных переходах или сложении с переносом).

> Ну и вот у RISCV тоже всякие SIMD расширения появляются.

И что?
Но в бижутерии всегда широкий ассортимент, в том числе бус.

>> ADC есть новая ADX, а в компиляторах всяческие __builtin_add_overflow(), __builtin_addcll()
>> и _addcarry_u64().
> Нюансик в том что это __builtin* напрочь не портабельно, еще хуже интринсиков.

Отсылка к нюансам предполагает знание матчасти, хотя-бы базовой формальной части.
Для понимания, исторически префикс __builtin используется в GCC для встраиваемых псевдо-функций (интринсиков), поддержка которых реализуется внутри компилятора.
А термин intrinsic был введен с подачи штеуда и мелко-мягких, при рекламе компиляторов умеющих в MMX без asm-вставок.

Как правило, интринсики жестко привязаны к конкретной архитектуре.
А builtin-ы является формой реализации интринсиков в GCC и clang, при этом существенная их часть переносима между архитектурами (в особенности те, о которых весь речь).

>> В этом весь RISC-V = много чего недодумано, недопеределано, а тут мы
>> рыбу заворачивали, но хайпово...
> Зато в x86 столько всего напродумано что до сих пор сотни легаси
> таскают, вплоть до 16 битного режима и чудесатых надписей в UEFI-программах
> о том что они в DOS работать не могут. Правда UEFI
> и сам то этот DOS запустить иной раз уже и не
> может для начала, но легаси штука злая.

Так в этом-то и дело, что для RISC-V декларируется что пытались допеределать по-уму.
А получилось недодуманное УГ для low-end, которое всячески пиарят, разукрашивают и впаривают под вывеской "гениальной простоты".

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

346. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 13-Мрт-23, 17:10 
> Не стоит повторять/пересказывать чужие пояснения, не понимая их сути и/или контекста.

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

> Без carry и overflow флагов вы не сможете эффективно реализовать ни арифметику
> с широкими числами, ни контроль переполнения.

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

> Конечно можно с дополнительными командами, проверками и ветвлениями - просто медленнее.

Вообще-то сколь-нибудь явные проверки этих флагов и различение разных случаев как раз и требуют добавочных команд впихнуть. А прикиньте, код который допустим жестко задефайнил что там урезается по mod 2^N так то сильно оптимальнее выходит, как ни крути. И половине кода вот именно этого и хотелось. Самого критичного как раз, типа кодеков, крипты, и тому подобной интенсивной математики - вот как раз чтобы там не было лишних операций. Но это вон те хотели, а вот эти - простреливали пятки такой механикой не специально. Просто не было халявного способа проверить переполнение типа. Даже в хрусте не смогли, так что это в дебаг билдах только, с соответствующей просадкой перфоманса. Да и в сях это поймать можно но только *san всякими, которые тоже по скорости ни разу не халявны.

> Либо можно сказать что это редкие кейсы и нам на них плевать,
> и для low-end и микроконтроллеров это действительно почти не нужно.

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

> И мешают флаги OoO-выполнению, только если являются общими, т.е. вносят дополнительные
> "спайки" в зависимости.

Опять же хорошая штука должна быть масштабируемой. ARM это очень наглядно показал. У этих есть все - от 8 ногого таракана до серверных процов. При том весьма непозорно. RISCV пытается быть чем-то таким, но более opensource friendly. Это - масштабирауемая экосистема.

> Если же флаги персонализировать для каждого регистра (в ISA, либо в микроархитектуре),
> то никакой код они тормозить не будут (кроме явных зависимостей, например
> при условных переходах или сложении с переносом).

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

> И что?
> Но в бижутерии всегда широкий ассортимент, в том числе бус.

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

> Отсылка к нюансам предполагает знание матчасти, хотя-бы базовой формальной части.

А это все есть, внезапно. Builtin это загоны конкретного компилера. На это вообще нет ни малейших намеков на стандарты. С интринсиками хоть какое-то подобие потуг этого, не то чтобы сильно успешное но не builtin'ам про это вещать.

> (интринсиков), поддержка которых реализуется внутри компилятора.

Исторически, SIMD вообще не существовал, если уж ворошить прошлое. Точнее, существовал  но совсем не так как вы себе это представляете, венцом творения был SWAR, который так то не требует никаких интринсиков вообще.

> А термин intrinsic был введен с подачи штеуда и мелко-мягких, при рекламе
> компиляторов умеющих в MMX без asm-вставок.

Представляете, даже эта парочка изредка может выдавать довольно здравые идеи?!

> Как правило, интринсики жестко привязаны к конкретной архитектуре.

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

> А builtin-ы является формой реализации интринсиков в GCC и clang, при этом
> существенная их часть переносима между архитектурами (в особенности те, о которых
> весь речь).

И тем не менее это нестандартно от слова вообще и лок на 2 конкретных компилера, что не круто.

> Так в этом-то и дело, что для RISC-V декларируется что пытались допеределать по-уму.

И при этом у них были довольно сложные гибридные соображения, сильно отличные от ваших. Это было о создании универсальной экосистемы типа ARMовской. Там немного другие соотношения и приходится учитывать интересы разных участников. Чтобы они все стали заинтересованы в этой экосистеме.

> А получилось недодуманное УГ для low-end, которое всячески пиарят, разукрашивают и впаривают
> под вывеской "гениальной простоты".

Да вот понимаете, если что-то в low end хорошо работает, с должным обвесом и апгрейдами оно потом и в десктопно-серверном достаточно непозорно смотрится по мипсам на ватт и прочем. А обрубить допустим x86 до мелочи - интель с таблет пц сколько пытался? Лет 20? А воз и ныне там. За это время ARM и Goole нишу заняли и поделили без вон тех. От чего у wintel'а плохо скрываемый батхерт. Что атомы, что винмобил, два фэйла, но пыхтели знатно.

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

337. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 10:26 
> Главный прогиб под C - это RISC-V,

Да вот кстати Cortex M для сишника так то поудобней RISCV. Я так понимаю что RISCV совсем без асмового стартапа тяжко поднять, а Cortex M вполне реально - я еще и проверял. Да в самом самом начале сишка нестандартный, пока он (сам себе!) BSS/RWDATA не инициализирует. Но сам чип операбелен и ничего враждебного сишке не делает. И сразу юзабелен сишным кодом.

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

> где нет флагов.

Да и болт с ними, обычно ими никто все равно не пользовался в арифметике особо, потому что их проверка время и код требует.

> Соответственно весь тот геморой, который нужен для сложения числе размера в два
> раза больше слова реализуется один в один как C код, сложение, сравнение и т.д.,
> без всяких add adc

А вы мне в XXI веке на асме чтоли прогать предлагаете? Ага, вот ща. Сейчас даже фирмварь китайского фонарика на аттини - на сишке, и ниипет. Это при том что там флеша 4-8 кило на все.

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

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

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




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

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