https://www.opennet.ru/opennews/art.shtml?num=54635

Ребят, вас ждет та же участь ну и плюс на бутылку посадят)

вас ждет та же участь

МЦСТ настолько не в курсе, что, как я понял, само дало авторам доступ к машинам, а Горшенин и Маркин (оба сотрудники МЦСТ, второй здесь на форуме есть, кастовать не буду) у себя в социалках повесили ссылку на сюда и что-то недовольства не высказывают.

Они были настолько в курсе, что знали об этом с самого начала. Впрочем МЦСТ – настоящие инженеры и относятся с пониманием.

Со времени публикации ни одного разговора о том, что эмулятор им хоть сколько нибудь мешается не было. Между прочим, даже намекнули на Elbrus Tech Day.

Недовольство было не в мою сторону, скорее в сторону Астры по поводу слива binutils, но это их проблемы и что они с этим будут делать нас уже касается мало.

binutils был слит Астрой и об этом написано в новости.

Можете делать с этим что захотите, мы вот эмулятор написали.

Какие-то люди с Германии написали очень поверхностную документацию на кодировку: https://github.com/nrdmn/elbrus-docs.

Ребята молодцы!

А вот некоторым сотрудникам МЦСТ должно быть очень стыдно. Дайте хоть документацию людям, которые делают за вас вашу работу. Детский сад. Прятать систему команд процессора… В 21ом веке. Цеховики.

Это не от МЦСТ зависит, а от разрешения заказчика и тот, если верить Горшенину и не против, но несколько неспешен.

интересно, Форт взлетит на Элбрусе? если ты понимаешь о чём это я? ;)

Чорт! ты вообще понимаешь почему Форт на х86 упал на взлете? Там же переход на переходе и переходом погоняет. Шитый код, деточка, дается не даром… увы

МЦСТ-R1000 вроде бы «нормальный» (не VLIW)

Ну да, SPARC у нас уже нормальным стал… Эльбрус побыстрее будет, причем без особых ухищрений и оптимизаций. Так что Отечество не в опасности, можно спать дальше

специалисты-компиляторщики МЦСТ считают фреймворки GCC и LLVM заведомо не очень подходящими для реализации всего потенциала архитектуры Эльбрус

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

если я не прав, то приведите пример области применения, в которой мы имеем шанс увидеть «реализацию всего потенциала архитектуры Эльбрус»

ПРО, не?

ничо не понял. ты намекаешь, что классический x86 не умеет в jmp/call по ссылке?

есть ещё вот такое:

https://habr.com/ru/company/badoo/blog/428878/

SIMD в том виде, в котором его привыкли видеть разработчики, а именно удобным в решении специфических задач

Какой SIMD, в каком виде, в виде билтинов что ли?
Там все векторные команды есть.
Лично мне неясно почему вещественные во всех каналах реализовали, а целочисленные в одном есть в другом нет как по остаточному принципу, он во многом потому в тестах и сосет что во всяких там библиотеках вещественных вычислений то не так и много.

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

Если мы работаем над 8С, то значит и 4С косвенно будет работать.

Почему косвенно? Оно прямо будет работать, заявлена двоичная совместимость

Я намекаю (да чо уж там - прямо говорю) на то, что если у тебя каждый несколько инструкций завершает переход, то это для любой современной архитектуры является адом. Кеш, он не бездонный, знаешь ли, конвейер сбрасывать - это тоже стоит денег, но наполнять - еще дороже. А Форт… у него такой код, переход на переходе. Зато очень компактненько и вообще, можно испытать интеллектуальный оргазм, глядя на

А я как сказал?

А вы сказали «косвенно», хотя по факту - «прямо»

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

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

Над e2k-v3 ней прямо говоря никто не работал, потому что процессора у нас нет

Задержки там такие же как в 8С вся разница (с точки зрения архитектуры) - в пятый юнит помоему докинули команд с плавающей точкой и все. в остальном это тот же 4С.

А у вас есть актуальное описание стандарта на векторные расширения для RISC-V? Поделитесь ссылкой?

А, так ты про риск пять. А я не так понял.

Задержки нам не принципиальны. :)

Насколько я помню, когда у нас был ПК на Э8, то дистр там стоял старый, собранный под Э4, а компилятор мы обновили и он норм собирал под Э8 и бинари вполне работали

Ну круто, я этот момент даже упомянул в своём комментарии. И что?

Да ничего, считай что не заметил этого или затупил, посчитав что тебе это не известно

чот кто-то явно гонит. про фатальную несовместимость «кэша» и команды перехода.

вот первый попавшийся исполняемый, претензиев по его работе нет на современных процах (у вас тоже наверняка он есть):

Дизассемблирование раздела .plt:

000000000002d020 endgrent@plt-0x10: 2d020: ff 35 e2 7f 0e 00 pushq 0xe7fe2(%rip) # 115008 <o_options@@Base+0x1888> 2d026: ff 25 e4 7f 0e 00 jmpq *0xe7fe4(%rip) # 115010 <o_options@@Base+0x1890> 2d02c: 0f 1f 40 00 nopl 0x0(%rax)

000000000002d030 endgrent@plt: 2d030: ff 25 e2 7f 0e 00 jmpq *0xe7fe2(%rip) # 115018 <endgrent@GLIBC_2.2.5> 2d036: 68 00 00 00 00 pushq $0x0 2d03b: e9 e0 ff ff ff jmpq 2d020 endgrent@plt-0x10

000000000002d040 __ctype_toupper_loc@plt: 2d040: ff 25 da 7f 0e 00 jmpq *0xe7fda(%rip) # 115020 <__ctype_toupper_loc@GLIBC_2.3> 2d046: 68 01 00 00 00 pushq $0x1 2d04b: e9 d0 ff ff ff jmpq 2d020 endgrent@plt-0x10

000000000002d050 iswlower@plt: 2d050: ff 25 d2 7f 0e 00 jmpq *0xe7fd2(%rip) # 115028 <iswlower@GLIBC_2.2.5> 2d056: 68 02 00 00 00 pushq $0x2 2d05b: e9 c0 ff ff ff jmpq 2d020 endgrent@plt-0x10

000000000002d060 sigprocmask@plt: 2d060: ff 25 ca 7f 0e 00 jmpq *0xe7fca(%rip) # 115030 <sigprocmask@GLIBC_2.2.5> 2d066: 68 03 00 00 00 pushq $0x3 2d06b: e9 b0 ff ff ff jmpq 2d020 endgrent@plt-0x10

000000000002d070 __snprintf_chk@plt: 2d070: ff 25 c2 7f 0e 00 jmpq *0xe7fc2(%rip) # 115038 <__snprintf_chk@GLIBC_2.3.4> 2d076: 68 04 00 00 00 pushq $0x4 2d07b: e9 a0 ff ff ff jmpq 2d020 endgrent@plt-0x10

000000000002d080 free@plt: 2d080: ff 25 ba 7f 0e 00 jmpq *0xe7fba(%rip) # 115040 <free@GLIBC_2.2.5> 2d086: 68 05 00 00 00 pushq $0x5 2d08b: e9 90 ff ff ff jmpq 2d020 endgrent@plt-0x10

000000000002d090 getservent@plt: 2d090: ff 25 b2 7f 0e 00 jmpq *0xe7fb2(%rip) # 115048 <getservent@GLIBC_2.2.5> 2d096: 68 06 00 00 00 pushq $0x6 2d09b: e9 80 ff ff ff jmpq 2d020 endgrent@plt-0x10

000000000002d0a0 wcscmp@plt: 2d0a0: ff 25 aa 7f 0e 00 jmpq *0xe7faa(%rip) # 115050 <wcscmp@GLIBC_2.2.5> 2d0a6: 68 07 00 00 00 pushq $0x7 2d0ab: e9 70 ff ff ff jmpq 2d020 endgrent@plt-0x10

Ну ёлы-палы! Я писал и кэш и конвейер. Если промах при кэшировании это досадная неприятность, то переход куда-то в е*еня заставляет сбрасывать весь конвейер, что вообще говоря - фаталити. А косвенный шитый код - это просто переход на каждый примитив, мимо кэша может и не промахнется, но почти наверняка за конвейер выскочит.

В С переход существенно реже должен встречаться (в кодах процессора, я имею ввиду), чем в каждой третьей команде (ну или около того, зависит от Форт-интерпретатора). Может с годами всё конкретно поменялось, но мне никаких прорывов по этой части на глаза не попадалось. Да и сомнительно - для контроллеров разных мелких штука годная

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

У меня, конкретно в ядре, где-то каждая 12-13 команда, при том что большая часть - условные переходы, которые «то ли будет, то ли нет, то ли дождик то ли снег» и немного предсказываются плюс ко всему, так что в реальной реальности на коде С процессор делает как бы не в десяток раз меньше сбросов конвейера и прочей неприятной мути:

bydymtydym@T480:/tmp$ grep -P "j..?\w" vm.S | wc -l
208985
bydymtydym@T480:/tmp$ wc -l vm.S 
2582598 vm.S

Да, я про RISC-V. Меня больше всего позабавила статья: https://www.sigarch.org/simd-instructions-considered-harmful/

Как с таким «расширением» они планируют чуть более сложную логику, чем «сложение двух массивов», реализовывать, я не понимаю.

Так это просто процессор претендующий заместить арм32/мипс32 ибо как то некрасиво что во всей мелкой электронике проприетарные процессоры и контроллеры. Это было ясно с самого начала, я не знаю чего с ним все носились.

Я бы вот на месте МЦСТ тоже выложил исходники самого первого эльбрус-3m (который без контроллера памяти, без всего) и открыл систему команд. Тоже мог бы быть кандидат в свободные от роялтей встраиваемые и не только процессоры.
МЦСТ от этого ничего бы не потеряли как минимум.

На данный момент эмулятор поддерживает только 64-битные программы, скомпилированные под Linux. Реализованы почти 80% набора инструкций Эльбрус-8С.

Только программы пользовательского режима, судя по «E2K User Support»?

Да, собственно под этим предложением и подразумевался linux-user. Недавно сделали запуск 32-битных приложений.

softmmu возможно будет, возможно нет. :)

С softmmu какие-то принципиальные проблемы или просто рабочих рук не хватает?

И рук мало, и понимания не хватает – доступ к машинам у нас только удалённый и загружать в них систему не представляется возможным.

Впрочем по поводу загрузки есть небольшие надежды – qemu-system-e2k уже был замечен в составе OSL. Это паравирт который судя по всему пока не работает, но как заработает и бинари будут у нас, можно будет попробовать играться с этим.

Похоже, они серьезно подходят к делу. Даже странно.