[byRAM 24]

44 минуты назад, yes сказал:

... а изобретать какую-то свою архитектуру вместо RISCV - бессмысленная трата времени. проще говоря: инструкшин декодер это настолько малая часть кода в большом процессоре, что абсолютно пофиг riscv там или уникальная_отечественная_архитектура_с_блэкджеком_и_социально_безответственными_тетками

Хорошо сказано! Вот и получается, что без участия массовой обкатки хороший микропроцессор не сделать, никто из китайских производителей планшетов и смартфонов не рискнёт туда пихать родной китайский, дабы не разориться в случае провала. И место всех этих изысков скорее всего в китайских госучереждениях и в военной технике. Да и то, не факт, что выдержат конкуренцию с клонами американских.

[baumanets 13]

В 30.06.2022 в 16:37, makc сказал:

 

В чем смысл изобретения велосипеда, в самом факте изобретения? Ну так всё получится как всегда: скопируют описание ISA RISC-V, назовут архитектурой "Донбай" и распилят на этом бюджет. Вместо того чтобы участвуя в международной кооперации предложить, реализовать и продвинуть расширения для имеющегося RISC-V, которые бы могли поднять его на новый уровень и устранить узкие места. Китайцы, между прочим, именно так и делают. Метод мягкой силы...

Что власть делает - мне совершенно плевать.

Они в данный исторический момент могут только плодить симулякры в бодрийяровском смысле. 

Вопрос помимо команд операций процессора в статистике их использования. В объективной статистике. 

Если у x86 оператор короткого перехода в  HEX типа 74 XX для условного по флагу. Или безусловного EB XX (пишу по памяти. Если ошибся -поправьте),  то делать костыли для другой архитектуры может не получиться. Вместо 2 байт операция займёт 4. Будут тебя же тормоза. 

Поэтому длина кодов операций должна быть обратно пропорциональна частоте их использования. 

Отвечает ли этому условию RISC-V. Очевидно нет. 

Будет ли этому отвечать RISC-V* с костылями - большой вопрос. 

Все короткие опкоды могут быть заняты. И новые команды придётся впихивать в длинные опкоды заваливая оптимизацию по памяти. 

[artemkad 92]

35 минут назад, baumanets сказал:

Поэтому длина кодов операций должна быть обратно пропорциональна частоте их использования. 

Отвечает ли этому условию RISC-V. Очевидно нет. 

На данном этапе выбор процессора меньше всего связан с длиной опкода не говоря уже о том, что делать 2 байтные команды на 128 битном процессоре может тормозить больше чем все 16 байтные... А уж за один такт загрузить 4 байта без наследия тяжелого прошлого х86-го в опкодах, это уже классика.

[makc 232]

10 часов назад, baumanets сказал:

Поэтому длина кодов операций должна быть обратно пропорциональна частоте их использования. 

Отвечает ли этому условию RISC-V. Очевидно нет. 

Thumb2 тоже не отвечает этому критерию, но работает намного лучше RV32IMC. Почему так? 

[baumanets 13]

В 01.07.2022 в 14:21, yes сказал:

-------------

ну то есть сделать годное ядро - это посильная задача (смотрим тот же syntacore - их yadro купил (?)) - то есть это вполне фаблес задача, для которой не нужно трильярд баксов в котлован закопать. то есть фаблес - это имхо единственный способ для РФ хоть как-то участвовать в производстве полупроводников (если конечно с геополитикой проблемы кончатся) . и опять же процессорное ядро делать - то есть микроархитектуру - это разумная задача, имеющая не только академический, а и коммерческий выхлоп (потенциально) . а изобретать какую-то свою архитектуру вместо RISCV - бессмысленная трата времени. проще говоря: инструкшин декодер это настолько малая часть кода в большом процессоре, что абсолютно пофиг riscv там или уникальная_отечественная_архитектура_с_блэкджеком_и_социально_безответственными_тетками

 

Вот собственно вопрос, чего не сделать этот декодер программируемым. Сначала потестить софт на временной системе команд, а потом сделать оптимизацию опкодов в целях оптимизации по памяти для задач, в первую очередь для неё критичных. 

В 01.07.2022 в 15:13, byRAM сказал:

Хорошо сказано! Вот и получается, что без участия массовой обкатки хороший микропроцессор не сделать, никто из китайских производителей планшетов и смартфонов не рискнёт туда пихать родной китайский, дабы не разориться в случае провала. И место всех этих изысков скорее всего в китайских госучереждениях и в военной технике. Да и то, не факт, что выдержат конкуренцию с клонами американских.

Вот я о том же.  Статистику применения надо набирать на больших объемах. 

