Дело в том, что обычный компилятор Си не поддерживает ни WCH-специфичного расширения, ни просто возможности настроить какие регистры надо сохранять.
Не очень понимаю, что им помешало аппаратно пушить только caller-save (согласно ABI) регистры? Тогда обработчик может быть обычной функцией с сигнатурой void name(void) и сам запушит callee-save регистры и всё будет тип-топ. В armv7-m так и сделано, например.
Ну в тех же armv7-m есть недо-SIMD с обработкой 4 байтов или 2 полувордов в одном 32-битном регистре. Так что видимо польза для лоу-энда и эмбеддеда есть.
Про кодировки уже пояснили, я ещё раз поясню что 64-битный процессор МОЖЕТ перейти в 32-битный режим (где обычные команды будут выполнять 32-битные операции, адресовать память 32 битами и исчезнут команды opW). Может, если в нём есть таковая поддержка, и соответствующий бит в CSR можно переключить. А если поддержки нет -- то он работает только в 64-битном режиме.
Оно в обязательном порядке должно выполнять все команды, которые использовались в архитектуре RISC V 32-битного исполнения
Нифига подобного. Если тут речь про 32-битный режим, то он в 64-битном ядре опциональный, например t-head c906 не имеют такогово. Если речь про кодировку 32-битных операций в 64-битном режиме, то они не совпадают с кодировкой таких же по смысле 32-битных операций в 32-битном режиме (или в чисто 32-битном ядре). Ввиду чего отквоченное утверждение получается ниачём.
несколько областей РФ уже может быть достаточно, неплохо комбинировать разные типы генерации.
Во-1, это не британская империя и солнце таки над Россией заходит. Во-2 всё равно остаётся 2 вопроса: первый это насколько больше генерирующих мощностей надо ставить в каждом регионе, чтобы они смогли при необходимости питать все остальные (туда же -- насколько больше линий передач), и второй, какие же всё же оценки вероятности блекаутов даже с такой избыточностью.
Как раз всякая промка легко адаптируется к будущей реальности
И как например к этой замечательной будущей реальности с неизбежными блекаутами может адаптироваться сеть ЖД? После первого же блекаута, причём во всех регионах сразу, понадобится несколько дней (если не недель) на растаскивание всех застрявших поездов и возвращения в график. Не говоря уже о банальных вещах типа замерзания пассажиров в труднодоступных местах без электричества. А промка с непрерывными процессами плавки, где блекаут означает застывание расплава и превращения всего оборудования и сооружений в бесполезный кусок застывшего непойми чего, который дешевле выкинуть и построить заново? Хотелось бы конкретики.
Не знаю, тут уместнее вопрос будет ли уголь с учетом всех экстерналий конкурентоспособен с ВИЭ.
Не кончается, потому что должны быть объединены в сеть.
В какую сеть, например? Размером как весь земной шар? И там прям с 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.
Ага, открываем доку на ARMv8-M и видим всё те же
QADD,QADD16,QADD8,SHADD16и т.д. Ничего не дропнуто.Не очень понимаю, что им помешало аппаратно пушить только caller-save (согласно ABI) регистры? Тогда обработчик может быть обычной функцией с сигнатурой void name(void) и сам запушит callee-save регистры и всё будет тип-топ. В armv7-m так и сделано, например.
Сильный аргумент, спорить после него нет смысла.
Тем временем в Европе:
https://www.cleanenergywire.org/news/short-term-power-prices-spike-amid-new-dunkelflaute-germany-most-customers-unaffected
Ну в тех же armv7-m есть недо-SIMD с обработкой 4 байтов или 2 полувордов в одном 32-битном регистре. Так что видимо польза для лоу-энда и эмбеддеда есть.
Про кодировки уже пояснили, я ещё раз поясню что 64-битный процессор МОЖЕТ перейти в 32-битный режим (где обычные команды будут выполнять 32-битные операции, адресовать память 32 битами и исчезнут команды opW). Может, если в нём есть таковая поддержка, и соответствующий бит в CSR можно переключить. А если поддержки нет -- то он работает только в 64-битном режиме.
Нифига подобного. Если тут речь про 32-битный режим, то он в 64-битном ядре опциональный, например t-head c906 не имеют такогово. Если речь про кодировку 32-битных операций в 64-битном режиме, то они не совпадают с кодировкой таких же по смысле 32-битных операций в 32-битном режиме (или в чисто 32-битном ядре). Ввиду чего отквоченное утверждение получается ниачём.
Во-1, это не британская империя и солнце таки над Россией заходит. Во-2 всё равно остаётся 2 вопроса: первый это насколько больше генерирующих мощностей надо ставить в каждом регионе, чтобы они смогли при необходимости питать все остальные (туда же -- насколько больше линий передач), и второй, какие же всё же оценки вероятности блекаутов даже с такой избыточностью.
И как например к этой замечательной будущей реальности с неизбежными блекаутами может адаптироваться сеть ЖД? После первого же блекаута, причём во всех регионах сразу, понадобится несколько дней (если не недель) на растаскивание всех застрявших поездов и возвращения в график. Не говоря уже о банальных вещах типа замерзания пассажиров в труднодоступных местах без электричества. А промка с непрерывными процессами плавки, где блекаут означает застывание расплава и превращения всего оборудования и сооружений в бесполезный кусок застывшего непойми чего, который дешевле выкинуть и построить заново? Хотелось бы конкретики.
Немного вот тут можно почитать. Инфа не особо новая, но не думаю что сейчас что-то улучшилось, скорее наоборот:
https://naked-science.ru/article/nakedscience/coal-trouble
Там есть и оценки необходимых величин запасов при полном переходе на ВИЭ, и цене таковых запасов и много чего ещё.
В какую сеть, например? Размером как весь земной шар? И там прям с 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