• Для чего идут изучать язык С?
    +3
    Перешел на Rust и C вспоминаю как страшный сон :D
  • Крушение Intel состоялось
    0
    Зачем нужен новый процессор, на котором будет работать старый софт? Программисты потратят сколько угодно вычислительных ресурсов с нулевым выхлопом.
  • Крушение Intel состоялось
    0
    В этом плане я считаю, что миру наконец повезло, что нашлась компания, которая не считает деньги для того, чтоб отомстить x86 за i860 и i960 :D
  • Крушение Intel состоялось
    0
    Я не говорил, что это просто. Как и любая продвинутая технология, разработка процессоров выглядит для непосвященных магией. Тем не менее, фактически процессорное ядро — это просто огромный набор кубиков, которые можно по-разному состыковать. Можно выбрать кубики разного цвета и разного размера, но они все друг с другом стыкуются, как лего. И они уже все придуманы и даже описаны в статьях. Разумеется, собрать динозавра из этих кубиков сложно, но это не магия. Просто нужны люди и время и деньги на зарплату, да и на сами кубики тоже. Лично на мой взгляд, сделать быстро и хорошо работающий многоядерный процессор сложнее, чем отдельное ядро (я уж молчу про софт для него).
    Вот, кстати, их ускоритель AI на том же чипе — это уже другие кубики, какие-то треугольные.
  • Крушение Intel состоялось
    0
    Здесь есть нюанс. Чтобы сделать частоту процессора быстрее, вы жертвуете эффективностью. Например, вы добавляете больше стадий в конвейер, что влияет на латентность команд и увеличивает оверхед при неправильно предсказанных переходах, увеличивает энергопотребление, и т.д. Посмотрим на два гипотетических процессора, сделанных по одному техпроцессу. Один из них разработан, чтоб работать на частоте 1ГГц, а другой — 2ГГц. У них будут разные архитектурные решения, чтоб этого добиться. Теперь, если вы возьмете второй и запустите на 1ГГц, вы увидите, что он менее эффективен (по тем же IPC) и больше жрет, чем первый. Если для вашего приложения 1ГГц достаточен, или у вас ограничение по энергопотреблению, то лучше выбрать первый. Но это не значит, что архитектура первого лучше, просто она другая.
  • Крушение Intel состоялось
    +2
    Ахах. Всего-то нужно добавить декодеров =) «Глупые» интеловцы и AMD-шники и ARM-овцы делают uOP кэш и разметку в L1I чтобы хоть как-то расширить узкие 4-5 wide декодеры.
    А больше они и не могут сделать. Без VLE это проще,
    поэтому в Power-печке 6/12-wide декодер.

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

    Слышал, могу даже вам рассказать, как они работают. Кстати, они — одна из самых сложных частей процессора (при этом одна из самых маленьких). А теперь представьте себе обычный код: три команды, потом переход, потом две команды, еще переход, еще пять команд, потом два перехода подряд, потом еще пара команд. Итого 16. Некоторые переходы условные и зависят от результатов предыдущих команд. Теперь вы за раз вытаскиваете из кэша по 8 команд и декодируете их параллельно, а потом решаете, что делать дальше. Так вот, в этих 8 командах у вас два перехода, которые могут зависеть от результатов первой и второй команды соответственно. Окей, у нас предсказатель переходов, который говорит нам, что первый переход надо выполнить. Правда, за то время, за которое срабатывает предсказатель, мы спекулятивно вычитываем и декодируем еще, например, три раза по восемь команд. То есть мы достали и декодировали 32 команды, из которых смогли использовать только четыре. Ну ок. Возможно, этим оверхедом можно пожертвовать. Правда, на мой взгляд это как раз то, что превращает процессоры в печку. Что-то в этом есть от Pentium-4 :)

    У меня есть замечательная книжка Майка Джонсона — одного из авторов AMD 29050. Это первый суперскалярный RISC от AMD — 1990 год, вроде бы. И в ней уже есть графики, сравнивающие эффективность декодера на 2 и 4 команды. Даже если мы забудем все доисторические мэйнфреймы, то декодер на четыре команды в обычном процессоре был представлен больше 30 лет назад! С тех пор частоты и количество транзисторов выросли астрономически, но до сих пор тот же ARM пихает декодер на те же четыре команды в самые распоследние Cortex-A7x. Вот же тупыыыые!
  • Крушение Intel состоялось
    0
    Непонятен ваш сарказм. Разумеется, равняется — чипы-то на деревьях не растут. Инженеры такие есть у всех компаний, что я перечислил, а еще у них много проектов — намного больше, чем вы думаете. Так что да, они занимаются другими задачами. Не хочу вторгаться в мир розовых пони, но я знаю, как работает эта индустрия.
  • Крушение Intel состоялось
    0
    А вы попробуйте сделать frontend с шириной 8. Intel/AMD тут и рядом не стояли. IBM может такое сделать в своих 200-300W печках.
    Но в ядре с потреблением 4-6W не может.
    При увеличение ширины запуска сложность соединений растёт очень быстро (квадратично).

    И в чем конкретно проблема сделать frontend с шириной 8? Делаем шину в L1 I-cache шире, 512 бит или 1024 бит — сколько не жалко. Добавляем декодеров, и вуаля. Ах да, компилятором анроллим все циклы, чтоб было чем загружать execution units, что увеличивает размер кода в разы и трэшит нам L1 I-cache. Бинго! Не удивительно, что у них >=192кБ L1 кэша для команд. Про IBM смешно, если б у них стояла задача сделать чип для лаптопа, то 300-ваттная печка превратилась бы в 15-ваттную путем замены одной библиотеки стандартных ячеек на другую — пара месяцев работы (работала бы медленнее, да).

    При увеличение ширины запуска сложность соединений растёт очень быстро (квадратично).
    Это не critical path, так что пофиг.

    Данные «в среднем по больнице» не интересны. Основное время код проводит в циклах.

    Это никак не отменяет того, что я сказал.

    Вот дураки — то в Интел и AMD. Не могут 1 строчку поправить :) А ещё и кэши не могут увеличить как у Apple. Ведь это 1 строчка в коде(с) Как сидели в 2003 с Pentium-M, так и сейчас сидят на 32/32 (L1I/L1D) в Comet Lake.

    Не не могут, а не хотят. Потому что у них есть симуляторы, которые показывают, что это неэффективно. Но есть люди, которым всегда надо больше — больше МГц, больше ядер, больше мегапикселей, больше камер,… :D

    Ничего, что размер структур напрямую влияет на энергопотребление и задержки? ARM не любит большие ROB, потому как это заметно ухудшает энергоэффективность.
    Apple, в отличии от всех остальных может делать большие структуры, которые быстро работают и при этом энергоэффективны.
    У Эппла какая-то другая физика, или просто 5нм? :)
  • Крушение Intel состоялось
    0
    1. По вашей же ссылке есть комментарий: «The i7-1165G7 is within 20% on single core performance of the M1. The Ryzen 4800U is within 20% on multi-core performance. Both are sustained ~25W parts similar to the M1. If you turned x64 SMT/AVX2 off, normalized for cores (Intel/AMD 4/8 vs Apple 4+4), on-die cache (Intel/AMD 12M L2+L3 vs Apple 32MB L2+L3) and frequency (Apple 3.2 vs AMD/Intel 4.2/4.7), you'd likely get very close results on 5nm or 7nm-equivalent same process. Zen 3 2666 vs 3200 RAM alone is about a 10% difference. The M1 is 4266 RAM IIRC.»
    2. Ну если у вас есть процессор, который УЖЕ умеет все это, просто для трех команд в параллель, то как вы думаете, сложно ли переделать его, чтоб он делал то же самое для восьми? Ответ: это просто. Сделать так, чтоб при этом он не стал работать медленнее и жрать сильно больше — гораздо сложнее. Верифицировать это все — еще сложнее (но не думаю, что Эппл покажет Errata на этот чип :D )
    3. Подождите, причем здесь смартфоны? Мы говорим про НОУТБУЧНЫЙ проц! Не видел ни одного хипстера в кофейне с самсунговским ноутом
    4. Разработка дорогая. Один американский инженер стоит им как минимум $120к в год. Думаю, они делали этот чип минимум 2-3 года. Сколько народу работало — 100 или 1000 — я не знаю, но можете прикинуть сами. Плюс новый техпроцесс, который завсегда подкидывает проблем. Если бы AMD выпустил такой процессор, на нем должен был бы работать Windows и все игрушки.
  • Крушение Intel состоялось
    +1
    Прошу прощения, что смею высказывать свое «ценное мнение», но и увеличение процессора «в ширину» не ново под луной. Проблема в том, что в среднем в обычном general-purpose коде всего четыре-пять команд между соседними командами ветвлений/переходов. И можно параллельно декодировать хоть 100, но КПД будет как у паровоза (если только это не спецпроцессор для DSP или AI). Да, глубина reorder buffer-а меняется одной строкой в коде (да и вообще, в процессоре изменение одной строки его кода может увеличить площадь в несколько раз — так, к сведению).

    Что касается того, что никто другой в индустрии такого сделать не может — это неправда. Western Digital, например, скупил у Оракла всю команду разработчиков OpenSPARC для своих новых RISC-V — я уверен, что они могли бы сделать такое. Интел мог бы, АМД мог бы, Самсунг мог бы, Квалкомм мог бы, ХайСиликон мог бы. Просто это дорого, и кроме Эппла никто не смог бы такой процессор монетизировать. Здесь уже маркетинг и экосистема важнее.

  • Крушение Intel состоялось
    +1
    Нет. Архитектор из 1980-х упал бы в обморок от количества EDA-софта, упрощающего разработку, и от скорости работы библиотек стандартных ячеек, но не от сложности процессора. Конечно, это сложный процессор. Но не сложнее интеловских, не уверен, что сильно сложнее какого-нибудь OpenSPARC или Power. Не прорыв. Не «The Next Big Thing».
  • Крушение Intel состоялось
    0
    Вот и ответ. Ничем принципиально M1 не отличается от других процессоров. Все то, о чем понаписано по ссылке, было изобретено еще в конце 1980-х. Просто куча железа + хороший техпроцесс + быстрая память. Идеальный вариант для ноутбуков. А теперь посмотрим, как они присобачат 32ГБ оперативки, которые от них уже видеографы всякие требуют :)
    AMD серверные процессоры с ARM-овым декодером лет 10 назад стала разрабатывать — и что? Технически это вообще не проблема — тогда вопрос на засыпку: в чем же проблема? :)
  • Крушение Intel состоялось
    0
    С тем же успехом можно сказать, что VLIW вообще ортогональна RISC-у. Это просто один из способов распараллелить последовательные вычисления. Т.е. RISC может быть «классическим», суперскалярным или VLIW, в зависимости от того, кто и где параллелит.
  • Olympus уходит с рынка цифровых камер
    0
    E-PL тоже негуманных денег стоит. Был еще E-PM, который давно уже убили (у меня до сих пор лежит как запасной). Прицепить к нему какую-нибудь Сигму 60mm 2.8 — аналогов по качеству за такую цену не было бы ни у кого на рынке. Видимо, все равно не выгодно.
  • Проект LLHD — универсальный язык описания аппаратуры
    +1
    Нет. Это то же самое, что сказать, что софт надо писать на ассемблере, потому что иначе тяжело отлаживать. Если у вас верилога на 100 тысяч строк, как в каком-нибудь среднего пошиба проце, то удобность отладки верилога будет скомпенсирована количеством багов, которые вы понаделаете в этой вермишели. Не надо кривобокость инструментов приравнивать к недостаткам методологии.
  • Проект LLHD — универсальный язык описания аппаратуры
    +1
    Затем, что можно описать логику, которая не будет работать без констрэйнов. Даже если констрэйны есть, они могут быть неправильные и не совпадать с дизайном. Поэтому в нормальном языке дизайнер описывал бы требуемое поведение, а транслятор потом мог бы генерить LLHD IR, верилог, SDC и черта в ступе. Но для этого надо, чтоб люди сняли шоры, которые нацепили 30 лет назад, а это никому не надо. Проще респин чипа сделать :D
  • Проект LLHD — универсальный язык описания аппаратуры
    –2
    Зачем это надо? Раст, скала, пайтон, С++ — напридумывали уже черт знает чего. После этого любая ошибка в коде превращается в дамп на пятьдесят строк, говорящий не о том, где ошибка, а о том, что в какой-то библиотеке, вызванной из какой-то другой библиотеки, что-то отстрелилось в строке 17296.
  • Проект LLHD — универсальный язык описания аппаратуры
    +1
    Почитаю повнимательнее, но на первый взгляд основная проблема современных языков описания не решена. А проблема эта — искусственное разделение функционального описания и констрейнов. Не должно быть никаких Verilog + SDC + UPF, это должен быть один язык.
  • Как фирма из Эйндховена стала монополистом на рынке современного оборудования для производства микросхем
    0
    Одно дело — промышленное производство, а другое дело — наклепать горстку микросхем для оборонки. Могли бы и озаботиться.
  • Всё, кроме Kotlin: Андрей Бреслав о гендерном балансе в IT, эмоциях и не только
    +1
    Вам это коммунизм напоминает не просто так. В англоязычном интернете уже и термин есть для происходящего — «cultural marxism». Только 100 лет назад марксисты делили всех на угнетателей и угнетенных по экономическому признаку, а сейчас — по полу, расе, ориентации и т.д. И если вы, к примеру, белый гетеросексуальный мужчина, то про вас уже все известно. Вы новый «буржуй» и вас надо «раскулачить». Вы оцениваетесь не как индивидуум, а как член класса. До России это еще почти не дошло, есть только жалкие потуги навроде описанных в обсуждаемой статье, но всем здесь присутствующим работникам международных компаний я бы советовал самообразоваться на эту тему, пока не поздно. Репрессивная машина уже давно заведена и прогрета.
  • Всё, кроме Kotlin: Андрей Бреслав о гендерном балансе в IT, эмоциях и не только
    +2
    Упомянутые psycological traits (https://en.wikipedia.org/wiki/Big_Five_personality_traits) напрямую влияют на профессиональные предпочтения. Очень грубо говоря — интерес к вещам vs интерес к людям, и т.д. Примерно наполовину они зависят от генов и наполовину от воспитания и окружающей среды. Когда окружающая среда «не давит» биологические предпочтения, они раскрываются наиболее полно и приводят к тому, что женщин в АйТи мало (именно из-за того, что распределение этих пяти черт в популяции мужчин и женщин разное). Разумеется, если окружающая среда говорит, что «ты ходишь в хиджабе, не имеешь водительских прав, иначе умрешь», то биологические предпочтения легко задавить на корню, а сопротивление почти бесполезно.

    Кстати, если кто-то считает, что в России мало женщин в Айти, то из всего вышесказанного следует, что это хороший признак )
  • Всё, кроме Kotlin: Андрей Бреслав о гендерном балансе в IT, эмоциях и не только
    +2
    По-моему, картина довольно ясна. Если вам повезло родиться в благополучной стране, то можете заниматься тем, чем душа велит. В Норвегии учителя неплохо зарабатывают, например. Или можете пойти в gender stuides и изучать, почему же так мало женщин-технарей. Ну а если вы из тех самых 10% женщин-технарей, идите в STEM. Если же вам «повезло» родится в индиях или китаях или россиях, то с дипломом по «gender studies» вы помрете с голоду, да и на учительскую ставку тоже, пожалуй. Так что придется вам засунуть свои хотелки куда подальше и пойти туда, где хорошо платят. В конце концов, мало ли людей занимаются нелюбимым делом? На этой дорожке вас могут поджидать побочные эффекты недоразвитых обществ с их «твое место у плиты», но это далеко не единственная проблема в таких местах, так что нет особых причин выделять ее среди прочих. Вот и причина, почему женщин в АйТи больше в развивающихся странах.
    Что бесит, так это когда американская VP of HR, у которой в штате 99% женщин, начинает мне рассказывать, что отныне при найме на инженерные позиции мы при прочих равных берем женщин, а за рекомендацию женщины-кандидата бонус в два раза больше, чем за мужчину. Для начала иди и пофикси гендерный баланс в своем чертовом HR отделе, если сможешь!
  • Всё, кроме Kotlin: Андрей Бреслав о гендерном балансе в IT, эмоциях и не только
    +4
    А первую ссылку вы читали? Разговор вот про эту статью в Таймс: www.thetimes.co.uk/article/patriarchy-paradox-how-equality-reinforces-stereotypes-96cx2bsrp (она платная).
    Чем МЕНЬШЕ влияние «внешних обстоятельств в обществе», тем больше влияние «личных предпочтений» человека — надеюсь, это не вызызвает возражений? В странах, где у женщин максимальное количество прав и свобод и минимальное влияние всяких общественных стереотипов (Скандинавия, Голландия, ...), разница в профессиональных предпочтениях между женщинами и мужчинами МАКСИМАЛЬНА. Например, женщин-айтишников в Швеции где-то 20%. И женщины в Швеции не идут в АйТи просто потому, что не хотят, а не потому, что кровавый патриархат их угнетает. И эта цифра не вырастет никогда до тех пор, пока не появятся репрессивные законы, гендерные квоты и прочее угнетение мужчин ради мифического гендерного равенства. Таковы единогласные, хоть и контр-интуитивные, результаты многочисленных исследований, сделанных разными людьми в разных странах, о чем в статье и говорится. Могу сказать, что мой личный опыт это полностью подтверждает. Зайдите в офис АйТи-компании в Голландии, и там будет одна-две женщины, и те эмигрантки. Зайдите в офис той же компании в Китае — женщин минимум треть.
  • Всё, кроме Kotlin: Андрей Бреслав о гендерном балансе в IT, эмоциях и не только
  • Всё, кроме Kotlin: Андрей Бреслав о гендерном балансе в IT, эмоциях и не только
    +2
    Вовсе не так. Зависит от того, кого именно включать в «Computer Science». У меня мать в восьмидесятых работала оператором ЕС ЭВМ (те самые огромные шкафы, магнитные ленты, куча лампочек...). При этом она до сих пор с компьютером не дружит.
  • Всё, кроме Kotlin: Андрей Бреслав о гендерном балансе в IT, эмоциях и не только
    +2
    j4mb.org.uk/2018/09/15/patriarchy-paradox-how-equality-reinforces-stereotypes

    “It seems that as gender equality increases, as countries become more progressive, men and women gravitate towards traditional gender norms,” Dr Mac Giolla said. “Why is this happening? I really don’t know.”
  • Как мы разработали устройство для контроля внимания водителей. Опыт Яндекс.Такси
    +5
    тем, что если я сижу спереди (пристегнутый), то при боковом ударе туша водителя меня убьет.
  • Обзор примитивов синхронизации — спинлоки и тайны ядра процессора
    0
    Все очень просто. С точки зрения процессора LL — это обычная команда load, а SC — обычная команда store. Они могут быть кэшированные (то есть лезут в кэш проца) и некэшированные (когда в обход кэша лезут прямо на внешнюю шину и дальше в память — DDR или что там у вас).

    1. Кэшированные:
    Кэшированные LL/SC требуют наличия аппаратной когерентности кэшей (именно поэтому внизу написали, что в TMS320C66xx они пропали). Предположим, что кэш пуст. Когда несколько ядер выполнят LL на ячейку памяти с каким-то одинаковым адресом, то это вызовет промах кэша во всех из них, и кэш-линия, содержащая этот адрес, будет прочитана в кэши всех ядер и во всех из них будет отмечена как «Shared» (гуглите MOESI — «Shared» это и есть «S» в этой аббревиатуре). Каждое ядро заодно запомнит внутри себя этот адрес и будет проверять по нему все последующие записи в память. Теперь, если все эти ядра выполнят SC по этому адресу абсолютно одновременно, то контроллер кэша каждого из ядер запросит перевод строки в состояние «Modified» (поскольку с точки зрения ядра это обычная запись, а запись в «Shared»-строку запрещена). Протокол MOESI регламентирует, что только одно из них получит разрешение перевести строку в «Modified», запросы от остальных будут забуферизированы и на это время они будут обязаны перевести свои строки в состояние «Invalid». Все ядра, в которых строка кэша стала «Invalid», поймут, что кто-то другой записал по этому адресу. Как только первое ядро закончит запись, начнет выполняться забуферизированный запрос от другого ядра: строка, отмеченная как «Modified», станет «Invalid», и наоборот — одна из тех, что были «Invalid», станет «Modified», и т.д. То есть контроллер кэшей будет гонять строку, содержащую наш адрес, туда-сюда между ядрами, и в каждый конкретный момент времени только у одного ядра будет разрешение на запись, но это уже к делу не отностится.
    Интересный побочный эффект: поскольку протоколы когерентности кэшей работают со строками, то доступ к любому слову в этой строке будет воспринят как доступ конкретно к нашей ячейке.
    2. Некэшированные:
    Некэшированные LL/SC вызывают особый тип трансфера на внешней шине: «Exclusive» (в протоколе AXI, например, такой есть). И слэйв на шине (например, контроллер памяти) должен эту функциональность реализовать сам (то есть следить, какой мастер записал по какому адресу и записал ли туда другой мастер что-либо). Если он ее не реализует как положено, то LL/SC защищать ничего не будут. Зачем вообще это надо? Ну, предположим, у вас в системе два четырехядерных проца, и внутри своих четырех ядер они когерентность кэшей обеспечивают, а между собой — нет. Придется вам использовать некэшируемые LL/SC.
  • Пишем под FPGA без HDL. Сравнение высокоуровневых средств разработки
    0
    С наглядностью того же Verilog при соблюдении минимальной культуры написания кода вообще мало какой из современных языков может сравниться


    Штоа? В языке без пользовательских типов данных, структур, многомерных массивов в портах, параметризации наличия/отсутствия портов, с бесконечными строками инлайн-вэйверов типа «spyglass disable_block» для затыкания линтеров? Где нельзя понять ни строчки, если ты не сам их вчера написал?
  • Опытное производство электроники за минимальный прайс
    0
    Любой человек, который хоть что-либо паял в жизни, понимает, что тетка должна была левой рукой держать плату, чтоб по столу не скользила. Она бы это сделала просто инстинктивно. Так что на лицо паршивенькая постановка на тему «даешь больше женщин в STEM».
  • Как поколение Y превратилось в поколение выгоревших?
    +1
    #learntocode
  • JavaScript как воплощение зла
    +7
    Это еще что. Тут недавно попалось #define volatile
  • Заказные блоки в микросхемах (Silicon IP): как это работает
    0
    Интел только недавно открыл доступ для сторонних разработчиков к своему 14 нм процессу. Так что скоро появятся в списке.
  • Заказные блоки в микросхемах (Silicon IP): как это работает
    +2
    Не забываем также MBIST, LBIST и прочий DFT, написание прошивок в ROM, всякую сертификацию по ISO-26262 и подобным стандартам, power-domain management и DVFS (самый простой способ выстрелить себе в ногу на сегодняшний день), разработку структуры ECC на всю микросхему (end-to-end или по частям, которые никогда, почему-то, между собой не совместимы), отловку багов в купленных Soft- и Hard-IP (которых там немеряно), ну и еще кучу всего. Именно поэтому куче контор, занимаюшихся исключительно интеграцией IP, хватает на хлеб с икрой.
  • Мифы о кэше процессора, в которые верят программисты
    +7
    Миф только один — что кэш «прозрачен» для программиста. Все остальное — детали.
  • Генерация и тестирование ядра RISC-V
    –1
    О том и речь. Только в варианте с Верилогом у вас есть выбор, что моделировать — RTL или нетлист. А в варианте с Chisel'ом выбора нет. Хотя есть шанс, что баги в Chisel'е наложатся на баги в трансляторе и на выходе получится работающий Верилог (по крайней мере, до выхода следующей версии транслятора).
  • Генерация и тестирование ядра RISC-V
    +1
    Для Chisel это все не нужно. Эквивалентность между RTL и нетлистом нужна, потому что верифицируете вы одно, а в кремний идет другое. А в случае с Chisel вы верифицируете Verilog, который из него получен, т.к. фреймворка по типу UVM, чтобы верифицировать нативный Chisel, наверняка нету. Если бы верифицировали Chisel, то тогда да.
  • Генерация и тестирование ядра RISC-V
    0
    А дебажить-то как? То же самое, что писать RTL-код, но симулировать и верифицировать только нетлист, а потом каким-то образом пытаться понять, что пофиксить в RTL, чтобы бага в нетлисте ушла? Спасибо, не надо.
  • Генерация и тестирование ядра RISC-V
    0
    «Talk is cheap. Show me the code» (с) Торвальдс.
    Сколько строк на Chisel написали лично вы?
  • Генерация и тестирование ядра RISC-V
    0
    1. Chisel — полная ерунда, никому не советую тратить время. Берите опенсорный RISC-V на верилоге или системверилоге, типа SCR1, и будет вам щастье.
    2. Работающего LLVM под RISC-V тоже нету, ну что ж, будем ждать.
    3. Самая интересная, по крайней мере для меня, часть ISA — векторное расширение, тоже не готова. Видимо, будет на основе берклевского же Hwacha, но когда — не понятно.

    Вывод: побаловаться студентам сгодится.