Создание экосистемы свободного ПО для процессоров «Эльбрус»

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

Нет, это не ложь, и те, кто реально прочитал эти ссылки, понимают их безосновательность. Если бы это было не так, вы бы давно скопи/пастили из них хотя бы парочку хорошо обоснованных тезисов. Но там таких просто нет, и вся ваша аргументация сведётся к «ну, это ж сотрудники МЦСТ так думаю».

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

Да вы чего-то бредите. :) Кнут вообще говорит, что и мультиядерность нафиг не нужна, так как она не ускорит его ТеХ. И, кстати, в начале 200х, откуда эта ссылка и пришла, так думало большинство программистов. Все хотели халявы, чтобы новые чипы продолжили бы ускорять их 40летней давности код. А халяву не дали. В результате, за 20 лет, люди научились писать мультитридовый код, и переписали имеющийся, так как старый код новые камни уже не ускоряли. А в случае с вливом - ещё и замедлят. И снова придётся всё переписывать. И программеры, в конечном итоге, снова прогнутся, хотя сейчас огворят «да нахрена нам этот ILP». Как и 20 лет назад Кнут говорил «да нахрена мне эта многоядерность».

Аргументы и пруфы расписаны в каждой статье.

Все эти «аргументы» строятся на выдуманном предположении, что архитектура Эльбрусов – это нечто неизменное и неподдающееся улучшению, что является очевидным заблуждением, если не сказать больше. И это прекрасно видно даже по тем моделям, что уже выпущены. Даже 6-е поколение уже вполне применимо для использования на десктопе, а в 7-м Эльбрусы помимо прочего обзаведутся аппаратным префетчером и предсказателем ветвлений, о чём ты сам упомянул. Что это если не прогресс? А 8-е поколение по слухам претерпит ещё более кардинальные изменения.

У одного в активе работа над lcc, у другого не известно (как-минимум мне).

По слухам Маслов в МЦСТ пилил бинарный транслятор.

Что это если не прогресс? А 8-е поколение по слухам претерпит ещё более кардинальные изменения.

+1, а какие конкретно изменения нужны Эльбрусу - уже и так видно из ссылки про пульсона. Лично у меня она практически все вопросы сняла. А ведь ещё про киттсона даже не накидали ссылок…

Какие наработки имеются в виду и кто даст гарантию, что все они будут совместимы между собой?

P.S. Ссылки те читал ещё 100 лет назад, ничего убедительного в них не обнаружил.

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

Это демагогия. Ты сейчас пытаешься всех прочитавших выставить за согласных с тобой и отрицаешь реальность.

Если бы это было не так, вы бы давно скопи/пастили из них хотя бы парочку хорошо обоснованных тезисов.

Если бы тебе было что возразить по существу - ты мог бы не начинать невнятные разговоры о ВПН. Тем временем, я написал саммари. Этого более чем достаточно. Кому надо - прочитают и изучат.

Но там таких просто нет

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

Да вы чего-то бредите.

Я уже говорил, что статьи надо читать целиком, а не по диагонали. Рассуждения о VLIW и техе идут отдельными тезисами.

Интересно, а в постели у тебя тоже premature posting случается? Что за манера постить новость о том что вскоре будет новость? А если подождать до самого события и уже конкретно о нём написать - слишком большой риск запостить содержательный контент?

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

Нет. Все эти аргументы строятся на том факте, что VLIW всегда будет хуже суперскалярных архитектур с Out-of-Order Execution. Соответственно, если бы МЦСТ пилили чипы на тех же ARM, прогресс был бы больше, производительность – выше, а проблем с софтом – меньше.

Какие наработки имеются в виду и кто даст гарантию, что все они будут совместимы между собой?

Софт. В одной из первых ссылок даётся разбор этой проблемы. А гарантию даёт архитектура и набор команд. Об этом тоже написано, или читай.

P.S. Ссылки те читал ещё 100 лет назад, ничего убедительного в них не обнаружил.

