Взаимодействие есть, в том плане, что отдельно взятые люди готовы говорить о том, что не попадает под NDA. Тем не менее, эмулятор вообще не переживает свои лучшие дни, всё равно всё упирается в закрытость МЦСТ. Да, вы можете прочитать его код, может открыть для себя что-то новое, а e2k есть чему удивлять. Но пользоваться им невозможно — из компиляторов у нас есть только утёкшая сборка 2015 года. Из операционных систем — можно скачать Astra Linux, из него как-то сгенерировать chroot, но там опять же нет компилятора.
Есть конечно обещания приоткрыть компилятор возможно в следующем году, но пока это всего-лишь обещания. Купить его для частного лица похоже невозможно — мне на письмо просто не ответили.
А вот почему у МЦСТ нет своего эмулятора? Ответ прост, он им не нужен. У них есть потактовая модель процессора и южного моста. У них есть симулятор на FPGA. Инженерам этого достаточно, чтобы разрабатывать новую итерацию Эльбруса. Но разработчикам прикладного софта это всё не подходит: FPGA стоят миллионы, а потактовая модель работает в 5 МГц.
Нуууу, кстати, компилятор Dalvik кода в Android уже очень давно. Он конечно не простой и собирает профиль работы приложения, продолжая перекомпилировать его даже после установки, но я не вижу как это не накладывается на существующий оптимизирующий компилятор.
Возможно, способ распространения Android приложений как раз таки лучше всего подходит Эльбрусу и вообще VLIW. Уже пробовали запускать программы скомпилированные под e2k-v4 на e2k-v5 и прирост только пропорциональный тактовой частоте. Хотя очевидно, что компиляция с -march=native была бы выгоднее. В v5 например самое крупное изменение — 128-битные регистры.
Кстати, интересен тот факт, что вот МЦСТ само собой самостоятельно разработали южный мост, разную переферию, но интерфейсы остались максимально приближенными к x86. Контроллер прерываний — APIC, сетевая карта — e1000. Ну это из того, что я расковырял дописывая в наш user-mode эмулятор поддержку system эмуляции.
>В случае VLIW, если компилятор что-то не смог (а его возможности в реальности крайне ограничены), то всё, аппаратура уже ничего не сможет сделать.
Я соглашусь. Это действительно так.
Но и Эльбрус сделан с расчётом на то, чтобы компилятор мог по максимуму забивать ШК. И спекулятивное исполнение, и предикаты, и я уже не говорю о DAM — таблице адресов разрешающей зависимость чтения и записи. Всё это на самом деле не делает Эльбрус «простым», но зато планировщик в компиляторе, да.
Тем не менее я не могу не восхищаться гением разработчиков его компилятора, который с каждой новой версией, но всё же ускоряет код. Даже на старых процессорах.
Я для публики поднял форк compiler-explorer с добавленной поддержкой lcc: ce.mentality.rip, играйтесь кто хотите.
Вообще в E2K вращаемые регистры практически основная причина головной боли в нашем с numas13 эмуляторе. Например, базированные регистры — это по сути вращаемое подпространство внутри и так вращаемых регистров. Собственно, на них вся аппаратная поддержка циклов и завязана, так как каждая новая итерация продвигает окно, а код продолжает обращаться к одним и тем же регистрам. Получается переименование регистров, на VLIW лад.
Архитектура транслятора QEMU просто не рассчитана на подобные действия и никто не знает что с этим делать.
Спекулятивное выполнение в e2k не совсем то же самое, о чём говорят подразумевая со Spectre/Meltdown. Это всего один бит у инструкции, который разрешает процессору игнорировать ошибку. От чтения по неправильному адресу в регистре не появится желаемой информации, но выставится единичка в двухбитный тег. По остальным инструкциям со спекулятивным режимом тег будет переноситься, а инструкции без него сгенерируют ошибку при доступе к такому регистру.
Защищенный режим в e2k есть и он реализован через расширение указателя с 64 бит до 128. В верхних 64 разрядах информация о размере массива и оффсете. В уже упомянутом двухбитном теге хранится и тип данных: указатель или число.
Интересная на самом деле технология, вот [тут](https://blog.handydev.com) блог человека, который её ковыряет и с помощью неё даже находит баги. И само собой краткая, но всё же документация от МЦСТ тоже [есть](http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter11.html).
В отношении RISC/CISC правдиво и обратное, что нет возможности использовать для параллелизма ту информацию, которая есть в исходном коде программы. Компилятор может быть постарается ради планировщика в железе, но это необязательно.
Впрочем я спорить не собираюсь, не люблю абстрактные обсуждения VLIW vs RISC vs CISC, да и приверженцем ни одной из них не являюсь.
А вы точно тот самый Armmaster, который был связан с Exagear? :)
OpenGL не только для геймдева, а так же он достаточно прост. Это вы ещё Vulkan не видели :)
Меня конечно уже поправили, что с GLSurfaceView не всё так просто, но тем не менее и геймдев, и время разработчиков выглядит как отмазка, потому что другой человек с Medium вам так сказал.
Статья не про дубовость. Человек разобрался в ARCore. Однако не удосужился всё же проверить как в принципе работает 3D на любом Android смартфоне и что там ничего сложного нет.
А можно без поиска библиотеки, просто накидать такую же сотню-две строчек на чистом GLES со стандартным GLSurfaceView? Вам не нужен AR чтобы выводить 3D объекты. Да вам даже OBJ файлы тут не нужны.
То что описано в статье -- очень неоптимально. В конце концов приложение просто не установится на телефон клиента, потому что приложение занимает сотню-два мегабайта, такова цена за очередной "фреймворк" и "давайте поищем библиотеку".
В случае ARCore так же высок шанс не получить картинку вовсе, потому что в нём, насколько мне известно, жёсткий белый список для устройств, которые поддерживают AR и для его задач это оправдано. Но не для ваших.
Собственно, вы сами уже заметили что ARCore нужен Android >7 и поддерживаемое устройство. Для того, что отобразить затекстуренный с обоих сторон прямоугольник.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Вот это вот.
ОС Эльбрус сейчас распространяется под x86_64 и насколько мне известно, собирается оно из тех же патченных сорцов, что и дистрибутив под e2k.
Я даже больше скажу, в этом исошнике под x86, вполне есть компилятор под e2k. Правда, не тот что lcc, а clang/llvm с патчем для e2k.
А вот права запрещать распространять они не имеют. То есть если кто-то получил модифицированные исходники под GPL, то он может свободно их опубликовать если захочет.
Что кстати отчасти правда. Опять же на «утёкшие» Linux и binutils можно спокойно посмотреть на моём GIt: git.mentality.rip/OpenE2K
Нельзя не упомянуть группу энтузиастов именующих себя e2k-dev(и я в их числе, ага), которые вручную портируют софт и отправляют его в апстрим.
Бывает, что некоторые сотрудники МЦСТ вполне публикуют свой софт и патчи. Например, недавно опубликовали патчи к rustc и LuaJIT.
Есть очень старые слухи, что оборонка-то как раз не против пойти навстречу, а РАН против. Не могу ничего сказать об их достоверности, но я бы не удивился.
Но мне кажется, что в данной ситуации очень большая удача уже в том, что ребятам не предъявлены обвинения в разглашении государственной тайны или в каком-нибудь неправомерном доступе к охраняемой информации
Собственно это причина по которой разработка эмулятора велась в тайне несколько месяцев. Но в конце концов, устав от такой ситуации, я выложил всё, и эмулятор, и исходный коды Linux и binutils(фактически на весь ассемблер), которые к нам попали.
С МЦСТ между прочим спрашивали каким образом были получены эти исходники. Я не скрывал, поэтому ответил честно. В общем-то судя по разговору, им было важно только то, что исходный код не был получен от них, а значит перед «Заказчиком» пришлось оправдываться другим людям.
Не забудут. Но вполне могут сосчитать за перспективную разработку, но не основную. Как например с LLVM/lccrt, Rust и Go.
Да, я не говорю что это плохо. Это достаточно здравое решение.
МЦСТ про эмулятор в курсе: Говорят оно есть где-то ещё
Взаимодействие есть, в том плане, что отдельно взятые люди готовы говорить о том, что не попадает под NDA. Тем не менее, эмулятор вообще не переживает свои лучшие дни, всё равно всё упирается в закрытость МЦСТ. Да, вы можете прочитать его код, может открыть для себя что-то новое, а e2k есть чему удивлять. Но пользоваться им невозможно — из компиляторов у нас есть только утёкшая сборка 2015 года. Из операционных систем — можно скачать Astra Linux, из него как-то сгенерировать chroot, но там опять же нет компилятора.
Есть конечно обещания приоткрыть компилятор возможно в следующем году, но пока это всего-лишь обещания. Купить его для частного лица похоже невозможно — мне на письмо просто не ответили.
А вот почему у МЦСТ нет своего эмулятора? Ответ прост, он им не нужен. У них есть потактовая модель процессора и южного моста. У них есть симулятор на FPGA. Инженерам этого достаточно, чтобы разрабатывать новую итерацию Эльбруса. Но разработчикам прикладного софта это всё не подходит: FPGA стоят миллионы, а потактовая модель работает в 5 МГц.
Причина такого решения — копировать x86-системы — на самом деле очевидна. Кто же будет писать драйвера под lintel? :)
А с ним, сам знаешь, всё запускается без изменений и каких-либо дополнительных драйверов.
Нуууу, кстати, компилятор Dalvik кода в Android уже очень давно. Он конечно не простой и собирает профиль работы приложения, продолжая перекомпилировать его даже после установки, но я не вижу как это не накладывается на существующий оптимизирующий компилятор.
Возможно, способ распространения Android приложений как раз таки лучше всего подходит Эльбрусу и вообще VLIW. Уже пробовали запускать программы скомпилированные под e2k-v4 на e2k-v5 и прирост только пропорциональный тактовой частоте. Хотя очевидно, что компиляция с
-march=nativeбыла бы выгоднее. В v5 например самое крупное изменение — 128-битные регистры.Кстати, интересен тот факт, что вот МЦСТ само собой самостоятельно разработали южный мост, разную переферию, но интерфейсы остались максимально приближенными к x86. Контроллер прерываний — APIC, сетевая карта — e1000. Ну это из того, что я расковырял дописывая в наш user-mode эмулятор поддержку system эмуляции.
ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/index.html
Я соглашусь. Это действительно так.
Но и Эльбрус сделан с расчётом на то, чтобы компилятор мог по максимуму забивать ШК. И спекулятивное исполнение, и предикаты, и я уже не говорю о DAM — таблице адресов разрешающей зависимость чтения и записи. Всё это на самом деле не делает Эльбрус «простым», но зато планировщик в компиляторе, да.
Тем не менее я не могу не восхищаться гением разработчиков его компилятора, который с каждой новой версией, но всё же ускоряет код. Даже на старых процессорах.
Я для публики поднял форк compiler-explorer с добавленной поддержкой lcc: ce.mentality.rip, играйтесь кто хотите.
>Точно :)
Когда Exagear у китайцев отвоёвывать будете?
Вообще в E2K вращаемые регистры практически основная причина головной боли в нашем с numas13 эмуляторе. Например, базированные регистры — это по сути вращаемое подпространство внутри и так вращаемых регистров. Собственно, на них вся аппаратная поддержка циклов и завязана, так как каждая новая итерация продвигает окно, а код продолжает обращаться к одним и тем же регистрам. Получается переименование регистров, на VLIW лад.
Архитектура транслятора QEMU просто не рассчитана на подобные действия и никто не знает что с этим делать.
Защищенный режим в e2k есть и он реализован через расширение указателя с 64 бит до 128. В верхних 64 разрядах информация о размере массива и оффсете. В уже упомянутом двухбитном теге хранится и тип данных: указатель или число.
Интересная на самом деле технология, вот [тут](https://blog.handydev.com) блог человека, который её ковыряет и с помощью неё даже находит баги. И само собой краткая, но всё же документация от МЦСТ тоже [есть](http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter11.html).
Впрочем я спорить не собираюсь, не люблю абстрактные обсуждения VLIW vs RISC vs CISC, да и приверженцем ни одной из них не являюсь.
А вы точно тот самый Armmaster, который был связан с Exagear? :)
Меня конечно уже поправили, что с GLSurfaceView не всё так просто, но тем не менее и геймдев, и время разработчиков выглядит как отмазка, потому что другой человек с Medium вам так сказал.
Статья не про дубовость. Человек разобрался в ARCore. Однако не удосужился всё же проверить как в принципе работает 3D на любом Android смартфоне и что там ничего сложного нет.
>Начинаем искать библиотеку.
А можно без поиска библиотеки, просто накидать такую же сотню-две строчек на чистом GLES со стандартным GLSurfaceView? Вам не нужен AR чтобы выводить 3D объекты. Да вам даже OBJ файлы тут не нужны.
То что описано в статье -- очень неоптимально. В конце концов приложение просто не установится на телефон клиента, потому что приложение занимает сотню-два мегабайта, такова цена за очередной "фреймворк" и "давайте поищем библиотеку".
В случае ARCore так же высок шанс не получить картинку вовсе, потому что в нём, насколько мне известно, жёсткий белый список для устройств, которые поддерживают AR и для его задач это оправдано. Но не для ваших.
Собственно, вы сами уже заметили что ARCore нужен Android >7 и поддерживаемое устройство. Для того, что отобразить затекстуренный с обоих сторон прямоугольник.
Вот это вот.
ОС Эльбрус сейчас распространяется под x86_64 и насколько мне известно, собирается оно из тех же патченных сорцов, что и дистрибутив под e2k.
Я даже больше скажу, в этом исошнике под x86, вполне есть компилятор под e2k. Правда, не тот что lcc, а clang/llvm с патчем для e2k.
Для желающих потыкать я уже давно держу Compiler Explorer
Что кстати отчасти правда. Опять же на «утёкшие» Linux и binutils можно спокойно посмотреть на моём GIt: git.mentality.rip/OpenE2K
Нельзя не упомянуть группу энтузиастов именующих себя e2k-dev(и я в их числе, ага), которые вручную портируют софт и отправляют его в апстрим.
Бывает, что некоторые сотрудники МЦСТ вполне публикуют свой софт и патчи. Например, недавно опубликовали патчи к rustc и LuaJIT.
Во всяком случае есть ещё numas, а он вообще в другой стране. Что впрочем судя по последним новостям никогда проблемой не было.
Кто знает в каких списках мы уже находимся.
У нас уже немного поддерживается набор инструкций ещё невышедшего Эльбрус-16С. Проверять было не на чем, кроме как компилятора, но тем не менее.
Надо бы уже дописать и опубликовать статьюСобственно это причина по которой разработка эмулятора велась в тайне несколько месяцев. Но в конце концов, устав от такой ситуации, я выложил всё, и эмулятор, и исходный коды Linux и binutils(фактически на весь ассемблер), которые к нам попали.
С МЦСТ между прочим спрашивали каким образом были получены эти исходники. Я не скрывал, поэтому ответил честно. В общем-то судя по разговору, им было важно только то, что исходный код не был получен от них, а значит перед «Заказчиком» пришлось оправдываться другим людям.