LINUX.ORG.RU

Decalon 0xA - первый российский микропроцессор с десятичной системой счисления

 


5

3

Российская компания «Модуль» подготавливает к восьмой международной выставке SEMICON Russia 2015 доклад об испытаниях тестовых образцов десятичного микропроцессора К12288ДВМ2Я (производственное обозначение степпинга - Decalon 0xA). Область использования данных микропроцессоров - высокопроизводительные вычисления в финансовом секторе для биржевых площадок уровня MillenniumIT и проведение научных расчетов.

Микропроцессор построен на основе уникальных дискретных элементов, в состав которых входит высокочастотный полевой транзистор, способный принимать десять логических уровней с величиной зазора 0,4 В. Это стало возможно путем создания ранее не применявшегося «гребенчатого» p-n перехода, благодаря которому транзистор способен поддерживать дискретность уровней на затворе. Такое решение позволило сохранить высокое входное сопротивление как по постоянному току, так и на высокой частоте, обеспечивая тем самым недостижимое ранее быстродействие, обусловленное отсутствием накопления и рассасывания неосновных носителей заряда. Дискретноуровневые полевые транзисторы (не путать с дискретными полевиками) в настоящий момент проходят процедуру получения патента в России и по соглашениям ЕАПК. Опытные кристаллы производятся на мощностях завода «Микрон» АО «НИИМЭ».

Авторы заранее заложились на многоядерную архитектуру, вследствие чего Decalon 0xA имеет два полноценных ядра с разделяемой общей шиной данных. Аккумулятор и АЛУ базируются на файле из 128 десятиричных ячеек, что позволяет на аппаратном уровне выполнять высокоточные вычисления с числами, превышающими число атомов во Вселенной. Такую же размерность имеют 22 регистра общего назачения, причем микропроцессор способен объединять регистры в пары для получения беспрецендентной аппаратной точности, ранее доступной только при использовании длинной арифметики. С этой же целью в систему команд добавлены инструкции, позволяющие определять области памяти как десятичные числа произвольной длинны, и инструкции, производящие с ними базовые арифметические операции. Такие вычисления выполняются на порядок медленнее чем на регистрах, однако в несколько раз быстрее, чем эквивалентная алгоритмическая реализация.

Для получения вычислительной среды используется специализированный контроллер памяти DDR3, который преобразует байтовую адресацию к декадной (D-битовой). Один D-бит занимает четыре бита двоичного байта, причем шесть неиспользуемых старших комбинаций используются для хранения специализированных не-чисел +Infinity, -Infinity, +0, -0, Undefined, Null (они рассматриваются как флаги и напрямую не используются в вычислениях).

Операционной системы, как таковой, данный вычислитель пока не имеет. Авторы экспериментируют с управляющей программой «Монитор», которая копируется из FLASH-микросхемы в ОЗУ при включении питания. Разрабатывается математическая библиотека libdmath, поддерживающая через API все аппаратные возможности микропроцессора.

Разработчики планируют в рекламных целях успеть до начала выставки протестировать майнинг Bitcoin, исполняющийся на новом кристалле. Производительность вычислений пока оценивать трудно, однако обнадеживает тот факт, что емкость десятичной системы на 128 разрядах выше чем двоичной в ~10^90 раз. К сожалению, из-за особенностей российского законодательства, процедура майнинга будет производится в Лейпциге (Германия), на выставке же будут представленны только сравнения производительности и результаты замеров.

>>> Подробности

★★★★★

Проверено: toney ()
Последнее исправление: toney (всего исправлений: 4)

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

Автор в курсе, что задача распределения инструкций в блоке компилятором является NP-сложной? Или, например, что для VLIW требуется намного большая пропускная способность памяти, из-за чего VLIW CPU попросту будут стоять на месте?

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

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

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

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

Автор в курсе, что задача распределения инструкций в блоке компилятором является NP-сложной? Или, например, что для VLIW требуется намного большая пропускная способность памяти, из-за чего VLIW CPU попросту будут стоять на месте?

Автор статьи говорит только о том что компиляторы генерят не оптимальный код, который не может нормально загрузить машину, про VLIW он ничего не говорит.

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

https://docs.google.com/viewer?url=http://www.mcst.ru/doc/glazin_0707.doc
Если есть какая то проблема то ее наверно надо решать как то, а не бросать все и бежать. Иначе бы у нас тогда программы не программировались, производство не производилось и разработки бы не разрабатывались.

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

