Лого Сделано у нас
201

Системная плата на микропроцессоре Эльбрус-8С

Всем привет!

немного эксклюзива: материнка для персоналки Эльбрус 801-РС на новом микропроцессоре Эльбрус-8С!

Это предсерияная партия плат, для внутренней отладки, но на серийной партии микропроцессоров.

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

Сразу скажу: в видео засветились только 4 платы: они остались на выходные для окончания монтажа. Они и попали в мои руки. Так же ранее было выпущено еще некоторое количество плат за предыдущие пол года.

От себя добавлю: по производительности — сущий термояд! все летает, но это еще не до конца оптимизировано ПО! так что хочу всех поздравить: Эльбрус-8С уже на уровне производительности с зарубежными аналогами!

читать полностью


  • 0
    Иван Левашев Иван Левашев
    23.12.1622:51:35

    Здравствуйте! Я хотел бы заявить о своём проекте, и Эльбрус к нему тоже относится, но вот кому и что с этой информацией делать, тут неопределённость. Я не чувствую обстановку. То ли фонд учредить, как с HTML5, то ли отправить меня на стипендию в ВУЗ, чтоб над проектом кто-то, кроме меня работал. Всё равно же магистрам надо хоть компилятор написать, хоть что-то такое продвинутое, чтобы прокачаться. А тут ещё и смысл в этом будет. Сам я хочу поступить в магистратуру Северо-Западного Университета КНР (Сиань), но чтоб и с Россией сотрудничать.

    Посылал в МЦСТ резюме, правда, не в декабре, ответа нет, а стоит ли усилия тратить, кто там вообще на другой стороне, не очень понятно.

    Сам я разработчик-фрилансер и тонко чувствую на своей шкуре, когда у разработчиков начинается геморрой. Вот не так давно один проект перенёс с Debian на CentOS, и заказчику это обошлось в $100, и пакетов, которые надо пересобирать, где-то порядка десяти, и там нет-нет, где-нибудь да и вылезет. Relocatable библиотека в configure подцепит static зависимость вместо relocatable или хотя бы static-pic, и привет. Просто скопировать если без перекомпиляции, в очередном OpenSSL символы не так заманглены, и по этому поводу можно взять и не запуститься. А это всего лишь с одного Linux x64 на другой Linux x64. Что же говорить про разные OS и разные архитектуры. И это всего лишь 10 пакетов, а если 260, как в каком-нибудь реально большом проекте? Да проект просто не сможет вырасти без кучи индийцев, решающих эти проблемы. Не на словах, а на деле я знаю сказку про ноулайферов, которые портируют ваши программы и библиотеки под разные дистрибутивы. И про исходники, которые сами соберутся. На мой взгляд, получается закономерно, что в Linux программы аномально часто либо на Java, либо скриптах, но они не покрывают весь спектр.

    Проблемы кроссплатформенности пытались решить виртуальные машины (Java, .NET), но они слишком навязчивы. Как прокрустого ложе. И если в это ложе втиснуть, часто получается решение, которым мало кто пользуется по сравнению с решением без виртуальной машины. Для PHP есть Quercus, для Python есть JPython и IronPython, но когда вы их последний раз видели? Вот какая-нибудь Joomla — и чтоб на Quercus? Я кроме Google, который впаривает всем без спросу, надо/не надо, эту Java в своём AppEngine, не слышал. У Qt есть Jambi, и казалось бы, возьми JPython и получи доступ ко всему богатству Java библиотек, в том числе Qt через Jambi, ан нет, зачем-то PyQt нагородили. И сам Qt — не на Java. Плагин для Netskape Navigator когда-то нельзя было без Java написать, этого требовал LiveConnect, а сейчас даже Java-апплет толком нигде уже не запустится. В OPENSTEP TextEdit однажды переписали на Java, а в современной Mac OS X даже мост между Java и Objective-C уже не встроенный. В общем, не везде приживаются такие навязчивые виртуальные машины.

    Я иду другим путём, я делаю байт-код из PE/COFF+x86+… Под ??? подразумевается взаимно притёртые и переработанные Wine, Cocoa и IBM SOM. На Windows, естественно, без Wine, а на Mac OS X мост к родной Cocoa. На тех процессорах, которые и так x86, нужно только, чтобы программа могла показывать вменяемые элементы интерфейса, понимать родную файловую систему и прочее, чего не даёт Wine. О том, как это делать, я написал в своей работе «Общая платформа исполнения приложений». И если это воплотить, это как недостающее звено в одном ряду с виртуальными машинами и скриптами. Чтобы повысить шансы на успех, я постарался набрать как можно больше заинтересованных лиц.

    Вы разрабатываете транслятор непопулярного языка программирования (Ada 2012, например), а библиотек чёт маловато? — Поддержите мой проект, он основан на IBM SOM, которая была многоязыковой, и это качество должно перейти в новую модель, а IBM SOM — это доказательство принципиальной возможности.

    Вы пишете библиотеку в машинных кодах и хотите вызывать её из скриптов? — Поддержите мой проект, и ваша библиотека автоматически станет доступна из поддерживаемых скриптов, как OLE Automation в Windows. И в сам OLE Automation мост можно сделать, Novell ComponentGlue подтверждает это. Сейчас разработчики тратят время, например, на SWIG. Это же время можно потратить на то, чтоб писать под мою платформу и получить дополнительные бонусы, которые не даёт заточенный под одну задачу SWIG.

    Вы делаете операционную систему, а программ чё-т маловато? — Поддержите мой проект, и разработчики, скорее всего, как и в случае Java, будут и дальше разрабатывать из-под Windows, но и как в случае с Java, оно просто запустится на поддерживаемой операционной системе. Как и в случае Wine, есть шанс, что им будет тяжело сделать полноценный порт, но они всё же найдут время убедиться в совместимости.

    Вы делаете процессор с нестандартной архитектурой, а программ чё-т маловато? — Поддержите мой проект, и разработчики, скорее всего, так и дальше будут разрабатывать не для вашего процессора, но если запустить на вашем, благодаря особенностям, эмулятор сможет срезать острые углы, а библиотеки из стандартного набора заменить их родными версиями, и общая производительность может получиться вполне приемлемой для работы.

    И всё это — в одном проекте, так что если набрать критическую массу, дальше как снежный ком должно раскрутиться.

    Сразу должен предупредить, что по моему опыту этот подход оскорбляет чувства линуксоидов, которые думают, что там в Linux какой-то самобытный путь, и ноулайфер должен персонально под их дистрибутив портировать весь софт. Только пакетов у них почему-то десятки тысяч, а не миллионы, как для Android. Мой подход переносит гомогенную среду исполнения и «файлопомойки CNews, FreeSoft и SoftPortal» на остальные OS (да хоть Genode) и процессора. Если я вижу, как это хорошо сработало в Windows, почему я должен не делать то же, чтобы изменить соотношение? На одной чаше весов — «самобытность», на другой — вырваться из vendor lock и импортозаместить. Если признать WinAPI ужасным рудиментом, а вместо него дать разработчикам нормальное ООП API (легче всего получается с OpenStep, ныне известном как Foundation и Cocoa в Mac OS X), то это вполне себе приятная среда исполнения. А любите пакеты — ну хотите, продолжайте их делать. Может, даже на базе модифицированного .msi пакетный менеджер сделать, чтоб с одного контроллёра домена ставить софт сразу и на Windows, и на Linux.

    Что касается Эльбруса, то некоторые подходы позволяют, во-первых, сделать подстановку эмулируемых библиотек родными версиями с идентичным API и разгрузить эмулятор от анимации, локальной БД и т. п. стандартного набора. Эмулятор при этом то выходит из режима эмуляции, то входит обратно. Во-вторых, в эмулируемом x86 коде, если его хитро генерить, можно убрать тормоза, и об этом моя вторая работа «Метод кооперативной эмуляции архитектуры процессора», которая ещё публикуется. Возможности такой хитрой генерации существуют в немодифицированных компиляторах, и я показал это на примере дизассемблированного листинга библиотеки из состава IBM SOM 2.1, скомпилированной Microsoft Visual C++, естественно, безо всяких таких модификаций. В качестве тормозов, которые можно убрать, я рассматриваю сопоставление адресам в эмулируемой архитектуре адресов в родной, с некоторой кооперацией со стороны разработчиков. Можно генерить код так, чтобы косвенные вызовы методов распознавались и могли быть перенаправлены сразу в таблицу методов для родной архитектуры. Кстати, не могли бы вы дать оценку производительности вашего двоичного транслятора, если ему не пришлось лезть в хеш-таблицы при каждом косвенном вызове? Надо как-нибудь исключить обращение в хеш-таблицы из замеров производительности. Может, она вплотную к родному коду подойдёт?

    Программа-максимум — это охватить сразу несколько архитектур. У китайцев Лунсон, а ещё производители ARM хотят разорвать замкнутый круг. Общие потребности. И вот хорошо бы взять и устроить единое пространство, чтоб в Китае написали программу, а у нас на Эльбрусе она запустилась, и так же с Лунсоном. В Китай я хочу сам отправиться, но так, чтобы в России тоже процесс пошёл, и у нас среды исполнения совместимые были. Каждый решает свои проблемы автаркии и импортозамещения, но всесторонне выгодно.

    Вот и найти бы заинтересованных лиц как-нибудь.

    • 0
      shigorin shigorin
      22.02.1722:09:25

      Читайте про semistatic (кому охота таскать одни бинарники по разным линуксам), FatELF (по разным архитектурам). Ну и поймите наконец, что предлагаемые решения не решают _всего_, а лишь сдвигают баланс между решёнными проблемами и созданными.

      И да, пакеты мы (в альте) любим. Вот сейчас они у меня на эльбрусе тихо-мирно себе собираются в чистой среде.

      В любом разе желаю успехов ;-)

      PS: а, во, ещё про общую шину почитайте.

      Отредактировано: shigorin~23:10 22.02.17
Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,