Значит плохо читал.

Это демагогия. Ты сейчас пытаешься всех прочитавших выставить за согласных с тобой и отрицаешь реальность.

Мож не всех, но некоторые уже тут отписались ровно с таким же мнением. Да и что делать со статьёй, где все тезисы идут вот в таком ключе:

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

Ну ок, мы верим. Дальше-то что? Сказано уже было, что проблему решит аппаратный префетчер и предсказатель переходов, которые будут в эльбрус добавлены (если не уже). И так по всем пунктам. Если нет - покажите хоть 1 стоящий пункт.

Если бы тебе было что возразить по существу - ты мог бы не начинать невнятные разговоры о ВПН. Тем временем, я написал саммари. Этого более чем достаточно. Кому надо - прочитают и изучат.

Пфф, нет, это я написал саммари, а вы написали бред. :) По вашей ссылке Кнут говорит, что ему не нужны ни ILP, ни мультитредовость. Как мы увидели за 20 лет, как минимум в 1 из этих пунктов он уже ошибся. Ошибётся и во 2м.

Вот тебе, например, не надо, поэтому ты отчаянно игнорируешь тот факт, что там содержится анализ кода и проведения компилятора, например.

Как и все тамошние аргументы, он сводится к конкретной реализации эльбруса и компилятора. Можно было бы сказать «ну ок, эльбрус тогда закопаем», но нет, МЦСТ уже сказал, что эти проблемы будут пофикшены. И что теперь?

Рассуждения о VLIW и техе идут отдельными тезисами.

Покажите хоть 1, достойный обсуждения вне контекста конкретных (старых) версий эльбруса.

Фанаты VLIW непробиваемы. Они либо читают критику через слово, либо не читают вообще. Сюда уже вон высадился десант из прошлого треда, одни и те же лица. По существу им нечего возразить - остается только рассказывать про субъективность, жаловаться на впн да клоунов ставить.

Ну хорошо, вот видишь ты - статья на хабре надуманная. Иди напиши ответную, да разбери ее по кирпичикам. Что, не хочется? Боишься, что съедят за несостоятельностью? А съедят. Вот и остается, что спорить на лоре со мной.

Даже 6-е поколение уже вполне применимо для использования на десктопе, а в 7-м Эльбрусы помимо прочего обзаведутся аппаратным префетчером и предсказателем ветвлений, о чём ты сам упомянул. Что это если не прогресс? А 8-е поколение по слухам претерпит ещё более кардинальные изменения.

А зачем тогда было брать за основу VLIW? Чтобы потом допиливанием напильником долго и мучительно превращать его в некое подобие архитектуры которую можно было взять изначально? Ведь весь этот твой «прогресс» не более чем исправление первоначальной ошибки в выборе архитектуры.

Этот шаг делается для развития открытого ПО для процессоров «Эльбрус».

В новости не хватает картинки счастливого Столлмана, ) https://ibb.co/zVdfvZx.

По существу им нечего возразить - остается только рассказывать про субъективность, жаловаться на впн да клоунов ставить.

Так ведь это же ты мне клоуна поставил, клоун! А я ничего такого не делал, значит, ты ещё и врун?

Ну, Шигорин известный, гм... он даже топил против слива исходников, т,е. фактически за «NDA приоритетнее, чем соблюдение GNU GPL».

А зачем тогда было брать за основу VLIW? Чтобы потом допиливанием напильником долго и мучительно превращать его в некое подобие архитектуры которую можно было взять изначально?

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

Ведь весь этот твой «прогресс» не более чем исправление первоначальной ошибки в выборе архитектуры.

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

Мож не всех

Вот и не примазывайтесь.

Ну ок, мы верим. Дальше-то что? Сказано уже было, что проблему решит аппаратный префетчер и предсказатель переходов, которые будут в эльбрус добавлены (если не уже).

Который точно так же был добавлен в итаниуме, как элемент OoO. В таком случае непонятно, зачем вообще нужен VLIW, учитывая, что полноценный OoO лучше всего будет работать на CISC или RISC, о чем там тоже написано. VLIW при этом увеличивает количество транзисторов, не прибавляя заметной производительности на единицу потребляемой электрической мощности, о чем можно увидеть в той же ссылке, и даже по бенчмарку https://7-cpu.com/

И так по всем пунктам. Если нет - покажите хоть 1 стоящий пункт.

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

И так по всем пунктам.

вы написали бред

Это твой лучший технический аргумент, как я понимаю.

Во первых, меньше перезаказов кремния, каждый из которых делался на Тайване, и стоил миллионы (и не рублей вовсе).

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

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

Исследования - это хорошо. Плохо только, что на тупиковое направление делается такая большая ставка.

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

Во вторых, влив наработки у них уже были, и хотелось реализовать их потенциал.

А ещё у них были SPARC наработки. Был бы прикол, если бы МЦСТ стали ведущим дизайнером чипов на SPARC и вытянули бы эту архитектуру после смерти солнцевских. Благо, софта вот под SPARC как раз хватает, да и архитектура не то чтобы прямо наивсратейшая.

В третьих, МЦСТ - исследовательская контора, и думали, что потянут такой исследовательский проект.

В 2000 году? Возможно. В 2005, когда Бабаян свалил и уже публично заявлял, что не лезет каменный цветов, думать такое было как-то странно.

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

А если добавить сюда необходимость пилить мегасложный компилятор? Всё ещё на порядок более простые?

Так ведь это же ты мне клоуна поставил, клоун! А я ничего такого не делал, значит, ты ещё и врун?

А я и не про тебя говорил, клоун. Просто скинул в одну кучу с другими балаболами.

если бы МЦСТ пилили чипы на тех же ARM

Политота и нацпол.

Байкал смогли, МЦСТ не могут. Skill issue lmao

Сначала нужно посмотреть, под какой оно будет лицензией.

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

А если добавить сюда необходимость пилить мегасложный компилятор? Всё ещё на порядок более простые?

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

Все эти аргументы строятся на том факте, что VLIW всегда будет хуже суперскалярных архитектур с Out-of-Order Execution.

Ничто не мешает VLIW самому заниматься перестановкой. VLIW более совершенен, потому что известно как ему помочь. В x86 компиляторы тоже пытаются помогать, без этого код будет тормозить.

В Эльбрусе кроме VLIW архитектура просто более защищенная, Англичане на исследование ARM с малой частью защит Эльбруса, потратили больше чем ушло на Эльбрус-8С, и еще не закончили. А у них уже есть ARM, и опыт.

Ничто не мешает VLIW самому заниматься перестановкой.

Конечно не мешает. Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW?

VLIW более совершенен, потому что известно как ему помочь.

Пристрелить, чтобы не мучался?

В Эльбрусе кроме VLIW архитектура просто более защищенная

Защищённая от чего? От установки в пользовательские компьютеры?

О чём вообще разговор, если обычному человеку Эльбрус не купить?

Защищённая от чего? От установки в пользовательские компьютеры?

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

Конечно не мешает. Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW?

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

Защищённая от чего? От установки в пользовательские компьютеры?

http://www.elbrus.ru/arhitektura_elbrus

записывает защищенный режим и тегированную память в свойство VLIW

И так, смотрим что я написал:

В Эльбрусе кроме VLIW архитектура просто более защищенная,

Определение кроме я тоже выпишу

Кроме - в добавление к кому-либо или чему-либо

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

Который точно так же был добавлен в итаниуме, как элемент OoO.

Это не совсем ОоО. И это важно понимать. Когда у вас есть последовательный поток инструкций, вы можете их переупорядочивать. Это - ОоО. А когда у вас бандлы параллельных инструкций, то они все там независимые. Так что, в каком бы порядке ни завершилось их выполнение - это не переупорядочивание по определению. Нельзя переупорядочить то, что шло параллельно и не имело изначальной упорядоченности.

Так что все сравнения этого с ОоО - лишь умозрительные упрощения. Префетчинг и кеш переходов - механизмы настолько простые по сравнению с динамическими трансляторами современных полноценных ОоО, что сравнивать их просто глупо.

и проблемы VLIW, неочевидные для обывателя, встают в полный рост.

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

Конечно не мешает. Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW?

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

Это в каких? И как это помогает процессору-то? Этот пакет команд – просто довольно всратая кодировка инструкций процессора. Если у тебя в чипе есть спекулятивное выполнение и out-of-order, то ВНЕЗАПНО оказывается, что группировка команд нахрен не сдалась.

С Itanium вот ровно так и вышло: туда всё это добавили, и тут оказалось, что эта группировка только мешает. Пришлось пристрелить.

http://www.elbrus.ru/arhitektura_elbrus

Ты про вот этот кусок?

Одна из самых интересных идей, унаследованных от архитектур Эльбрус-1 и Эльбрус-2 – это так называемое защищенное исполнение программ. Его суть заключается в том, чтобы гарантировать работу программы только с инициализированными данными, проверять все обращения в память на принадлежность к допустимому диапазону адресов, обеспечивать межмодульную защиту (например, защищать вызывающую программу от ошибки в библиотеке). Все эти проверки осуществляются аппаратно. Для защищенного режима имеется полноценный компилятор С/С++ и библиотека run-time поддержки.

Это же буквально описание работы MMU любого современного процессора. Да-да, на x86 такое тоже возможно.

Вот был тут Frost_ii (кажется) - так он хотя бы на действительно сложные в решении проблемы указывал, типа как повышение нагрузки на шину памяти из-за жирного кода.

Про это писал ещё хаскеллист-штангист thesz лет 10 назад (мем из-за него появился, да):

https://thesz.livejournal.com/1448727.html

хз есть ли он на ЛОРе, но про это тоже все давно знают. Это следствие всратой группировки команд, на которую тут дрочат фанаты VLIW.

Ничто не мешает VLIW самому заниматься перестановкой.

Нет там перестановки, и в этом вся фишка. Там «ОоО» на уровне и без того параллельных бандлов. Какая тут перестановка, если в бандле инструкции и не были упорядоченными изначально?

По этому, это даже не ОоО, а просто какие-то наработки, взятые из других архитектур.

Новость о намерениях?

Создание экосистемы свободного ПО для процессоров «Эльбрус»

состоится пресс-конференция, посвященная развитию экосистемы

ничего не замечает тело подтверждавшее «новость»? что развивать собрались? то, чего неть? Или всё-таки создавать?

АО «МЦСТ» объявляет о раскрытии исходных кодов ядра linux, системных библиотек, патчей совместимости для ПО

это точно должно быть в конце «новости»? Может всё-таки в начале?

Приятно что лорчик штабильно растёт (отрицательно), вногу с Роиссей!

ЗЫ Миша куда девался? НафронтЪ? Лицеист бл.

И так, смотрим что я написал:

И так

Господи.

В Эльбрусе кроме VLIW архитектура просто более защищенная

кроме VLIW

архитектура

«Кроме архитектуры архитектура более защищенная?»

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

Если у тебя проблемы с русским языком, то викисловарь незаменимая находка.

Меня русским языком попрекает клоун, не в состоянии правильно написать слово «итак»? Дожили.

Это же буквально описание работы MMU любого современного процессора. Да-да, на x86 такое тоже возможно.

Нет, гранулярность другая. Да и не только это. Эльбрус понимает, что такое «объект в памяти», и проверит, что указатель установлен на начало объекта (а не на середину), и что тип указателя соответствует объекту.

Они отвечали на этот вопрос

