LINUX.ORG.RU

Опубликована ранняя версия неофициального эмулятора архитектуры Эльбрус 2000

 , , ,


7

3

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

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

Эмулятор был разработан используя:

Среди известных проблем:

  • эмулятор не является абсолютно точным. Полная документация на набор инструкций отсутствует, он был подвергнут методу обратной разработки, анализируя ассемблерный код, генерируемый компилятором, и его работу на реальном процессоре.
  • скорость работы эмулятора на Ryzen 2600X ниже Эльбрус-8С практически в 20 раз.
  • недостаток тестирования на реальных программах. На данный момент подтверждена работа busybox, coreutils, bash, некоторых бенчмарков и компилятора lcc.

Что примечательно, эмулятор разработан двумя участниками нашего форума: @numas13 и @a1batross.

>>> Исходный код

★★★★★

Ответ на: комментарий от pingvinek

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

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

SkyMaverick ★★ ()
Ответ на: комментарий от SkyMaverick

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

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

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

a1batross ★★★★★ ()
Ответ на: комментарий от normann

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

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

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

a1batross ★★★★★ ()

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

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

linuxmaster ★★★★ ()
Ответ на: Ребята молодцы! от linuxmaster

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

AKonia ()
Ответ на: комментарий от mumpster

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

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

BydymTydym ()
Ответ на: комментарий от Egor_

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

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

BydymTydym ()
Ответ на: комментарий от Samsonov

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

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

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

Egor_ ()
Последнее исправление: Egor_ (всего исправлений: 1)
Ответ на: комментарий от sadko4u

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


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

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

uin ★★★ ()
Ответ на: комментарий от a1batross

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

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

BydymTydym ()
Ответ на: комментарий от mumpster

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

BydymTydym ()
Ответ на: комментарий от BydymTydym

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

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

a1batross ★★★★★ ()
Ответ на: комментарий от a1batross

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


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

uin ★★★ ()
Ответ на: комментарий от sadko4u

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

uin ★★★ ()
Ответ на: комментарий от a1batross

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

BydymTydym ()
Ответ на: комментарий от a1batross

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

BydymTydym ()
Ответ на: комментарий от BydymTydym

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

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

Дизассемблирование раздела .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

mumpster ★★★★★ ()
Ответ на: комментарий от mumpster

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

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

BydymTydym ()
Ответ на: комментарий от mumpster

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

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

bydymtydym@T480:/tmp$ grep -P "j..?\w" vm.S | wc -l
208985
bydymtydym@T480:/tmp$ wc -l vm.S 
2582598 vm.S
BydymTydym ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей