У вас переменная уже extern const, оптимизировать ее компилятор уже не будет, потому что она в другом translation unit, и положить ее в регистр если и получится, то только при LTO.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
А volatile ей тогда зачем? В голову приходит только какой-то глобальный объект в многопоточной программе, который можно читать из разных мест, а писать только в одном (либо только хитрым способом). Borrow checker для бедных.
Поддержу, современным разработчикам на ассемблере писать на них реализацию замыканий не нужно, и уже, скорее всего, не будет нужно.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
А давайте обсудим.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
У PC HW все точно так же, и за некоторые решения хочется натурально убивать голыми руками, но всех все устраивает, продукт выпущен, все довольны, недовольных шлют по вектору. Работает — не трогай, перестанет — будем посмотреть.
Дык нет же, аналоговое аудио и по метровому кабелю Belkin не едет (у меня он на столе лежит, я проверял), а едет ли VL — пока еще непонятно. Все остальное — да, т.е. кабель почти универсальный и не толщиной с палец, конечно, но все равно набор из 3 кабелей попроще таки дешевле и большинству пользователей хватит такого набора за глаза.
Почему же, делайте, и все будет, никакой уличной магии там нет, инженерия вполне обычная. Понятно, что сразу замахиваться на высокочастотную симуляцию не смысла, но что-то небольшое сделать самому — вполне можно, а если с сообществом поделитесь — будет отлично совсем.
Так я и не спорю с этим, в реалиях бизнеса все так и есть. Проблема водопада именно в том, что он несовместим с качанием требований вслед за линией партии, но это не делает саму методологию плохой, а лишь неподходящей к этим реалиям. Т.е. если цель — решить задачу бизнеса, то решать ее надо как получается, и не жаловаться на тормоза и неоптимальность решения. А хочешь оптимально — доставай строгие требования, математику, теорию систем, инженерию, все то, что мы как человечество наработали для решения проблем, влезающих в головы архитекторов.
Мы с вами находимся на одной стороне спора, мне кажется. Я говорил про вот это:
Провода — вроде бы все одни, но нет — через один зарядка не идёт, через другой не идёт быстрая зарядка, третий не предназначен для Thuderbolt, четвёртый не работает с v2. А usb-c наушники — вот уж подлиное безумие! Все с проблемами. Телефоны работают с ними всяк по своему. И снова уйма несогласованных стандартов.
Даже с учетом того, что физически разъем выглядит одинаково, его по причинам вполне прозаическим не делают совместимым со всеми режимами, альтернативными или нет, и кабелей таких, по которым все вообще режимы работали бы — нет, и не надо. О чем я и написал, а ваших вопросов теперь понять не могу, т.к. это не я хочу один кабель на все случаи жизни.
Не перегибаю, аналоговое аудио по активным кабелям не работает на том Belkin, я проверял. Работу VirtualLink не проверял пока, но надеюсь, что вывезет без отдельных кабелей.
Опять же, никто не мешает USB IF послезавтра выпустить еще десяток альтернативных режимов для которых понадобятся свои кабеля, и задача сведется к предыдущей.
Работал и так, и так, и справляться приходилось и с водопадом, и с эджайлом.
Если у вас задача не влезает по сложности в дизайн — это показатель того, что решать ее рано. Ах, надо уже вчера? Ну тогда никто не гарантирует никакого качества, кроме того, что получится. Именно так получается нынешнее ПО, нынешние процессоры и все остальное. Нужно лучше — планируйте, контролируйте, используйте подходящие инструменты, контролируйте, хорошо платите, контролируйте, и не забывайте контролировать, это обязательно.
Пока это все не станет выгодно (т.е. ничем другим от конкурентов отличиться станет невозможно, кроме размера и\или скорости кода), для масс это не будет сделано никогда, потому что это адски дорого, адски долго, а на выходе получаются только примитивные вещи, влезающие в дизайн по ТЗ.
Именно в этом и разница между инженерной задачей и задачей получить на выходе продукт, который кому-то нужен. И именно поэтому софт для спутника или марсохода пишется по спеке и исключительно по ней, а писать так приложения для бизнеса, который сам не знает, чего хочет — выбросить сотню миллионов на ветер, и остаться позади конкурентов. Разные цели — разные методы, и я не ругаю ни тот, ни другой, просто отвечаю на вопрос «почему результат вот такой» — он вот таким получается, получать его иным — дорого.
Истинно так, выпрямлять — невыгодно, т.е. делаться будет либо энтузиастами, либо только тогда, когда ничего другого уже не поможет, и останется только выпрямлять. Думаю, мы вполне успеем дожить до этого момента, если никаких существенных прорывов в скорости вычислений и объемах памяти не произойдет в ближайшие лет 30.
Потому что из песка, скотча и тряпок ее делать дешевле в соответствии с теми процессами, которые идут внутри компании, эту систему производящую.
Чтобы бить задачи на подзадачи, нужно ясное видение «что именно строим», и план детальный к нему. По нынешней же моде это все называется жутким словом «водопад» и преподносится дорогими консультантами как жуткое болото, страшный суд, ад и погибель (о том, что так делается любой инженерный проект от моста через реку до ракеты, консультанты умалчивают почти всегда). Теперь у нас в моде эджайл, скрам, канбан и прочее все, призванное ПО не разрабатывать, а выращивать, лепя MVP из песка, тряпок и скотча, чтобы релизить быстрее, потому что иначе деньги кончатся, а инвесторы не дадут новые.
Виноваты умолчания.
Никто не захотел думать (не знал, не стал заморачиваться, не влезал в строки, не влезал в бюджет, не влезал в целевую производительность, причины точные не знает никто), что процессор можно атаковать с этой стороны. Почему раньше никто не переживал по поводу того, что kernel.dll отображается по фиксированному адресу, а теперь это большая проблема? Почему никто не пытался предотвращать исполнения страниц памяти с данными, а теперь все стараются всеми силами? Почему аппаратура начала вести теневые стеки, подписывать указатели и тегировать динамическую память, а раньше об этом никто не думал?
Все потому, что программирование — оно в основном про то, как выполнить задачу бизнеса при определенном наборе входных данных и выдать относительно приличный результат за относительно же приличное время. Написание программы, работа которой возможна при любых входных параметрах, противостоящей утечкам данных из любых общих ресурсов, тайминг-атакам и всему тому, что появилось за 50 лет противостояния брони и снаряда — это совсем другая задача за совсем другие деньги.
Согласен с автором, но причин разочаровываться не вижу. Человечество развивает ИТ таким же образом, как и все остальное, в полном соответствии со своей природой. Программы пишутся так же, как строятся города: кем попало, без плана и на руинах от предыдущих попыток. Сложность современных вычислительных систем уже вплотную подбирается (если уже не превысила) порог их понимания человеческим мозгом, и потому единственный путь вперед — повторять за эволюцией, нагромождая слои на слои, и сравнивая результаты.
Автору посоветую пойти и попробовать разобраться досконально хотя бы с современными архитектурами, т.е. как оно там все работает «на самом деле», начиная прямо с собирания сумматора из подручных материалов (как у Петцольда в известной книге), написания процессора простейшего на верилоге и так вверх до ЖаваСкрипта со всеми остановками. Где-то на реализации первых сложных команд в микрокоде придет понимание того, что писать все так, чтобы летало, при этом было доступно вчерашним школьникам, масштабировалось, обновлялось, свистело и пердело — просто настолько умопомрачительно дорого по всем параметрам, что позволить себе это могут либо огромные корпорации, либо гениальные энтузиасты (вроде Беллара). Все остальные берут то, что уже есть, и добавляют к нему то, чего еще нет, но хотелось бы иметь, либо комбинируют то, что уже есть, нужным им способом. Да, медленно, да 10 слоев, да эмуляция виртуализации эмуляции, да, никто понять не может толком уже давно, но результат — вот он, решения в массы, деньги в кассы.
Потому что унификация должна проводиться железной рукой и контролироваться на каждом этапе до состояния «не будут брать — отключим газ», а такое возможно только там, где цена ошибки очень высока — у ядерщиков, военных и авиаторов. И там не рынок, а олигополия, и разработка унифицированных продуктов занимает там годы и стоит миллионы.
Рынку же нафиг не нужна унификация, наоборот каждому игроку нужны свои, ни с чем не совместимые и запатентованные разъемы, кабели, периферия, и собственные стандарты вообще на все, иначе прибыль от продажи всех сопутствующих товаров падает.
Кроме того, если вам сделать один кабель USB-C, по которому можно будет передавать и Thunderbolt, и USB 3.1, и питание, и аудио цифровое и аналоговое, и черта лысого оцифрованного — такой кабель будет толщиной в палец и стоить 50 долларов за метр, а покупать его никто не будет, потому что десяток кабелей попроще можно купить вдесятеро дешевле.
Производителю нужно, чтобы его продукт продавался, и он это делает так, как умеет. Хотите совместимости со всем вообще — покупайте только такие продукты, голосуйте рублем и ногами. Нет таких — сделайте и постарайтесь продать. Не вышло — значит это не нужно никому, кроме вас, прошу искреннего пардону.
С кэшем там непонятно, потому что ядро там Quark DXk, т.е. кэш может и быть, и не быть, синтезируют что захотят. Почти все написано на верилоге, и поэтому у одного процессора (серверного, например), может быть и L1I, и SRAM, а у другого (атома) — ни того, ни другого.
Я не хочу с вами спорить, я только пояснил, почему ситуация именно такая, а не иная.
Не нравится — не ешьте, меняйте дебильную систему команд на нормальную, предлагайте архитектуры, пишите петиции, делайте свои собственные процессоры так, как вы считаете нужным, и рынок потом вас рассудит.
Предлагать я тоже могу что-угодно, любой степени сложности и реализма, а по факту количество специализированных закрытых контролеров с собственной прошивкой у всех только растет, а количество вещей, реализованных на железе, с каждым поколением уменьшается, потому что делать вещи на железе — дорого.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
Даже с учетом того, что физически разъем выглядит одинаково, его по причинам вполне прозаическим не делают совместимым со всеми режимами, альтернативными или нет, и кабелей таких, по которым все вообще режимы работали бы — нет, и не надо. О чем я и написал, а ваших вопросов теперь понять не могу, т.к. это не я хочу один кабель на все случаи жизни.
Опять же, никто не мешает USB IF послезавтра выпустить еще десяток альтернативных режимов для которых понадобятся свои кабеля, и задача сведется к предыдущей.
Если у вас задача не влезает по сложности в дизайн — это показатель того, что решать ее рано. Ах, надо уже вчера? Ну тогда никто не гарантирует никакого качества, кроме того, что получится. Именно так получается нынешнее ПО, нынешние процессоры и все остальное. Нужно лучше — планируйте, контролируйте, используйте подходящие инструменты, контролируйте, хорошо платите, контролируйте, и не забывайте контролировать, это обязательно.
Пока это все не станет выгодно (т.е. ничем другим от конкурентов отличиться станет невозможно, кроме размера и\или скорости кода), для масс это не будет сделано никогда, потому что это адски дорого, адски долго, а на выходе получаются только примитивные вещи, влезающие в дизайн по ТЗ.
Чтобы бить задачи на подзадачи, нужно ясное видение «что именно строим», и план детальный к нему. По нынешней же моде это все называется жутким словом «водопад» и преподносится дорогими консультантами как жуткое болото, страшный суд, ад и погибель (о том, что так делается любой инженерный проект от моста через реку до ракеты, консультанты умалчивают почти всегда). Теперь у нас в моде эджайл, скрам, канбан и прочее все, призванное ПО не разрабатывать, а выращивать, лепя MVP из песка, тряпок и скотча, чтобы релизить быстрее, потому что иначе деньги кончатся, а инвесторы не дадут новые.
Никто не захотел думать (не знал, не стал заморачиваться, не влезал в строки, не влезал в бюджет, не влезал в целевую производительность, причины точные не знает никто), что процессор можно атаковать с этой стороны. Почему раньше никто не переживал по поводу того, что kernel.dll отображается по фиксированному адресу, а теперь это большая проблема? Почему никто не пытался предотвращать исполнения страниц памяти с данными, а теперь все стараются всеми силами? Почему аппаратура начала вести теневые стеки, подписывать указатели и тегировать динамическую память, а раньше об этом никто не думал?
Все потому, что программирование — оно в основном про то, как выполнить задачу бизнеса при определенном наборе входных данных и выдать относительно приличный результат за относительно же приличное время. Написание программы, работа которой возможна при любых входных параметрах, противостоящей утечкам данных из любых общих ресурсов, тайминг-атакам и всему тому, что появилось за 50 лет противостояния брони и снаряда — это совсем другая задача за совсем другие деньги.
Автору посоветую пойти и попробовать разобраться досконально хотя бы с современными архитектурами, т.е. как оно там все работает «на самом деле», начиная прямо с собирания сумматора из подручных материалов (как у Петцольда в известной книге), написания процессора простейшего на верилоге и так вверх до ЖаваСкрипта со всеми остановками. Где-то на реализации первых сложных команд в микрокоде придет понимание того, что писать все так, чтобы летало, при этом было доступно вчерашним школьникам, масштабировалось, обновлялось, свистело и пердело — просто настолько умопомрачительно дорого по всем параметрам, что позволить себе это могут либо огромные корпорации, либо гениальные энтузиасты (вроде Беллара). Все остальные берут то, что уже есть, и добавляют к нему то, чего еще нет, но хотелось бы иметь, либо комбинируют то, что уже есть, нужным им способом. Да, медленно, да 10 слоев, да эмуляция виртуализации эмуляции, да, никто понять не может толком уже давно, но результат — вот он, решения в массы, деньги в кассы.
Рынку же нафиг не нужна унификация, наоборот каждому игроку нужны свои, ни с чем не совместимые и запатентованные разъемы, кабели, периферия, и собственные стандарты вообще на все, иначе прибыль от продажи всех сопутствующих товаров падает.
Кроме того, если вам сделать один кабель USB-C, по которому можно будет передавать и Thunderbolt, и USB 3.1, и питание, и аудио цифровое и аналоговое, и черта лысого оцифрованного — такой кабель будет толщиной в палец и стоить 50 долларов за метр, а покупать его никто не будет, потому что десяток кабелей попроще можно купить вдесятеро дешевле.
Производителю нужно, чтобы его продукт продавался, и он это делает так, как умеет. Хотите совместимости со всем вообще — покупайте только такие продукты, голосуйте рублем и ногами. Нет таких — сделайте и постарайтесь продать. Не вышло — значит это не нужно никому, кроме вас, прошу искреннего пардону.
Не нравится — не ешьте, меняйте дебильную систему команд на нормальную, предлагайте архитектуры, пишите петиции, делайте свои собственные процессоры так, как вы считаете нужным, и рынок потом вас рассудит.
Предлагать я тоже могу что-угодно, любой степени сложности и реализма, а по факту количество специализированных закрытых контролеров с собственной прошивкой у всех только растет, а количество вещей, реализованных на железе, с каждым поколением уменьшается, потому что делать вещи на железе — дорого.