The OpenNET Project / Index page

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



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

Оглавление

Релиз ядра Linux 4.19, opennews (ok), 22-Окт-18, (0) [смотреть все]

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


51. "Безопасность Эльбрусов"  +4 +/
Сообщение от Аноним (51), 22-Окт-18, 14:46 
Эх, Михаил! Я б и рад в сабж поверить, но с несвободным компилятором как-то наивно.
Подвижки хотя б по back-end'у есть хоть какие-то? Ладно front-end имеющийся не открыть, но машинозависимую часть могли бы. Но, судя по одному интервью, не особо стремятся.
А это нивелирует претензии на безопасность: кто-то возьмётся за независимый (!) аудит LCC?
Ответить | Правка | Наверх | Cообщить модератору

67. "Безопасность Эльбрусов"  +1 +/
Сообщение от Michael Shigorinemail (ok), 22-Окт-18, 16:01 
> Эх, Михаил! Я б и рад в сабж поверить, но с несвободным
> компилятором как-то наивно.

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

> Подвижки хотя б по back-end'у есть хоть какие-то? Ладно front-end
> имеющийся не открыть, но машинозависимую часть могли бы. Но, судя
> по одному интервью, не особо стремятся.

Они рассматривают компилятор как часть аппаратуры по сути, причём с существеннейшим know how в оптимизаторе (это та часть, которую не смог интел для итаника -- помимо решения проблемы бинарной совместимости с "наследством" x86).

И с рассекречиванием СК есть грабелька: это собственность не только МЦСТ (но понимание, что надо двигаться в этом направлении, есть -- осталось всего ничего, так и сделать).

> А это нивелирует претензии на безопасность: кто-то возьмётся
> за независимый (!) аудит LCC?

Ну скажем так, я бы такую команду собрал оперативно, был бы заказчик.  Пока остаётся полагаться на тех, кто это смотрит для МО (во избежание устаревших комментариев про "решал" -- нам в альтераторе, который вообще на схеме написан, нашли несколько реальных проблем; с 2014 наконец-то взялись за голову).

Только в любом случае вся эта тема упирается в доверенный компилятор -- и для gcc/x86 тоже, что характерно.

PS: спасибо, очень дельный комментарий.

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

72. "Безопасность Эльбрусов"  +1 +/
Сообщение от Andrey Mitrofanov (?), 22-Окт-18, 16:32 
> Только в любом случае вся эта тема упирается в доверенный компилятор --
> и для gcc/x86 тоже, что характерно.

Местами хоть уже не в бинари. http://bootstrappable.org/

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

76. "Безопасность Эльбрусов"  +/
Сообщение от Аноним (71), 22-Окт-18, 16:53 
>И с рассекречиванием СК есть грабелька: это собственность не только МЦСТ (но понимание, что надо двигаться в этом направлении, есть -- осталось всего ничего, так и сделать).

А что, тогда получается, что при засекреченной системе команд, для Эльбруса нет Ассемблера?

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

78. "Безопасность Эльбрусов"  –1 +/
Сообщение от Michael Shigorinemail (ok), 22-Окт-18, 17:01 
> А что, тогда получается, что при засекреченной системе команд,
> для Эльбруса нет Ассемблера?

Есть и ассемблер (и cc -S), и дизассемблер -- и даже JTAG на 4.4... но по бумагам -- засекречены и система команд, и её кодировка.

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

188. "Безопасность Эльбрусов"  +1 +/
Сообщение от Аноним (188), 24-Окт-18, 20:53 
Как обычно - "такие приборы, но вам мы их не покажем". А потом оказывается что Такие Приборы годятся только на то чтобы предприятие по конверсии перешло к выпуску кастрюль...
Ответить | Правка | Наверх | Cообщить модератору

187. "Безопасность Эльбрусов"  +1 +/
Сообщение от Аноним (188), 24-Окт-18, 20:51 
> промежуточного представления, в прошлый раз не хватило и оптимизировать получалось на
> порядок хуже.

А конструктивно и плодотворно поработать, пардон, с апстримом, вместо наворачивания требований NDA и прочих *удизмов - не того?

> Они рассматривают компилятор как часть аппаратуры по сути,

Удачи в этом начинании. Трансмета крузо приветы передавал.

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

При том это их know how настолько всем надо, что только и удается что бюджетникам всучивать, занимаясь по сути попилом бюджета. А остальные в результате просто покупают более вменяемые железки с более вменяемыми компилерами и разработчиками. И таки даже побиваемые камнями интелы и амды поддержку своих железок в GCC нынче сами несут первым делом. Понимая что без компилера их камни даром никому не. И даже из интела дурь с ICC уже повыветрилась в целом.

> осталось всего ничего, так и сделать).

При том судя по темпам - это займет годиков 30.

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

Вообще-то в таких вещах по состоянию на сейчас должен быть заинтересован сам производитель CPU. Кроме случая когда он о...вшая морда, тягающая деньги из бюджета на свой хлам и прикрывающаяся левыми отмазками. Просто глядя на хотя-бы китайцев, которые почему-то NDA не страдают, в апстримы комитят, и вообще, зарубаются на general markets. Не рекордной производительностью так ценой. А не ставят бюджет своей страны на бабки.

> и для gcc/x86 тоже, что характерно.

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

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

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

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




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

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