Наткнулся тут на интересную запись. Вкратце - человек посетил конференцию в Abu Dhabi в которой было отделение по Risc-V.
Самое интересное в ней "Евросоюз запустил программу по разработке своих решений на базе этого ядра практически для всех применений."
Причина - Евросоюз боится, что англосаксы заберут лицензию на ARM (у европейской фирмы STM).
Вот такая вот шутка юмора. Россия боится санкция, Китай боится санкций и Евросоюз боится санкций.
Использованные источники:
Комментарии
А можно уточнить каких санкций Россия боится...
Россия боится санкций на покупку электронных компонентов.
Но тут надо уточнить, что значит "боится". Вот скажем сейчас Россия производит вполне неплохие комбайны с кучей электронники со всего мира. Даже есть варианты, для которых водитель не требуется. На производства такого типа санкции влияют очень сильно.
Не забываем, что совсем недавно был кризис, из-за которого разные электронные компоненты было тяжело купить даже без санкций. И вот есть зарубежный продавец, у которого недостаточно товара для продажи. И у него есть выбор - продать эту электроннику обычному покупателю и подсанкционному. Как вы думаете, что он выберет?
Шутки-шутками, а США, судя по всему, уже во всем мире становятся "нерукопожатными". Даже среди своих "союзников" (вассалов). И начинаешь по новому смотреть на усилия российского руководства "играть по правилам".
Бояться санкций и пугать ими народ - разные вещи
Да, в данном случае Евросоюз боится санкций США и втихаря к ним готовится. Но народ санкциями не пугает.
Не пугает. Но обрекает. Неужели вы считаете, что верхушка ЕС станет меньше потреблять стейков, рассекать на самолетах и лимузинах? Санкции, они, для быдла, баре даже не заметят спада потребления собою любимыми. Не для того они пропагандируют инсектбелок, чтоб самим его жрать.
Ну, в любом случае, тоже - "Мадэ Ин УСА".
Джентельмены - хозяева свои сов. Хотят - дают. Хотят - обратно забирают.
Оупен суорс был хорош и нужен, когда нужно было "вбросить в массы" кучу разноплановых идей и направлений и "обкатать" их. За бесплатно.
Когда определятся - всё возвернётся взад.
Ибо - не фиг.
Open source очень хорош в эпоху перемен.
Например Huawei использует open source в виде Android. Если бы он был в закрытых исходниках, то Android бы превратился в тыкву в момент наложения санкций на Huawei.
Аналогично и Risc-V. Основной набор инструкций - open source, и поэтому его двигает и Китай и Евросоюз и Россия.
Так я - про RISC-V и говорил.
Вспомните, историю с Линуксом. Вернее - с Торвальдсом. Помните, был у него период с Трансметой (?).
Там ведь "не взлетело" - именно по причине того, что "гранды отрасли" (которые к тому времени уже до фига бабок в ядро Линукс вложили, чтобы оно хоть на что-то работающее стало похоже) не хотели, чтобы на "чужой архитектуре" (которую собирались "опенсорсной" сделать), ещё и софт с ГНУ-лицензией заработал. И проц тормознули и фирму "почикали" именно под угрозой "отмены" ГНУшной лицензии на ядро и утилиты. Там, помнится, есть лазейки в законах Штатов (по интеллектуальной собственности). И - да - те, кто под ГНУ-лицензией свой софт выпускают, всё время "под этими статьями" ходят. ПО ВСЕМУ МИРУ! Просто это не афишируется как-то... Тоже - в порядке договора с Торвальдсом. Тем более, что - ГНУ- ГНОй, но Товальдс, кое на что, свои права-таки оформил после Трансметы очень оперативненько и - совсем даже - не ГНУшненько...
По сути, оупенсорс/"открытые исходники" - то, что и было однажды Столлманом озвучено: миллионы пар глаз БЕСПЛАТНЫХ "тестировщиков"... НЕ БОЛЕЕ.
Нет, к сожалению такой истории я не знаю.
Transmeta умерла по той-же причине, по какой умерли остальные VLIW процессоры. Производительность ядра росла быстрее, чем скорость оперативной памяти. В какой-то момент всё преимущество VLIW растратилось на том, что в нём инструкция очень много места занимает (по сравнению с другими архитектурами) и соответственно требуется либо большой кешь, либо очень быстрая память.
Ну, сейчас уже и интеловские процы вполне спокойно можно к vliw-ам причислять.
Кстати, как для программистов - самая оптимальная архитектура. Логично-естественная, так сказать.
Вот если бы ещё побитовую (а - не побайтовую) адресацию сделали (как на i432-м кристалле) - совсем бы "бомба" была!
Нет. Vliw вариант Intel x86 умер вместе с Pentium 4. Семейство Intel Core и его производные насколько я помню выполняют каждую микрооперацию отдельно без сборки в одну большую инструкцию.
Вот как вы себе редставляете типичную ситуацию - есть несколько инструкций. Первая читает из памяти и сколько она прождёт - неизвестно, т.к. это зависит от того, в каком кеше данные лежат. Последующие инструкции - независимы от первой и могли бы выполняться дальше. Как это возможно с VLIW архитектурой?
А - какая разница, какая длинна команды(?), если у вас уже есть конвейер и вы уже понимаете, где границы инструкций, и они независимы друг от друга, и не занимают соответствующие внутрикристальные шины - ну и распараллеливайте их - переназначайте занятость ресурсов. К тому же и сам кэш "многопортовым" быть может. Рассовывайте для последующих команд в разные диапазоны адресации компилятором. Да, состояние кэша - практически не предсказуемо (из за "зоопарка" в памяти и разных состояний при разных запусках), ну, таки - да? А "предсказатели" - на что? :) Вообще проблем не вижу. Не забывайте историю с RISCами: там тоже все надеялись и ставили на то, что, за счёт команд с фиксированным размером и выравниванием, сложность кристаллов упадёт и скорострельность увеличится... А потом - "пошли нюансы", когда первоначальные требования и ограничения стали "ослаблять и расширять" и сейчас RISCи даже сложнее MISCов стали получаться.
П.Н. Всё равно, ничего приятней и органичней PDP-11/VAX-11 уже не будет... :)))))))
Интел - так вообще, с определённого времени внутри себя, по сути, RISCи содержит с "эмуляцией" микрокодом нужного/"привычного" набора команд.
Большая разница. Вот как действуют современные процессоры когда выполняют asm инструкции по нескольку за такт.
Сначала они разбивают инструкцию на более простые микроинструкции.
Потом - строят граф последовательности выполнения микроинструкций.
Потом - выполняют от начала графа инструкции, причем по возможности параллельно. На сколько выполнительных блоков хватит - настолько параллельно и выполняют.
Если какая-то из веток выполнения графа тормозит - это не мешает выполняться другим инструкциям, которые независимы от них.
Вот куда тут приткнуть VLIW??? Он только мешать будет.
А вот набор инструкций Risc-V спецально дизайнился для того, что-бы out of order execution можно было максимально просто реализовывать.
Ещё раз повторю - к ассемблерным инструкциям есть два важных требования требования:
1. с одной стороны они должны занимать минимум места в памяти (так называемая плотность информации в коде)
2. с другой стороны они должны быть лекго понимаемы процессором.
У VLIW команд всё хорошо со вторым пунктом, но плохо с первым.
У CISC команд всё хорошо с первым пунктом, но плохо со вторым.
Risc-V где-то посерединке между ними.
Да - ничем vliw от остального хозяйства не отличается. Только потребными ширинами внутренних шин и дополнительными ресурсами, потребными на промежуточных, указанных вами, этапах обработки команды.
Да, всегда ищутся компромиссы.
Ошибка сейчас в том, что все продолжают "копать" в сторону "универсальных" архитектур. А это - уже НЕ "актуально". Это было к месту примерно до того момента пока не появились "бохатые" ПЛИСины.
Сначала народ "докумекал", что на них можно "эмулировать" уже имеющиеся кристаллы и архитектуры...
Чем все и кинулись заниматься. Вон, на opencore - куча реализаций ядер х86-х, z80-х, NS32xxx-х выложено.
А, потом, самые смекалистые, пройдя полную итерацию, опять вернулись к "кремниевым компиляторам", где не "ОС запускает процесс", а - часть кристалла - ОПТИМАЛЬНО - перестраивается под задачу.
При этом - совершенно пропадает необходимость "сравнивать" какие-то стандартные архитектуры! Ну - просто потому, что часть кристалла, ПОД ЗАДАЧУ - УЖЕ ИМЕЕТ ОПТИМАЛЬНО ПОСТРОЕННУЮ АРХИТЕКТУРУ. И этот уровень оптимальности НИКОГДА имеющимися "универсальными" архитектурами не будет достигнут в принципе!
И поэтому, лично для меня, все эти разговоры - про vliw-ы, risc-и, cisc-и, misc-и - уже - НЕ имеют никакого смысла.
Как говорится:
Лично я использовал и EP4CE22 и Zynq 7010, потому как они разумных денег стоят. Но! На EP4CE22 запустить ядро процессора быстрее, чем на частоте 100 МГц нереально. На Zynq 7010 максимальная частота более-менее сложного кода ближе к 200 МГц. И писать на Verilog - это то ещё счастье. Просто огромное количество времени убивается на сравнительно простые задачи.
Реконфигурируемость ПЛИС - это дорого. На том-же техпроцессе спокойно можно делать гигагерцовые ядра, если они будут полностью в железе.
Уже выше указал VLIW отличается принципиально тем, что нельзя динамически оптимально нагружать блоки. Это если мы говорим о микроинструкциях.
Если же делать цельные инструкции VLIW, как в Эльбрусе, тогда всё ещё печальнее. Очень много nop (пустых операций) внутри VLIW инструкций вставляется. Плотность кода сильно страдает, размеры программ увеличиваются, в кешь ничего не влезает. Грусть и печаль.
Очень странно.
И - странные результаты и выводы.
К тому же - ну кто же СИСТЕМЫ на Verilog, VHDLили каком-нить SystemC разрабатывает????
Здесь - иные средства и иной подход нужен. Практически - противоположный принятому в означенных средствах. Иначе - так все и будут топтаться в "трёх соснах" в попытках вырваться из-под тяжести уже искусственно привнесённой сложности (неадекватные языковые средства и базовые архитектурные элементы).
К сожалению, здесь мы (на моей стороне) подходим к ситуации "у нас есть ТАКИЕ приборы!... но мы вам о них не расскажем."
Поверьте, вполне есть уже рабочие варианты на гигагерцах.
Весь прикол в том, что в этих вещах НЕТ понятия "тактовой частоты" для всей системы (впрочем, для локальных "подблоков" на кристалле, получающихся после работы компилятора, - тоже). Ну - вот так, да. Концепция и подход с "тактированием" - тупиковый. Причём - радикально. Это - всё равно, что продолжать ньютоновской физикой пользоваться там, где надо уже "нечто иное" применять в моделях, чтобы результаты экспериментов с расчётами совпадали. :)
Я верю, что топовые Alterra можно запустить на гигагерцовой частоте. Но это несколько дорого, есть значительно более дешевые способы набрать ту-же производительность.
Про средства разработки - да, я слышал, что сейчас идёт тенденция отказа от "низкоуровневых" Verilog/VHDL и переход на более высокий уровень. Но насколько понял - всё это сейчас очень коммерциализированно и за большие деньги.
Про "нет понятия тактовой частоты" - вы точно программировали FPGA? Если да, то можно продолжить обсуждение уже с техническими деталями. Если нет - то видимо нет.
Да, сейчас это - ОЧЕНЬ дорого.
Всё - на этапе "концепт-пруфа".
Да, сами FPGA мы без тактирования, ЕСТЕСТВЕННО, просто не сможем использовать. Но сейчас происходит "эмуляция" схемных и логических решений, в которых отрабатываются блоки и их взаимодействия на "сугубо" асинхронном базисе и принципах функционирования. Что-то похожее было в GreenArrays, но, теперь, это - уже на более высоком уровне и "продвинутости", по итогам их использования.
Не очень понятное объяснение. Надо читать детали.