LLVM IR, однако, является платформенно-независимым, так как это только промежуточное представление кода.
Немного позанудствую: разработчики LLVM пишут, что совсем платформенно-независимый код не получится (препроцессор, размеры типов и т.д.)
Кстати, эта задача напомнила мне то, с чем столкнулись разработчики mozilla rr (это time-travelling debugger, основанный на полном воспроизведении недетерминированного поведения) — им потребовалось в точности (или почти?) воспроизводить количество инструкций между некоторыми точками выполнения (вероятно, переключениями потоков/процессов) — в итоге их инструмент работает только на достаточно свежих Интеловских процессорах с достаточно стабильными используемыми ими performance counter-ами (были попытки поддержи Ryzen, но чем закончились, не знаю). Ну, то есть стабильность зависит от микроархитектуры, а не конкретного экземпляре процессора. :) Впрочем, здесь уже никакой платформенно-независимостью и не пахнет, конечно.
Кстати о птичкахQEMU: насколько мне известно, при указании опции -icount (возможно, ещё с какими-то параметрами) — получаете подсчёт инструкций "из коробки" (вроде, там в каждый translation block добавляется соответствующее изменение счётчика выполненных инструкций и, можно надеяться, исключения тоже обрабатываются корректно). Вот только с user-mode эмуляцией никогда на это не смотрел (я вообще на неё особо не смотрел)… Возможно, к этому счётчику можно как-то прицепиться, правда логика там малость запутанная.
Кстати, а Valgrind в режиме cachegrind чего-нибудь подобного не умеет?
А как же Codeforces? — у него есть и русскоязычная, и международная версия. По крайней мере, когда я там участвовал, они были синхронизированы.
А на TopCoder есть (были?) соревнования по чему угодно, в том числе "марафонные матчи" — это когда на, скажем, две недели даётся некая оптимизационная задача, предположительно не решающаяся точно, и ты сидишь и совершенствуешь своё решение.
Насколько я помню, кроме "традиционных" алгоритмических задач там были задачи/соревнования по функциональному программированию, машинному обучению и т.д. Были даже наборы задач по bash, регуляркам и т.д. В общем, забавный сайт.
Честно говоря, вопрос был, скорее, риторический. :) Просто при первом взгляде напомнило описываемое в статье Драйвер компьютерной игры Street Fighter V отключает встроенный механизм защиты Windows, поэтому мне показалось, что было бы полезно описать некие меры предосторожности, которые, вероятно, есть. То есть речь не только о safety, но в большей мере о security.
Если браузер старый, без поддержки WebAssembly, то потребуется emscripten. Это, грубо говоря, эмулятор WebAssembly для браузера.
<зануда> Emscripten — это не эмулятор WASM, это LLVM-бекенд для генерации Asm.JS/WASM, JS-рантайм для сгенерированного кода и, видимо, ещё пачка всякого разного (вероятно, включающая и интерпретатор). </зануда>
Иногда попадается не только в комментариях: например, в документации QEMU
Lines should be 80 characters; try not to make them longer.
...
Rationale:
- Some people like to tile their 24" screens with a 6x4 matrix of 80x24
xterms and use vi in all of them. The best way to punish them is to
let them keep doing it.
...
А в Firefox какое-то время назад были параметры для включения экспериментального и "ваще экспериментального" WebRender:
Под связкой C-ассемблер я имел в виду просто два языка программирования разного уровня. То есть не "напишем всё на Чизеле, а потом вручную поправим ниже уровнем". Я имел в виду "что удобно, быстро напишем на Чизеле, что неудобно — допишем на Verilog/VHDL" — я же не предлагаю выкинуть классические HDL-языки и заменить их на Chisel. А вот с количеством ресурсов — это да, остаётся надеяться разве, что компилятор выкинет всё лишнее (как компилятор C вычисляет константные выражения и т.д., образовавшиеся после раскрытия макросов). Ну и на то, что взамен это хотя бы даст то железо (или FPGA-дизайны), которое раньше было сильно сложно сделать (ну или простое, но полезное и много видов) за счёт упрощения процесса разработки.
Чтобы не приходилось играть со средой разработки в игру «кто кого умнее».
Когда я читал книгу Harris&Harris, у меня сложилось впечатление, что на Verilog тоже нужно писать не просто по стандарту, а по идиомам, иначе компилятор не поймёт. В этом смысле язык, в котором бы идиомы явно записывались в коде, был бы, наверное, шагом вперёд (не утверждаю, что это Chisel). Ну и здесь это поведение, во всяком случае, детерминированное, а не какие-то эвристики.
автоматическое своевольное добавление chisel-ом логики тактовой частоты и ресета мне кажется странной практикой.
Со своей, программистской, колокольни: ассемблер нагляднее C с точки зрения того, что в итоге получится, и можно, например, в каждую функцию предавать параметры, как в данном случае удобно. Можно договориться о calling convention и аккуратно везде её соблюдать. А можно писать на C, и там нужно исхитриться, чтобы не соблюсти calling convention. Последнее мне кажется более безопасным, хотя и может помешать, например, написанию низкоуровневого кода ядра ОС — ну так на то и ассемблерные вставки и отдельный ассемблерные файлы.
Насколько я знаю, для некоторых устройств Altera/Intel тоже доступны инструменты, конвертирующие OpenCL (в каком-то смысле, почти C) в дизайн для FPGA.
Хотя, на самом деле, получилось довольно нетривиально и это интересно.
Спасибо :) Раз получилось "нетривиально" при не очень большом количестве кода и почти полном отсутствии опыта, значит, возможно, Chisel мог бы дать возможность не-суровым-профессионалам написать что-то осмысленное и относительно близкое к железу (то есть всё же не на С), как в своё время экосистема Arduino многих приобщила к электронике. Впрочем, Chisel выглядит серьёзнее, чем Arduino IDE. :)
ИМХО, есть несколько путей "оюзерфрендливания" языка:
угадывание намерений (не всегда точное) — JavaScript, PHP
усложнение выстрела в ногу / упрощение отладки — все те же + Java — там хоть стек-трейс почти всегда будет, а в Java ещё и статическая проверка типов
лаконичность и безопасность ценой более запутанной системы типов и, возможно, существенного усложнения некоторых низкоуровневых вещей--- Scala, Rust (?)
Отличный bridging the gap между программистом и железом. Но на мой взгляд, до конкуренции Chisel и HDL — как до до луны пешком.
О, это было бы как раз интересно: комментарий от человека, хорошо знакомого с классическими HDL о том, почему Chisel не конкурент HDL. Правильно ли я понимаю, что подразумевается примерно то же, что "Java не конкурент C/C++" (то есть, что Chisel — это упрощённое безопасное подмножество, на котором сложнее выстрелить в ногу, но некоторые низкоуровневые вещи выразить существенно сложнее, как и понять, во что оно оттранслируется на самом низком уровне)? Всё-таки Chisel — это просто язык описания, а не попытка автоматически транслировать Scala в Verilog.
Спасибо! Первая ссылка вообще шикарна! (А вторую я как раз тоже использовал при подготовке статьи.) Но всё равно с ходу не помогло. :) Кстати, автор одной из статей говорил, что на микроконтроллере он PAL так и не завёл, но завёл NTSC.
Chisel, вроде, тоже проще некуда при условии, что уже знаешь Scala. Вопрос, на чём мне будет комфортнее писать от случая к случаю. Я при этом не утверждаю, что ответ — Chisel — у меня банально опыта нет для таких сравнений. Но учитывая, что на основной работе мой язык — Scala, то вкусовщина, скорее всего, будет именно на его стороне. Вот что интересно, так это узнать у людей, знакомых как с Verilog, так и с "хипстерской функциональщиной", что безопаснее в плане "не выстрелить в ногу".
А ещё, помню, натыкался на вопрос на Quora, о том, стоит ли учить Chisel или Verilog для промышленного применения. Ответ был "Verilog учить однозначно — стандарт, остальное — по желанию". И при этом указывалась полезность большого кругозора даже не в плане "профессионально знаю десять языков, поддержу что угодно", а в плане знакомства с мотивациями "а нафига вам ещё один язык понадобился, что плохого/опасного в существующих решениях". Знакомство с Maybe[A] и Either[A, B] по Хаскелю может и при программировании на C++ пригодиться.
Ну и, гипотетически, если вам нужно что-то очень хитро кастомизировать каждый раз — то в Chisel к вашим услугам вся мощь ФП и экосистемы Java — хоть в БД лезь. Нужно ли это кому-то и насколько это будет удобно — другой вопрос.
Только там, насколько я помню, буфер будет синхронизироваться постоянно — скопировал пароль, а он на все устройства улетел. :) Ну и там полно других компонентов, не только синхронизация буфера — удалённый доступ к файлам устройства или удалённая клавиатура/тачпад для компьютера, например. Вроде, можно было даже лазить с телефона сразу на планшет за файлами.
Видимо, неточно выразил мысль: на идею параллельных англоязычных блогов я и сам смотрю с оптимизмом.
Я имел в виду скорее то, что изложение статьи, написанной на родном языке автора, вероятно, будет выглядеть "живее", чем на неродном. То есть "интереснее" стилистически.
Сейчас же на Хабре немало переводов не от оригинальных авторов. Может, сделать удобную кнопку "Я хочу сделать официальный перевод этой статьи на английский (или русский), разрешите, пожалуйста". Такие официальные внутренние переводы от сторонних авторов. Многие, наверное, будут только рады.
Не сказать, чтобы я был против затеи, но согласен: написать какую-нибудь документацию, которую можно как-то прочитать и статью, которую интересно читать — это, имхо, сильно разный уровень владения английским должен быть.
Немного позанудствую: разработчики LLVM пишут, что совсем платформенно-независимый код не получится (препроцессор, размеры типов и т.д.)
Кстати, эта задача напомнила мне то, с чем столкнулись разработчики mozilla rr (это time-travelling debugger, основанный на полном воспроизведении недетерминированного поведения) — им потребовалось в точности (или почти?) воспроизводить количество инструкций между некоторыми точками выполнения (вероятно, переключениями потоков/процессов) — в итоге их инструмент работает только на достаточно свежих Интеловских процессорах с достаточно стабильными используемыми ими performance counter-ами (были попытки поддержи Ryzen, но чем закончились, не знаю). Ну, то есть стабильность зависит от микроархитектуры, а не конкретного экземпляре процессора. :) Впрочем, здесь уже никакой платформенно-независимостью и не пахнет, конечно.
Кстати о
птичкахQEMU: насколько мне известно, при указании опции-icount(возможно, ещё с какими-то параметрами) — получаете подсчёт инструкций "из коробки" (вроде, там в каждый translation block добавляется соответствующее изменение счётчика выполненных инструкций и, можно надеяться, исключения тоже обрабатываются корректно). Вот только с user-mode эмуляцией никогда на это не смотрел (я вообще на неё особо не смотрел)… Возможно, к этому счётчику можно как-то прицепиться, правда логика там малость запутанная.Кстати, а Valgrind в режиме cachegrind чего-нибудь подобного не умеет?
А как же Codeforces? — у него есть и русскоязычная, и международная версия. По крайней мере, когда я там участвовал, они были синхронизированы.
А на TopCoder есть (были?) соревнования по чему угодно, в том числе "марафонные матчи" — это когда на, скажем, две недели даётся некая оптимизационная задача, предположительно не решающаяся точно, и ты сидишь и совершенствуешь своё решение.
Насколько я помню, кроме "традиционных" алгоритмических задач там были задачи/соревнования по функциональному программированию, машинному обучению и т.д. Были даже наборы задач по bash, регуляркам и т.д. В общем, забавный сайт.
Честно говоря, вопрос был, скорее, риторический. :) Просто при первом взгляде напомнило описываемое в статье Драйвер компьютерной игры Street Fighter V отключает встроенный механизм защиты Windows, поэтому мне показалось, что было бы полезно описать некие меры предосторожности, которые, вероятно, есть. То есть речь не только о safety, но в большей мере о security.
Я правильно понимаю, что это предназначено исключительно для прототипирования и ни в коем случае нельзя оставлять на production?
<зануда> Emscripten — это не эмулятор WASM, это LLVM-бекенд для генерации Asm.JS/WASM, JS-рантайм для сгенерированного кода и, видимо, ещё пачка всякого разного (вероятно, включающая и интерпретатор). </зануда>
Напомнило: в коде WebKit видел чудесную строчку:
Как говорится, "Зачем писать комментарии, если можно понятно называть функции".
Иногда попадается не только в комментариях: например, в документации QEMU
А в Firefox какое-то время назад были параметры для включения экспериментального и "ваще экспериментального" WebRender:
Под связкой C-ассемблер я имел в виду просто два языка программирования разного уровня. То есть не "напишем всё на Чизеле, а потом вручную поправим ниже уровнем". Я имел в виду "что удобно, быстро напишем на Чизеле, что неудобно — допишем на Verilog/VHDL" — я же не предлагаю выкинуть классические HDL-языки и заменить их на Chisel. А вот с количеством ресурсов — это да, остаётся надеяться разве, что компилятор выкинет всё лишнее (как компилятор C вычисляет константные выражения и т.д., образовавшиеся после раскрытия макросов). Ну и на то, что взамен это хотя бы даст то железо (или FPGA-дизайны), которое раньше было сильно сложно сделать (ну или простое, но полезное и много видов) за счёт упрощения процесса разработки.
Я нуб и извините, если скажу чушь, но всё же...
Когда я читал книгу Harris&Harris, у меня сложилось впечатление, что на Verilog тоже нужно писать не просто по стандарту, а по идиомам, иначе компилятор не поймёт. В этом смысле язык, в котором бы идиомы явно записывались в коде, был бы, наверное, шагом вперёд (не утверждаю, что это Chisel). Ну и здесь это поведение, во всяком случае, детерминированное, а не какие-то эвристики.
Со своей, программистской, колокольни: ассемблер нагляднее C с точки зрения того, что в итоге получится, и можно, например, в каждую функцию предавать параметры, как в данном случае удобно. Можно договориться о calling convention и аккуратно везде её соблюдать. А можно писать на C, и там нужно исхитриться, чтобы не соблюсти calling convention. Последнее мне кажется более безопасным, хотя и может помешать, например, написанию низкоуровневого кода ядра ОС — ну так на то и ассемблерные вставки и отдельный ассемблерные файлы.
Насколько я знаю, для некоторых устройств Altera/Intel тоже доступны инструменты, конвертирующие OpenCL (в каком-то смысле, почти C) в дизайн для FPGA.
Спасибо :) Раз получилось "нетривиально" при не очень большом количестве кода и почти полном отсутствии опыта, значит, возможно, Chisel мог бы дать возможность не-суровым-профессионалам написать что-то осмысленное и относительно близкое к железу (то есть всё же не на С), как в своё время экосистема Arduino многих приобщила к электронике. Впрочем, Chisel выглядит серьёзнее, чем Arduino IDE. :)
ИМХО, есть несколько путей "оюзерфрендливания" языка:
Есть подозрение, что Chisel — это вариант 3.
О, это было бы как раз интересно: комментарий от человека, хорошо знакомого с классическими HDL о том, почему Chisel не конкурент HDL. Правильно ли я понимаю, что подразумевается примерно то же, что "Java не конкурент C/C++" (то есть, что Chisel — это упрощённое безопасное подмножество, на котором сложнее выстрелить в ногу, но некоторые низкоуровневые вещи выразить существенно сложнее, как и понять, во что оно оттранслируется на самом низком уровне)? Всё-таки Chisel — это просто язык описания, а не попытка автоматически транслировать Scala в Verilog.
Спасибо! Первая ссылка вообще шикарна! (А вторую я как раз тоже использовал при подготовке статьи.) Но всё равно с ходу не помогло. :) Кстати, автор одной из статей говорил, что на микроконтроллере он PAL так и не завёл, но завёл NTSC.
Chisel, вроде, тоже проще некуда при условии, что уже знаешь Scala. Вопрос, на чём мне будет комфортнее писать от случая к случаю. Я при этом не утверждаю, что ответ — Chisel — у меня банально опыта нет для таких сравнений. Но учитывая, что на основной работе мой язык — Scala, то вкусовщина, скорее всего, будет именно на его стороне. Вот что интересно, так это узнать у людей, знакомых как с Verilog, так и с "хипстерской функциональщиной", что безопаснее в плане "не выстрелить в ногу".
А ещё, помню, натыкался на вопрос на Quora, о том, стоит ли учить Chisel или Verilog для промышленного применения. Ответ был "Verilog учить однозначно — стандарт, остальное — по желанию". И при этом указывалась полезность большого кругозора даже не в плане "профессионально знаю десять языков, поддержу что угодно", а в плане знакомства с мотивациями "а нафига вам ещё один язык понадобился, что плохого/опасного в существующих решениях". Знакомство с
Maybe[A]иEither[A, B]по Хаскелю может и при программировании на C++ пригодиться.Ну и, гипотетически, если вам нужно что-то очень хитро кастомизировать каждый раз — то в Chisel к вашим услугам вся мощь ФП и экосистемы Java — хоть в БД лезь. Нужно ли это кому-то и насколько это будет удобно — другой вопрос.
Только там, насколько я помню, буфер будет синхронизироваться постоянно — скопировал пароль, а он на все устройства улетел. :) Ну и там полно других компонентов, не только синхронизация буфера — удалённый доступ к файлам устройства или удалённая клавиатура/тачпад для компьютера, например. Вроде, можно было даже лазить с телефона сразу на планшет за файлами.
Спасибо!
Видимо, неточно выразил мысль: на идею параллельных англоязычных блогов я и сам смотрю с оптимизмом.
Я имел в виду скорее то, что изложение статьи, написанной на родном языке автора, вероятно, будет выглядеть "живее", чем на неродном. То есть "интереснее" стилистически.
Сейчас же на Хабре немало переводов не от оригинальных авторов. Может, сделать удобную кнопку "Я хочу сделать официальный перевод этой статьи на английский (или русский), разрешите, пожалуйста". Такие официальные внутренние переводы от сторонних авторов. Многие, наверное, будут только рады.
Не сказать, чтобы я был против затеи, но согласен: написать какую-нибудь документацию, которую можно как-то прочитать и статью, которую интересно читать — это, имхо, сильно разный уровень владения английским должен быть.