В 02.07.2022 в 10:37, makc сказал:

Thumb2 тоже не отвечает этому критерию, но работает намного лучше RV32IMC. Почему так? 

Судя по этим докам thumb отвечает. 

http://www.gaw.ru/html.cgi/txt/doc/micros/arm/arh/arm_3.htm

[makc 232]

19 минут назад, baumanets сказал:

Судя по этим докам thumb отвечает. 

http://www.gaw.ru/html.cgi/txt/doc/micros/arm/arh/arm_3.htm

Я писал про Thumb2. По ссылке просто Thumb и на сколько мне известно сейчас уже не осталось микроконтроллеров, которые могут Tumb и ARM одновременно.

[yes 8]

On 7/2/2022 at 10:42 AM, baumanets said:

Вот собственно вопрос, чего не сделать этот декодер программируемым. Сначала потестить софт на временной системе команд, а потом сделать оптимизацию опкодов в целях оптимизации по памяти для задач, в первую очередь для неё критичных. 

 

Вообще неинтересно объем кода. Шина обычно больше 32, минимум 64, а обычно 512, поэтому по-любому за такт можно выбрать больше инструкций, чем в пайплайн засунуть. Ну если бы это играло роль, что индустрия не придумала бы? Ну а общий формат, когда два регистра источника и один приемник - очень любят компиляторщики. И там без разницы, мипс, арм или riscv. 

Понятно, что можно какие то форт процессоры или энтропийное кодирования инструкций, но это все маргинальное, не знаю примера коммерческого успеха. 

[baumanets 13]

В 02.07.2022 в 11:04, makc сказал:

Я писал про Thumb2. По ссылке просто Thumb и на сколько мне известно сейчас уже не осталось микроконтроллеров, которые могут Tumb и ARM одновременно.

На удивление моё, могут. 

https://stackoverflow.com/questions/28669905/what-is-the-difference-between-the-arm-thumb-and-thumb-2-instruction-encodings

Собственно а тексте и ответ на вопрос. Дело в длине инструкций. 

[makc 232]

25 минут назад, baumanets сказал:

На удивление моё, могут. 

Это два разных режима исполнения программы, выбор режима определяется битом T в регистре CPSR, при этом, на сколько мне известно, в современных Cortex-M* вариант с T=0 не реализуется. Что касается ширины командного слова, то в режиме Thumb-2 оно 16 бит, но если декодер получает на вход код "расширенной" команды, то до её исполнения извлекает ещё 16 бит (всего два слова). Считать ли это 32-разрядной командой - вопрос спорный.

[Arlleex 190]

58 минут назад, makc сказал:

Считать ли это 32-разрядной командой - вопрос спорный.

Почему не считать, если она будет выполнена за 1 такт? Ведь ничто не мешает буферу предвыборки отдавать декодеру по 32 бита за раз.

[makc 232]

30 минут назад, Arlleex сказал:

Почему не считать, если она будет выполнена за 1 такт? Ведь ничто не мешает буферу предвыборки поджирать по 32 бита за раз.

Потому что для её исполнения (формально с точки зрения ISA) тратится два такта на извлечение 2х слов по 16 бит, все остальное, как и буфер предвыборки, это по сути средства снизить влияние этой особенности и вполне допускаю, что они работают, т.е. через этап Execute конвейера проходит одна команда. Т.е. на этапе Fetch это две команды, а на Execute одна, поэтому и спорно.

[baumanets 13]

В 02.07.2022 в 19:24, yes сказал:

Понятно, что можно какие то форт процессоры или энтропийное кодирования инструкций, но это все маргинальное, не знаю примера коммерческого успеха. 

Где про это можно прочитать?

[Obam 38]

...в современных Cortex-M* вариант с T=0 не реализуется... Но есть (говорят, где-то) Cortex-A* (да, медиа-процессоры) и Cortex-R* (тут точно - МК) и с ARM32, и с THUMB2

Изменено 2 июля, 2022 пользователем Obam

[sasamy 0]

On 7/2/2022 at 10:42 AM, baumanets said:

Сначала потестить софт на временной системе команд

венду через бинарный транслятор который превращает процессор в тыкву

[byRAM 24]

55 минут назад, sasamy сказал:

венду через бинарный транслятор который превращает процессор в тыкву

Да прям уж там в тыкву 

Пингвиноводам, пингвиноведам и пингвинофилам пора бы уже понять, что большинству пользователей ПК это условное суперпупербыстродействие линуха не требуется, а нужен широчайший набор возможностей, который линух в принципе не способен предоставить всвязи с его узколобостью и наххренникомуненужностью, кроме пингвиноманов 

Изменено 3 июля, 2022 пользователем byRAM