Эта проблема решена в архитектурах типа EPIC
https://ru.wikipedia.org/wiki/EPIC_(архитектура_микропроцессора)

uin ★★★
()
Последнее исправление: uin (всего исправлений: 2)
Ответ на: комментарий от uin

Если есть какая то проблема то ее наверно надо решать как то, а не бросать все и бежать.

В данный момент проблему с пропускной способностью памяти, насколько я знаю, не решить из-за физических ограничений.

Эта проблема решена в архитектурах типа EPIC

Ок, хоть этого и мало. EPIC так же страдает от необходимости в огромном регистровом файле (что ведет к значительному подорожанию чипа и снижению частоты) и крайне низкой плотности кода. Последнюю решить не получится, потому что «это не баг, это фича».

Откуда столько фанатизма по поводу VLIW/EPIC? Даже Intel, у которых бабла и людей намного больше чем у МЦСТ, наигрались с итаниумом и забили. Насколько я знаю, это был единственный помимо собственно Эльбруса CPU с VLIW-архитектурой (Transmeta не в счёт). Остальные кроме как в DSP и видеочипы никуда VLIW не пихают и даже не думают. Может быть не всё так просто?

hateyoufeel ★★★★★
()
Ответ на: комментарий от A-234

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

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

Может быть не всё так просто?

А может просто никто глубже не копал? Поддержка типов тоже ни у кого не получилась, ни у барроуз ни у англичан ни даже интел (у которых бабла и людей намного больше), однако в Эльбрусе оно было еще в 70х годах прошлого века и есть до сих пор, мало того - на высокоуровневом языке системное программирование велось.

Откуда столько фанатизма по поводу VLIW/EPIC?

Тебе показалось.

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

А может просто никто глубже не копал?

Дофига людей копали.

Поддержка типов тоже ни у кого не получилась, ни у барроуз ни у англичан ни даже интел (у которых бабла и людей намного больше), однако в Эльбрусе оно было еще в 70х годах прошлого века и есть до сих пор, мало того - на высокоуровневом языке системное программирование велось.

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

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

В данный момент проблему с пропускной способностью памяти, насколько я знаю, не решить из-за физических ограничений.

Прошу прощения за дилетантский вопрос, но разве пропускная способность памяти не решается за счёт оптических шин? Или речь идёт не об обмене данными с памятью, а о быстродействии самой памяти?

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

Компиляторы уже давно научились генерировать код с использованием векторных вычислений (флаги -mmmx -msse ...) и это совсем не так сложно как может показаться на первый взгляд. Хотя иногда написать алгоритм с использованием векторных операций проще чем тупо лепить циклы, поэтому интринсики выручают.

A-234 ★★★★★
()
Ответ на: комментарий от hateyoufeel

Можно подробнее? Насколько я знаю, типы данных были в некоторых архитектурах, но это не прижилось

Ну у других может и не прижилось (хотя скорее неосилилось), а вот в эльбрусе прижилось. Подробнее у Пентковского http://publ.lib.ru/ARCHIVES/P/PENTKOVSKIY_Vladimir_Mstislavovich/_Pentkovskiy...

ведет к увеличению сложности и стоимости процессора

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

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

Ну у других может и не прижилось (хотя скорее неосилилось), а вот в эльбрусе прижилось.

А в чём профит? Ведь типы - это как раз то, с кем компиляторы справляются намного лучше.

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

Имелось ввиду усложнение в сравнении с другими процессорами в том же сегменте в тот же временной период.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

https://ru.wikipedia.org/wiki/Типобезопасность хотя бы, ну и производительность высокоуровневых языков и как следствие избавление от этого:

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

Имелось ввиду усложнение в сравнении с другими процессорами в том же сегменте в тот же временной период.

Не понял, ну да и ладно.

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

https://ru.wikipedia.org/wiki/Типобезопасность хотя бы, ну и производительность высокоуровневых языков и как следствие избавление от этого:

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

Ещё раз, почему это должен делать процессор, если с этим прекрасно справляются компиляторы высокоуровневых языков? Даже для встраевыемых систем и жесткого реалтайма сейчас используются высокоуровневые DSL (например, http://en.wikipedia.org/wiki/Atom_(programming_language)).

hateyoufeel ★★★★★
()

Хорошо бы в раше сделали хоть что-нибудь не через жо.. И чтоб работало.

barberry ★★
()

Он ламповый.

anonymous
()

А оно потянет крузис? И чем оно лучше i7?

Tsumi
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.