Архитектура ARM vs x86 что лучше?

Яблоко выкатило свой ARM M1
Вроде по тестам крут ...

 

Не понятно: если у Интела 30 на 4 ядра, это если на каждое, всего должно быть 120 - у каких процессоров?
И если считать по Pavia - "Также Altra оснащен 32 Мбайт кэшем System Level Cache (SLC)" почему не 32 * 80?

 

Читаю сейчас "Reverse Engineering для начинающих", и понимаю, какой же всё таки ARM, говно для практического программирования.
Во первых архитектура идиотская, во вторых сами ассемблеры для армы тоже хреновые, такого как UASM наверно просто не существует!
Хотя хороший ассемблер, да ещё с интелским с синтаксисом, может здорово облегчить программирования. В принципе такой и самому можно сварганить, если есть время, желание, возможности.
Хочется такую архитектуру чтобы брала лучшее из х86, АРМ, МИПС и т.д.
То есть, обязательная развитая индексация, несколько протипов вводных параметров которые не как не привязаны только к каким то отдельным командам; 0 параметров, 1 параметр(регистр; память; непосредственное значение), 2 параметра (регистр, память; память, регистр; регистр, непосредственное значение; память, непосредственное значение).
Иначе говоря можно так.
shl r0, [r1+r2*8]
И так далее. Можно обойтись без сложных команд типа работа со строками.
Так что АРМ это фигня. Полное разочарования.

 

https://ru.bmstu.wiki/Synopsys_ARC

 

Какая глубина анализа, каков уровень аргументации! Сударь сразил глаголом просто наповал.

 

ARM это Риск архитектура а на ней прогить не очень удобно.
ARM не заточен на то что бы бы ручками сидеть на ASM писать.

Это скорее для компиляторов C++ накодил ..а компилер сам там чо нужно сговноляпил

--- Сообщение объединено, 12 дек 2020 ---

берем FPGA делаем свой проц. с блекджеком и ш*юхами

 

Да! На самом деле на АРМе можно таки писать программки на асме. Но тут нужен нормальный компилятор ассемблера, которого просто нет. Стиль очень низкоуровнего асма меня совсем не устраивает, вот в чём проблема. Да, я знаю, что некоторые асматики любят кодить на асме в стиле "очень низкий уровень", типа бейсик спагетти. Типа "что это за говно?", да я уже сам не помню. А ведь на асме можно писать такой код, который может быть понятен каждому.

 

Асм арма не для человека он для компилятора !

 

А почему, в ARM нет команд двухсловных команд, с нормальной загрузкой 32 битной константы?
АРМ может выполнять условно следующую инструкцию, т.е. выполнить её или нет, в зависимости от флагов, а значит легко и не принуждёно прочитать её как константу. То есть, не надо сильно усложнять архитектуру, превращая её в подобие х86, чтобы иметь 8 байтовые или двусловные команды. Скорей всего тут дело политическое, типа RISC такого не предполагает, и всё тут, но это всё бред. Обычные догмы заумных людей!

 

Intro, откройте уже мануал и посмотрите систему команд ARM.

Точнее, на то посмотрите, как эти команды кодируются.

 

Microedition, ничего не заставляет реализовать архитектуру так, чтобы можно было читать 32 константы. Сейчас может уже не получится, надо было с самого начало такую возможность залаживать!

 

Intro, зачем усложнять архитектуру ради чтения каких-то констант? Не нравится -- используйте макронстрккции, как, например, сделали для MIPS.

 

Microedition, а тогда как быстро загрузить 32-битную константу? Из памяти? Желательно чтобы команда была простая, выполнялось за один такт, и в суперскалярных могла выполнится сразу на нескольких конвейерах!

 

Цэшнику на это наплевать, прихоти полутора ассемблерщиков никто исполнять не будет.

 

f13nd, на самом деле, она не нужна! Но надо эффективная загрузка констант из памяти. Я ж говорю АРМ довольно перспективная архитектура, хоть и без недостатков, хотя они потихоньку устраняются. Как там, деление добавили в новых ARM'ах?
В общем, возможно на форуме надо сделать целый раздел для по АРМ процессорам.

 

Немного инфы по ARM
http://www.gaw.ru/html.cgi/txt/doc/micros/arm/index.htm

 

Наверное многие уже видели, но интересно про первый ARM с номером 1, по транзисторам как 8086, но при этом конкурировал с 386, а по сложности даже проще 8086, за счёт блоков с одинаковыми элементами.

 

А это на самом деле сразу была одна из интересных практических задач - как быстро загрузить 32-битную константу имея фиксированные команды в 32 бита и это целая история и она оставила глубокую борозду в долго эволюционировавшей архитектуре ARM как минимум 32-битном.
Сперва предполагалось, что мы загружаем такие константы просто по небольшому смещению относительно ip (instruction pointer). Смещение около [math]\pm 2[/math]Кб влазит в инструкцию и константы надо было просто поместить где-нибудь рядом в дырках возле инструкций которые в них нуждались.
Но шли годы и сильную роль начал играть кеш - нелокальность кода и данных и замусоривание и кеша для кода и кеша для данных когда можно было бы юзать только кеш кода ударять начало по производительности.
Тогда ввели принцип парных команд загрузки нижних и верхних 16 бит. Нижние 16 бит и так уже покрывались какой то существующей командой, поэтому ввели команду LDH - load high. При этом расход байт остаётся тем же, но данные и код уже локальны и работают только с кешем кода.
Но и этого показалось мало и пошли дальше во все тяжкие и придумали инструкции размножающие один байт по некоторой маске, так что константы типа 0xA0A00000 можно загружать одной инструкцией. Детали её забыл, но что-то типа того, что в инструкцию зашит 1 байт и маска в каких байтах результата он лежит (иначе 0).
Можно еще заметить, что компиляторы были умными и до введения новых команд и умели выкручиваться и имитировать загрузку константы через сдвиг, например, там где тоже получалось уложиться в две обычных команды.
Правда что из этого перекочевало в 64-битность и в каком виде не знаю, понятно, что загрузка по смещению от ip есть однозначно, но т.к. команды остались строго 32-битными, то на LDH уже паритет по байтам с ld ip+offset не вытянешь.

 

через 10 лет 9 из 10 виндовсов будут на АРМе
https://blogs.windows.com/windowsde...aunching-arm-advisory-service-for-developers/