Не кончается, потому что должны быть объединены в сеть.
В какую сеть, например? Размером как весь земной шар? И там прям с 99.99999% вероятностью никогда не будет блекаутов, синоптики гарантируют? А политики тоже гарантируют, что такая сеть вообще будет когда-либо построена?
Способы хранения уже изобретены и постоянно улучшаются, уже все есть.
Например что и какая стоимость хранения? Только возьмите пример не с чайниками и стиралками, а например с заводами электролиза алюминия, электроплавки стали, ну и например электроснабжения ЖД сети на уровне государства. Где блекаут просто вообще недопустим и приведёт к космическим убыткам. Сколько будет стоить хранение, которое "уже изобретено" по сравнению с кучей угля около ТЭС (фактически бесплатное хранение в любых нужных объёмах)?
Это всё дешёвое электричество с панелек и ветряков кончается ровно в момент штиля или облачности (про ночь даже молчу). И тут оказывается, что или будут регулярные блекауты ввиду погоды, или же надо держать *в запасе* традиционную генерацию. Которая как раз в таких условиях и подключится и обеспечит потребителей. А ввиду того, что теперь традиционная генерация оказывается сильно недоиспользована (тот самый КИУМ), цена для конечных потребителей только возрастёт. И так будет, пока не изобретут способы хранения электричества, сравнимые по эффективности скажем с 10 тысячами тонн угля в куче рядом с ТЭС.
Ваша инфа касательно рельсового транспорта устарела лет эдак на 40.
Весь современный подвижной состав ездит на асинхронных или "вентильных" двигателях, и для них ВСЕГДА нужен тяговый инвертор. Которому по барабану, рекуперировать в провод или жрать мощность из провода. Что на постоянке, что на переменке (в последнем случае -- через тяговый трансформатор, очевидно). И единственная проблема с рекуперацией -- потери, которые наиболее выражены в случае постоянки (малое напряжение, "длинная" и изолированная от энергосистемы контактная сеть). В случае с переменкой энергосистема может сожрать произвольную мощность рекуперации в любой момент.
Каковые могут жить с 2 портами чтения регистрового файла пока конвеер простой и один. Как только эти команды начинают работать на суперскалярном процессоре, СРАЗУ ЖЕ появляется зависимость от rd: его всегда необходимо читать и всегда писать. По-другому суперскаляры не умеют.
обычные операции АЛУ, ничем архитектурно не отличающиеся от, например, add
Отличающиеся. Тем, что или rd обновляется не всегда (простой конвеер) или rd является одним из операндов (суперскаляр).
Здесь ответ очевиден — переход не самая удачная идея, поскольку не слишком хорошо сочетается с конвейером. Но есть еще и вариант с условным исполнением команд, и он вполне приемлем
Есть мнение, что ситуация ровно обратная. Условные переходы предсказываются задолго до попадания операций в вычислительный конвеер и как правило с очень хорошей точностью. А вот команды с предикатами, как в том же 32-битном арме -- это ад с т.з. структуры конвеера. Начиная с необходимости +1 порта чтения у регистрового файла (регистр-приёмник может или записаться или нет только в простом несуперскалярном единственном конвеере как у arm7tdmi, а во "взрослой" суперскалярной архитектуре это будет дополнительный операнд у команды) и кончая всеми теми милыми приколами, когда предикатная операция решит записать в pc. Ну и конечно же, дополнительные зависимости по флагам, что отнюдь не облегчает шедулинг.
Если такое захотят проделать одновременно например главный тред и прерывание, или два разных треда (в случае RTOS), или прерывания разных преемптивных приоритетов, всё это с разными битами в одном и том же регистре, то произойдёт катастрофа. Можно запрещать прерывания вхлам и потом разрешать (будет критическая секция). НО: в cortex-m3/m4 есть спец. область адресного пр-ва, где запись в конкретный ворд нуля или ненуля мапится аппаратно (т.е. непрерываемой последовательностью read-modify-write) в изменение бита в регистре или памяти.
Соотв-но вопрос, а что есть на эту тему в этих ядрах risc-v?
Поддержка команд вида amo* ? Поддержка механизма lr/sc ?
Это не в разрыв а параллельно. Запинывать таким образом что-то из того что не шлёт сама клава -- будет уже жутким извратом с деланием КЗ клаве и пиханием своих пакетов. И штатные usb-devic'ы в МК это уже точно не смогут.
Честно работает в разрыв клавиатуры -- USB-хаб. Если вы хотите это сделать на двух полностью независимых подсистемах (usb-host и usb-device) с программной связью между ними -- не факт, что это в принципе получится. А если получится -- это будет извратом.
То есть, там изобрели свой велосипед вместо argon2 (ну или просто взяли старый pbkdf2)? Ну, значит вам повезло, иначе argon2 вы бы физически не смогли бы посчитать на вашем дохлоконтроллере (не хватило бы ОЗУ).
Никаких пассов, чтобы загрузить qemu через MBR c virtio, не нужно. В самом деле, биос для кему в курсе о virtio, далее естественно бутлоадер должен быть в курсе (иметь драйвер), grub вполне имеет. Ну и наконец, само ядро, оно тоже в курсе (если нужный драйвер вкомпилирован или в виде модуля подпихнут из initramfs).
Нельзя создать диск "sata" c интерфейсом "virtio". sata или virtio в qemu -- это какую "виртуальную", то есть эмулируемую железку покажут виртуализированным ОС/бутлоадеру/биосу. А сам диск -- это просто посекторный образ из файла. Ну или не просто посекторный, если например qcow2.
На чип I2C ставить аналоговый ключ для электронного пере сброса электропитания на этом чипе по GPIO от MCU. Тогда в случае зависания можно будет пере инициализировать и хоть как-то дальше работать.
Это вообще не гарантия. После отрубания питания чип может оказаться запитанным phantom-питанием и его автомат останется в зависшем состоянии.
AMD64 процессор после ресета запускается в "реальном" режиме (самое дно костыльных слоёв), а при необходимости может из "лонг" режима (пока ещё поверхность костыльного океана) вернуться обратно в "реальный" (так работают CSM в теперешних биосах). О чём вы пытаетесь мне возразить -- решительно не понимаю.
Мне, честно говоря, не очень хочется понимать разницу между N+1ым и Nым слоями густо рассыпанных и скреплённых скотчем костылей. У меня есть материнка 2020 года, и она прекрасно бутится с MBR, работая очевидно в 8086-режиме или как вы его там называете костыльно-одобренным словом. Если вдруг биос в материнке так не умеет, то виртуалка сможет всегда -- из того же qemu (на пару с kvm) MBR-загрузку никто не выпилил ещё. Следовательно, мой тезис о том, что в процессорах блюдётся совместимость с 8086 -- верен. При желании и необходимости даже дос можно запустить без эмуляции. В отличие от маков.
initramfs -- по сути вполне себе userspace, а не "ядро-одиночка", "ядро само по себе" и т.д.
Чтоб запустить в виртуалке ядро с initramfs, не нужно никаких образов дисков, форматирований, загрузчиков и проч. Для qemu есть опции запуска конкретного ядра и initramfs, взятых файлами из хостовой ОС. Как там в гуеподелке и виртуальной коробке -- не в курсе.
Если "системы" это "ос", то вот тут пишут что разрешают: https://en.wikipedia.org/wiki/Wine_(software)#Backward_compatibility . Если это "процессоры", то нет. Любой 64-битный amd64 проц способен запустить DOS несмотря ни на какие ограничения в "long mode" и проч. Ещё есть разница между виртуализацией (фактически только эмуляция периферии и немножко -- MMU) и эмуляцией (эмуляция всего процессора софтово).
В какую сеть, например? Размером как весь земной шар? И там прям с 99.99999% вероятностью никогда не будет блекаутов, синоптики гарантируют? А политики тоже гарантируют, что такая сеть вообще будет когда-либо построена?
Например что и какая стоимость хранения? Только возьмите пример не с чайниками и стиралками, а например с заводами электролиза алюминия, электроплавки стали, ну и например электроснабжения ЖД сети на уровне государства. Где блекаут просто вообще недопустим и приведёт к космическим убыткам. Сколько будет стоить хранение, которое "уже изобретено" по сравнению с кучей угля около ТЭС (фактически бесплатное хранение в любых нужных объёмах)?
Это всё дешёвое электричество с панелек и ветряков кончается ровно в момент штиля или облачности (про ночь даже молчу). И тут оказывается, что или будут регулярные блекауты ввиду погоды, или же надо держать *в запасе* традиционную генерацию. Которая как раз в таких условиях и подключится и обеспечит потребителей. А ввиду того, что теперь традиционная генерация оказывается сильно недоиспользована (тот самый КИУМ), цена для конечных потребителей только возрастёт. И так будет, пока не изобретут способы хранения электричества, сравнимые по эффективности скажем с 10 тысячами тонн угля в куче рядом с ТЭС.
Ваша инфа касательно рельсового транспорта устарела лет эдак на 40.
Весь современный подвижной состав ездит на асинхронных или "вентильных" двигателях, и для них ВСЕГДА нужен тяговый инвертор. Которому по барабану, рекуперировать в провод или жрать мощность из провода. Что на постоянке, что на переменке (в последнем случае -- через тяговый трансформатор, очевидно). И единственная проблема с рекуперацией -- потери, которые наиболее выражены в случае постоянки (малое напряжение, "длинная" и изолированная от энергосистемы контактная сеть). В случае с переменкой энергосистема может сожрать произвольную мощность рекуперации в любой момент.
Каковые могут жить с 2 портами чтения регистрового файла пока конвеер простой и один. Как только эти команды начинают работать на суперскалярном процессоре, СРАЗУ ЖЕ появляется зависимость от rd: его всегда необходимо читать и всегда писать. По-другому суперскаляры не умеют.
Отличающиеся. Тем, что или rd обновляется не всегда (простой конвеер) или rd является одним из операндов (суперскаляр).
Есть мнение, что ситуация ровно обратная. Условные переходы предсказываются задолго до попадания операций в вычислительный конвеер и как правило с очень хорошей точностью. А вот команды с предикатами, как в том же 32-битном арме -- это ад с т.з. структуры конвеера. Начиная с необходимости +1 порта чтения у регистрового файла (регистр-приёмник может или записаться или нет только в простом несуперскалярном единственном конвеере как у arm7tdmi, а во "взрослой" суперскалярной архитектуре это будет дополнительный операнд у команды) и кончая всеми теми милыми приколами, когда предикатная операция решит записать в pc. Ну и конечно же, дополнительные зависимости по флагам, что отнюдь не облегчает шедулинг.
Ну вот я и спрашиваю, в ядрах которые в этих МК -- есть атомики?
li t0, PORTB_OCTLlw t1, 0(t0)xori t1, t1, (1<<LED)sw t1, 0(t0)Если такое захотят проделать одновременно например главный тред и прерывание, или два разных треда (в случае RTOS), или прерывания разных преемптивных приоритетов, всё это с разными битами в одном и том же регистре, то произойдёт катастрофа. Можно запрещать прерывания вхлам и потом разрешать (будет критическая секция). НО: в cortex-m3/m4 есть спец. область адресного пр-ва, где запись в конкретный ворд нуля или ненуля мапится аппаратно (т.е. непрерываемой последовательностью read-modify-write) в изменение бита в регистре или памяти.
Соотв-но вопрос, а что есть на эту тему в этих ядрах risc-v?
Поддержка команд вида
amo*?Поддержка механизма
lr/sc?Это не в разрыв а параллельно. Запинывать таким образом что-то из того что не шлёт сама клава -- будет уже жутким извратом с деланием КЗ клаве и пиханием своих пакетов. И штатные usb-devic'ы в МК это уже точно не смогут.
Честно работает в разрыв клавиатуры -- USB-хаб. Если вы хотите это сделать на двух полностью независимых подсистемах (usb-host и usb-device) с программной связью между ними -- не факт, что это в принципе получится. А если получится -- это будет извратом.
То есть, там изобрели свой велосипед вместо argon2 (ну или просто взяли старый pbkdf2)? Ну, значит вам повезло, иначе argon2 вы бы физически не смогли бы посчитать на вашем дохлоконтроллере (не хватило бы ОЗУ).
Никаких пассов, чтобы загрузить qemu через MBR c virtio, не нужно. В самом деле, биос для кему в курсе о virtio, далее естественно бутлоадер должен быть в курсе (иметь драйвер), grub вполне имеет. Ну и наконец, само ядро, оно тоже в курсе (если нужный драйвер вкомпилирован или в виде модуля подпихнут из initramfs).
Нельзя создать диск "sata" c интерфейсом "virtio". sata или virtio в qemu -- это какую "виртуальную", то есть эмулируемую железку покажут виртуализированным ОС/бутлоадеру/биосу. А сам диск -- это просто посекторный образ из файла. Ну или не просто посекторный, если например qcow2.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=BPF
Я использую именно iptables-legacy и именно с netfilter в ядре.
А точно стоит? Всякоразные дырки в BPF находят чуть ли не несколько раз в год.
Это вообще не гарантия. После отрубания питания чип может оказаться запитанным phantom-питанием и его автомат
останется в зависшем состоянии.
AMD64 процессор после ресета запускается в "реальном" режиме (самое дно костыльных слоёв), а при необходимости может из "лонг" режима (пока ещё поверхность костыльного океана) вернуться обратно в "реальный" (так работают CSM в теперешних биосах). О чём вы пытаетесь мне возразить -- решительно не понимаю.
Мне, честно говоря, не очень хочется понимать разницу между N+1ым и Nым слоями густо рассыпанных и скреплённых скотчем костылей. У меня есть материнка 2020 года, и она прекрасно бутится с MBR, работая очевидно в 8086-режиме или как вы его там называете костыльно-одобренным словом. Если вдруг биос в материнке так не умеет, то виртуалка сможет всегда -- из того же qemu (на пару с kvm) MBR-загрузку никто не выпилил ещё. Следовательно, мой тезис о том, что в процессорах блюдётся совместимость с 8086 -- верен. При желании и необходимости даже дос можно запустить без эмуляции. В отличие от маков.
Замечания по статье и комментариям:
initramfs -- по сути вполне себе userspace, а не "ядро-одиночка", "ядро само по себе" и т.д.
Чтоб запустить в виртуалке ядро с initramfs, не нужно никаких образов дисков, форматирований, загрузчиков и проч. Для
qemuесть опции запуска конкретного ядра и initramfs, взятых файлами из хостовой ОС. Как там в гуеподелке и виртуальной коробке -- не в курсе.Если "системы" это "ос", то вот тут пишут что разрешают: https://en.wikipedia.org/wiki/Wine_(software)#Backward_compatibility . Если это "процессоры", то нет. Любой 64-битный amd64 проц способен запустить DOS несмотря ни на какие ограничения в "long mode" и проч.
Ещё есть разница между виртуализацией (фактически только эмуляция периферии и немножко -- MMU) и эмуляцией (эмуляция всего процессора софтово).