Вопрос был не к ним. К ним то какие вопросы? Бизнес и ничего личного. Вопрос к тем кто сначала утверждал что VLIW это круто и мы всем ещё покажем, а теперь оказалось что придется допиливать напильником чтобы вернуться к тому от чего ушли.

Это в каких? И как это помогает процессору-то?

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

Это же буквально описание работы MMU любого современного процессора. Да-да, на x86 такое тоже возможно.

Хорошо, покажи где в x86 «128-битовый указатель содержит размер выделенного блока, тэги, адресс начала блока и offset». После этого покажи как доступ к неинициализированной переменной вызывает отлавливаемую ошибку.

Это не совсем ОоО.

Именно поэтому я и автор статей называют это простейшим ОоО или элементами ОоО. Потому что полноценный ОоО на VLIW организовать невозможно, как ты сам написал. А элементы ОоО понадобились от общей проблемности VLIW, как и в случае с итаниумом.

Так что все сравнения этого с ОоО - лишь умозрительные упрощения.

Сравнения совершенно легитимны в контексте подхода. Еще раз смотрим на историю итаниума и сравнения последних версий их микроахритектуры.

И совсем не те, о которых вы говорите

Нет, они идут в дополнение к тем, о которых я говорю.

Эльбрус понимает, что такое «объект в памяти», и проверит, что указатель установлен на начало объекта (а не на середину), и что тип указателя соответствует объекту.

Да-да, это буквально страничный MMU с тегированными. Только тут страницы более гранулярные. Ничего нового.

У системы команд Эльбруса (то есть на уровне, который не требовал вообще никакого дорогого софта или оборудования) есть два фундаментальных ограничения.

1. Единый регистровый файл.

Результат операции, которая произошла в канале 0 должна быть немедленно доступна для чтения всем шести. Даже если программа исполняет что-то типа сложения матриц, где это и не нужно. Это как все переменные делать атомиками в однопоточной программе. Юзкейсы, когда это полезно по пальцам фрезеровщика пересчитать можно.

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

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

Исправить это можно либо поломав обратную совместимость и выкинув на помойку все работы по компилятору, либо добавив скрытое спекулятивное состояние, но в таком случае у ISA нет фишек, которые делают эту работу проще по сравнению с каким-нибудь ARM, так что в чем был смысл?

Скажем, векторы у RISC-V явно требуют указать длину цикла перед каждой итерацией. За счет этого можно запилить спекулятивное исполнение без сложного предсказателя ветвлений, без всяких там Томасуло и переименований регистров, и префетчеров. А Е2К под такое банально не проектировался.

Переставлять команды не бесплатно.

Конечно нет. Но в итоге получается всё равно быстрее и дешевле, чем долбиться в VLIW.

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

Ну, да. И? Использование VLIW это как-то убирает? Ни разу! Наоборот, всё становится только хуже.

Хорошо, покажи где в x86 «128-битовый указатель содержит размер выделенного блока, тэги, адресс начала блока и offset». После этого покажи как доступ к неинициализированной переменной вызывает отлавливаемую ошибку.

Смотри выше мой ответ. Плюс, один хрен, это не эксклизивное свойство еблуса. Тегированные указатели запилили в ARM недавно, можешь сам посмотреть.

«Кроме архитектуры архитектура более защищенная?»

Кроме свойства «VLIW» которое находится в наборе «архитектура», эльбрус обладает свойством «защита» которое находится в том же наборе «архитектура».

Меня русским языком попрекает клоун, не в состоянии правильно написать слово «итак»? Дожили.

Я понимаю смысл, ты нет. Ты даже с этим решил спорить? Иди правь тогда викисловарь, я то тут причем?

Я понимаю смысл, ты нет.

Крайне сомнительно.

Иди правь тогда викисловарь, я то тут причем?

я то

Ты в каком-то движении за свободу от орфографии и пунктуации состоишь, признайся честно?

Конечно нет. Но в итоге получается всё равно быстрее и дешевле, чем долбиться в VLIW.

Спасибо что привел так много аргументов, и ссылки на источники.

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

Ну, да. И? Использование VLIW это как-то убирает? Ни разу!

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

Смотри выше мой ответ.

Там нету ответа на мои вопросы, вот тебе хороший сайт https://godbolt.org/
Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной, я очень хочу увидеть новые инструкции x86, которые видимо добавили 5 минут назад, потому что я еще ничего подобного не видел.

Спасибо что привел так много аргументов, и ссылки на источники.

Ссылок выше приведено до жопы.

с VLIW они могут лучше выполнять свою работу.

Не могут.

Там нету ответа на мои вопросы, вот тебе хороший сайт https://godbolt.org/ Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной, я очень хочу увидеть новые инструкции x86, которые видимо добавили 5 минут назад, потому что я еще ничего подобного не видел.

Читай сюда: https://wiki.osdev.org/Memory_Management_Unit

А элементы ОоО понадобились от общей проблемности VLIW, как и в случае с итаниумом.

Так я не вижу, после вашей ссылки на пульсон, каких-то существенных, доселе не решённых проблем. И это вы ещё ссылку на китсон не закидывали. То, что всем нужны те или иные аппаратные оптимизации - это и так очевидно. То, что вы называете «простейшим ОоО», на самом деле лишь избавляет компилятор от необходимости работать с потактово-предсказуемым железом, где, если не обложить всё префетчами, то пайплайны встанут при первом же кеш-промахе. Очевидно, такая ситуация никого не устраивает: железо не может быть потактово- предсказуемым, а компилятор не может всё обкладывать префетчами. Теперь эту (очевидную для всех) проблему решили. Если бы её не решили, влив можно было бы хоронить - тут спору нет. Хорошо, что вы приложили ссылку на пульсон, которая сняла этот вопрос, равно как и все остальные.

С открытым софтом никаких проблем нет, бери и компилируй. Закрытый софт там где будут использоваться Эльбрусы предположу что не нужен, а если и нужен, то от отечественных разработчиков. Для всех остальных случаев есть бинарный транслятор.

Архитектура и набор команд вообще не даёт никаких гарантий, т.к. МЦСТ вряд ли будет иметь возможность влиять на развитие архитектуры risc-v, а следовательно они были бы обречены на вечное отставание и необходимость подстраиваться под каждое (неизбежное) изменение или нововведение, независимо от того, нужно оно им или нет. Проще взять открытый софт и собрать. Гентушники вон вообще добровольно конпеляют свои программы и никто из них от этого ещё не умер. Не говоря уже о том, что risc-v нам банально могут запретить. Подождать того момента когда Россия поглубже завяжется на эту архитектуру, чтобы было больнее, а потом взять и запретить. И такие призывы (в отношении Китая) уже звучали, а уж как это сделать придумать при желании не сложно. И останешся ты один на один со своим чудесным risc’ом в своём гараже, естественно без всяких перспектив на какой-либо потенциальный экспорт. Вон, байкаловцы тоже до известных событий били себя пяткой в грудь, заявляя что уж такая солидная компания как ARM точно не станет ничего запрещать. Ага, конечно… Хотя их предупреждали.

Кроме того, ты упускаешь из виду, что главная проблема сейчас не в архитектуре, а в отсутствии производства, и от того что все сейчас перейдут на risc-v свой литограф у нас не появится. К тому же разве Yadro уже не пилит свой risc-v? Так чего ты от МЦСТ хочешь? Чтобы они запилили ещё один? А зачем нам два одинаковых процессора?

*liksys не понимает простейшего предложения, издает страшные звуки при виде викисловаря*

Я понимаю смысл, ты нет.

Крайне сомнительно.

Бедняжка, я все понял, ты же GPT бот, умеешь выдавать вроде бы верные ответы, даже орфографию соблюдаешь, но к сожалению вместо содержания один бред.

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

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