Исходное сообщение
"Безопасность Эльбрусов" Отправлено Michael Shigorin, 22-Окт-18 16:01
> Эх, Михаил! Я б и рад в сабж поверить, но с несвободным > компилятором как-то наивно. Это да, болючая штука.  Но сейчас вроде опять взялись и за gcc -- может, в нынешнем уже хватает информации о циклах ниже промежуточного представления, в прошлый раз не хватило и оптимизировать получалось на порядок хуже. > Подвижки хотя б по back-end'у есть хоть какие-то? Ладно front-end > имеющийся не открыть, но машинозависимую часть могли бы. Но, судя > по одному интервью, не особо стремятся. Они рассматривают компилятор как часть аппаратуры по сути, причём с существеннейшим know how в оптимизаторе (это та часть, которую не смог интел для итаника -- помимо решения проблемы бинарной совместимости с "наследством" x86). И с рассекречиванием СК есть грабелька: это собственность не только МЦСТ (но понимание, что надо двигаться в этом направлении, есть -- осталось всего ничего, так и сделать). > А это нивелирует претензии на безопасность: кто-то возьмётся > за независимый (!) аудит LCC? Ну скажем так, я бы такую команду собрал оперативно, был бы заказчик.  Пока остаётся полагаться на тех, кто это смотрит для МО (во избежание устаревших комментариев про "решал" -- нам в альтераторе, который вообще на схеме написан, нашли несколько реальных проблем; с 2014 наконец-то взялись за голову). Только в любом случае вся эта тема упирается в доверенный компилятор -- и для gcc/x86 тоже, что характерно. PS: спасибо, очень дельный комментарий.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Эх, Михаил! Я б и рад в сабж поверить, но с несвободным >> компилятором как-то наивно. > Это да, болючая штука. Но сейчас вроде опять взялись и за > gcc -- может, в нынешнем уже хватает информации о циклах ниже > промежуточного представления, в прошлый раз не хватило и оптимизировать получалось на > порядок хуже. >> Подвижки хотя б по back-end'у есть хоть какие-то? Ладно front-end >> имеющийся не открыть, но машинозависимую часть могли бы. Но, судя >> по одному интервью, не особо стремятся. > Они рассматривают компилятор как часть аппаратуры по сути, причём с существеннейшим know > how в оптимизаторе (это та часть, которую не смог интел для > итаника -- помимо решения проблемы бинарной совместимости с "наследством" x86). > И с рассекречиванием СК есть грабелька: это собственность не только МЦСТ (но > понимание, что надо двигаться в этом направлении, есть -- осталось всего > ничего, так и сделать). >> А это нивелирует претензии на безопасность: кто-то возьмётся >> за независимый (!) аудит LCC? > Ну скажем так, я бы такую команду собрал оперативно, был бы заказчик. > Пока остаётся полагаться на тех, кто это смотрит для МО > (во избежание устаревших комментариев про "решал" -- нам в альтераторе, который > вообще на схеме написан, нашли несколько реальных проблем; с 2014 наконец-то > взялись за голову). > Только в любом случае вся эта тема упирается в доверенный компилятор -- > и для gcc/x86 тоже, что характерно. > PS: спасибо, очень дельный комментарий.
	Введите код, изображенный на картинке: