Сообщение Re[14]: История компьютеров в СССР от 05.10.2023 1:16
Изменено 05.10.2023 1:29 vdimas
Re[14]: История компьютеров в СССР
Здравствуйте, netch80, Вы писали:
V>>Если сегодня самые-самые простые RISC-микрики имеют конвейер длиной 4, как сам думаешь? ))
N>А зачем вспоминать "самые-самые простые", когда по контексту они точно ни при чём?
Просто самые простейшие уже отвечают на вопрос (исполняют одну команду за несколько шагов).
Более навороченные и подавно.
N>Коды условий должны быть — как в SPARC, ARM, POWER — или нет, как в MIPS, Alpha, RISC-V? Собери обоснования и попробуй доказать, кто из них прав, а кто презренный самец большой мерзкой кошки.
Это смотря какой файл регистров.
Например, в PIC-ах есть операция наложения маски на любой регистр из файла 128 штук и последующего ветвления по нулю или не нулю (через пропуск команды).
Часть регистров — системные, например, флаги нуля предыдущей операции, флаг переноса и т.д.
Т.е. одной командой покрыли как ветвление по маске обычного регистра, как и системных (как флагов, так и IO на ногах).
Поэтому, сравнимые возможности есть, но их умудрились упаковать в продуманный набор инструкций.
Т.е., набор инструкций влияет на архитектуру чипа и наборот тоже верно — это взаимосвязанные вещи, разрабатываемые в комплексе.
N>ARM/32 имел хитрую схему векторных регистров, когда, например, D0 состоит из S0 и S1. ARM/64 похерил это. В MIPS-R раннем 64-битном (поздние не видел) 64-битный регистр это пара 32-битных (типа R2+R3),
ХЗ, в MIPS64 всё те же 32 регистра, просто уже 64 бит.
N>распределители в компиляторах сходят с ума в попытке укладки. Кто прав?
А что тут не так, в сравнении с другими архитектурами? ))
В целом, задумка MIPS была понятной — инструкции фиксированной длины в слово, что позволило упростить дешифратор, упорядочить внутреннюю синхронизацию, а потом в камне разогнать частоту проца вдвое выше пней.
N>ARM по умолчанию когда кладёт более короткое значение в регистр — расширяет его нулями.
В MIPS есть команда загрузки беззнакового байта — lbu.
N>RISC-V аналогично расширяет знаково, размножая старший бит, причём настаивает в ABI на таком расширении при передаче через границу функции даже для коротких беззнаковых.
N>Оба почти что с пеной у рта доказывают свою правоту (RISC-V — в родной доке, ARM — в высказываниях сотрудников).
N>Кто прав?
Зависит от возможности независимого оперирования частями регистра.
В эпоху битовыжимания это было важно.
Сейчас не особо актуально, т.к. исходник оперирует обычно тупо интами или size_t, хотя почти никогда этого не требуется, просто никто уже не жмётся на ширине переменных, берут с запасом.
Давно ты в исходниках видел short и byte, если речь не идёт о строке или бестиповых байт памяти? ))
То бишь, сейчас можно уже автоматом расширять, не боясь, что это создаст сложности там, где расширять не требуется, потому что таких мест в реальной программе исчезающе мало.
N>MIPS-R содержит пачку команд с trap-ом на знаковом переполнении. Реально даже родные компиляторы их не использовали, а уж тотально всё победившие gcc + clang — тем более. Поддерживать надо, использование — фиг. Лучше бы как в ARM сделали adds/subs/etc. в отдельный регистр.
Какой отдельный?
N>Они правы или опять ХЗ что?
MIPS позволяет указывать dst-регистр явно.
И по-другому в этом огромном (на момент разработки архитектуры) файле регистров было бы неразумно.
Зато исключаются бесконечные внутрирегистровые пересылки и прочие пары push/pop.
Я же говорил выше — система команд зависит от архитектуры и наоборот тоже верно.
Например, трехрегистровая кодировка позволила ввести команду условного move, когда перемещение м/у двумя регистрами выполняется, в зависимости от значения в третьем.
Тут простор для оптимизаций большой, разве что MIPS давно не основной мейнстрим, т.е. я бы не ожидал от gcc многого.
N>И почему нет аналогичных для беззнакового переполнения?
А в чём заключается вопрос?
По ARM-у я не очень, скорее никак — просто на уровне представлений об архитектуре проца, но в возможности ни разу глубоко не вникал, бо нелюбопытно — когда вникал всего один раз давно, то увидел, что эта архитектура не проектировалась для упора на вычисления, в отличие от того же MIPS, который изначально был неплох даже в качестве сигнального проца.
Поэтому, для меня ARM несколько скучен...
Хотя, я понимаю причины, почему он когда-то взлетел — из-за низкого энергопотребления.
Но сегодня ARM64 уже не торт, уже всё всерьёз, на уровне MIPS... но мейстрим уже был захвачен армами.
Хотя, китайцам пох, они развивают архитектуру MIPS аж бегом, просто не в мобильном сегменте.
N>Часть архитектур знает пустой регистр (крайне ценно для RISC), часть — нет (ARM/32 не имел). Нужен или нет? Методы построения всей системы после этого меняются чуть более чем полностью.
Дык, кодировка же! ))
Если нулевой регистр — то имеем абсолютную адресацию...
А команда та же, что и для относительной адресации по регистру+смещение.
N>Ладно, предположим, ты только про "кодировку", хотя это ничтожная часть всей задачи... В SPARC вызов функции по смещению от PC получает 30-битное смещение (да-да, 1/4 всего пространства кодов), после сдвига влево на 2 бита получаем полное 32-битное пространство. Это правильно или нет, по сравнению с более короткими в конкурентах? Обоснование — в студию.
Спарки можно рассматривать как продолжение MIPS-архитектуры в сторону увеличения эффективности (окна регистров).
Там слишком много похожего.
V>>Например, гарвардское семейство PIC имеет 12-битные инструкции, ветвление там происходит через трюк "условно пропустить следующую инструкцию", адрес инструкции — не в байтах, это адрес слова. Зато уложились в 12 бит.
V>>В ARM и AVR условный переход всегда относительный (относительно текущего счётчика команд), т.к. ширина адреса `уже, чем полное адресное пространство.
V>>В то же время, каждая инструкция в ARM имеет 32 бита, поэтому младшие 2 бита адреса в команде не кодируются.
V>>В этом месте очевидно, что безусловные jmp/call должны кодироваться не более 4-мя битами, отдавая остальные биты под адрес границы 32-битного слова.
N>Смотрю в AArch64. "B", "BL" — 6 фиксированных, 26 бит на смещение. Итого 28 бит (со знаком). А вот SPARC, наоборот, сделал ещё шире этот литерал. Не соглашаются они с тобой, оба, но по-разному
Значит, арму не хватило пространства кодов, что не смог выделить больше бит под адрес.
В целом, это более экономная, более жадная архитектура -пытается повысить не эффективность исполнения, а размер образа.
В MIPS/SPARC наоборот, при проектировании архитектур во главу угла ставилась эффективность.
Поэтому, армы предазначались для персоналок и встраиваемых решений, а MIPS/SPARC — для рабочих станций и серверов.
И когда сегодня говорят, что вот сервак на армах делают...
Это
Понятно, что из-за массовости камни эти дешевле при топовых процессе исполнения, но не лучше ли массово выпускать на том же процессе более пригодные для сервера архитектуры? ))
V>>>>По тем временам — типичная задача для подобных комплексов, бо на управляющей машине монитор периферии, графики в реальном времени и это всё.
N>>>А какая доля таких комплексов от всех PC?
V>>Ну, тогда еще во всех офисах PC не стояли, поэтому доля инструментального применения персоналок была весьма высокой.
N>Ты хоть бы приблизительно цифру прикинул...
Где-то в разы меньше, чем в офисах, но разницы даже на порядок не видел.
Сегодня же любые терминалы, любые пульты управления станками, любое локальное серверное хранилище — это тоже персоналки по архитектуре, просто исполнение внешне другое.
Поэтому, можно поспорить и о сегодняшних раскладах. ))
Возможно, что "там" инструментальное исполнение было доступным "сразу", но у нас были только массово хлынувшие б/у персоналки, поэтому вся инструменталка одно время делалась на них.
V>>>>Для разных регистров получилась разная кодировка, плюс префиксы для новых команд, чтобы "остальные" регистры стали "как все" и т.д.
N>>>Ты о каком этапе-то? Для x86-16, x86-32 она тут одинаковая, в 32 даже ровнее.
V>>Разве ровнее? ))
N>Я про то, что база и индекс адресации — любой из 8.
Но кодировки под разные регистры иногда разные, в отличие от ортогональных архитектур.
V>>https://3dnews.ru/1087156/intel-predlogila-x64s-iskonno-64bitniy-variant-arhitekturi-x86-dlya-budushchih-cpu
N>Да, тут было обсуждение. Я одного не понял — они хотят чтобы страничная адресация вообще не выключалась, а кто её будет настраивать со старта? ME в южном мосту?
Со старта можно в плоскую память, ИМХО.
V>>https://3dnews.ru/1090501/intel-predstavila-apx-rasshireniya-arhitekturi-x8664-kotorie-uskoryat-lyuboe-po
N>Ну как наворот поверх существующей схемы — ok.
Не-не-не ))
То бишь, можно будет постепенно отказаться от "франкенштейна" в традиционной кодировке.
А потом однажды перекодировать команды, убрав уже ненужные префиксы, что сократит размер образа. ))
N>"Догнать и перегнать ARM". А когда от TSO начнут отходить?
Ну, ARM поступили правильно в ARM64 — в новую жизнь без старых долгов.
А вот AMD64 поднасрала, конечно...
N>Но если бы на этом этапе проектировали с нуля, то мне кажется, что подход с полностью переменной схемой (в стиле CBOR и отдельными элементами в le128) декодировался бы не дороже.
Речь идёт о том, чтобы сделать сам дешифратор проще.
Причём, в ортогональной схеме он получается проще в разы.
А это важно как для будущего увеличения кол-ва ядер, так и для будущего увеличения степени параллельности гипертрединга (до 16 аппаратных потоков на ядро было бы неплохо — и это самый начальный минимум).
(Самый первый гипертрединг в спарках был, вроде, сразу 4 потока — ИМХО, потому что дешифратор в разы дешевле, чем в x86/x64 архитектуре)
V>>Если сегодня самые-самые простые RISC-микрики имеют конвейер длиной 4, как сам думаешь? ))
N>А зачем вспоминать "самые-самые простые", когда по контексту они точно ни при чём?
Просто самые простейшие уже отвечают на вопрос (исполняют одну команду за несколько шагов).
Более навороченные и подавно.
N>Коды условий должны быть — как в SPARC, ARM, POWER — или нет, как в MIPS, Alpha, RISC-V? Собери обоснования и попробуй доказать, кто из них прав, а кто презренный самец большой мерзкой кошки.
Это смотря какой файл регистров.
Например, в PIC-ах есть операция наложения маски на любой регистр из файла 128 штук и последующего ветвления по нулю или не нулю (через пропуск команды).
Часть регистров — системные, например, флаги нуля предыдущей операции, флаг переноса и т.д.
Т.е. одной командой покрыли как ветвление по маске обычного регистра, как и системных (как флагов, так и IO на ногах).
Поэтому, сравнимые возможности есть, но их умудрились упаковать в продуманный набор инструкций.
Т.е., набор инструкций влияет на архитектуру чипа и наборот тоже верно — это взаимосвязанные вещи, разрабатываемые в комплексе.
N>ARM/32 имел хитрую схему векторных регистров, когда, например, D0 состоит из S0 и S1. ARM/64 похерил это. В MIPS-R раннем 64-битном (поздние не видел) 64-битный регистр это пара 32-битных (типа R2+R3),
ХЗ, в MIPS64 всё те же 32 регистра, просто уже 64 бит.
N>распределители в компиляторах сходят с ума в попытке укладки. Кто прав?
А что тут не так, в сравнении с другими архитектурами? ))
В целом, задумка MIPS была понятной — инструкции фиксированной длины в слово, что позволило упростить дешифратор, упорядочить внутреннюю синхронизацию, а потом в камне разогнать частоту проца вдвое выше пней.
N>ARM по умолчанию когда кладёт более короткое значение в регистр — расширяет его нулями.
В MIPS есть команда загрузки беззнакового байта — lbu.
N>RISC-V аналогично расширяет знаково, размножая старший бит, причём настаивает в ABI на таком расширении при передаче через границу функции даже для коротких беззнаковых.
N>Оба почти что с пеной у рта доказывают свою правоту (RISC-V — в родной доке, ARM — в высказываниях сотрудников).
N>Кто прав?
Зависит от возможности независимого оперирования частями регистра.
В эпоху битовыжимания это было важно.
Сейчас не особо актуально, т.к. исходник оперирует обычно тупо интами или size_t, хотя почти никогда этого не требуется, просто никто уже не жмётся на ширине переменных, берут с запасом.
Давно ты в исходниках видел short и byte, если речь не идёт о строке или бестиповых байт памяти? ))
То бишь, сейчас можно уже автоматом расширять, не боясь, что это создаст сложности там, где расширять не требуется, потому что таких мест в реальной программе исчезающе мало.
N>MIPS-R содержит пачку команд с trap-ом на знаковом переполнении. Реально даже родные компиляторы их не использовали, а уж тотально всё победившие gcc + clang — тем более. Поддерживать надо, использование — фиг. Лучше бы как в ARM сделали adds/subs/etc. в отдельный регистр.
Какой отдельный?
N>Они правы или опять ХЗ что?
MIPS позволяет указывать dst-регистр явно.
И по-другому в этом огромном (на момент разработки архитектуры) файле регистров было бы неразумно.
Зато исключаются бесконечные внутрирегистровые пересылки и прочие пары push/pop.
Я же говорил выше — система команд зависит от архитектуры и наоборот тоже верно.
Например, трехрегистровая кодировка позволила ввести команду условного move, когда перемещение м/у двумя регистрами выполняется, в зависимости от значения в третьем.
Тут простор для оптимизаций большой, разве что MIPS давно не основной мейнстрим, т.е. я бы не ожидал от gcc многого.
N>И почему нет аналогичных для беззнакового переполнения?
А в чём заключается вопрос?
По ARM-у я не очень, скорее никак — просто на уровне представлений об архитектуре проца, но в возможности ни разу глубоко не вникал, бо нелюбопытно — когда вникал всего один раз давно, то увидел, что эта архитектура не проектировалась для упора на вычисления, в отличие от того же MIPS, который изначально был неплох даже в качестве сигнального проца.
Поэтому, для меня ARM несколько скучен...
Хотя, я понимаю причины, почему он когда-то взлетел — из-за низкого энергопотребления.
Но сегодня ARM64 уже не торт, уже всё всерьёз, на уровне MIPS... но мейстрим уже был захвачен армами.
Хотя, китайцам пох, они развивают архитектуру MIPS аж бегом, просто не в мобильном сегменте.
N>Часть архитектур знает пустой регистр (крайне ценно для RISC), часть — нет (ARM/32 не имел). Нужен или нет? Методы построения всей системы после этого меняются чуть более чем полностью.
Дык, кодировка же! ))
Если нулевой регистр — то имеем абсолютную адресацию...
А команда та же, что и для относительной адресации по регистру+смещение.
N>Ладно, предположим, ты только про "кодировку", хотя это ничтожная часть всей задачи... В SPARC вызов функции по смещению от PC получает 30-битное смещение (да-да, 1/4 всего пространства кодов), после сдвига влево на 2 бита получаем полное 32-битное пространство. Это правильно или нет, по сравнению с более короткими в конкурентах? Обоснование — в студию.
Спарки можно рассматривать как продолжение MIPS-архитектуры в сторону увеличения эффективности (окна регистров).
Там слишком много похожего.
V>>Например, гарвардское семейство PIC имеет 12-битные инструкции, ветвление там происходит через трюк "условно пропустить следующую инструкцию", адрес инструкции — не в байтах, это адрес слова. Зато уложились в 12 бит.
V>>В ARM и AVR условный переход всегда относительный (относительно текущего счётчика команд), т.к. ширина адреса `уже, чем полное адресное пространство.
V>>В то же время, каждая инструкция в ARM имеет 32 бита, поэтому младшие 2 бита адреса в команде не кодируются.
V>>В этом месте очевидно, что безусловные jmp/call должны кодироваться не более 4-мя битами, отдавая остальные биты под адрес границы 32-битного слова.
N>Смотрю в AArch64. "B", "BL" — 6 фиксированных, 26 бит на смещение. Итого 28 бит (со знаком). А вот SPARC, наоборот, сделал ещё шире этот литерал. Не соглашаются они с тобой, оба, но по-разному
Значит, арму не хватило пространства кодов, что не смог выделить больше бит под адрес.
В целом, это более экономная, более жадная архитектура -пытается повысить не эффективность исполнения, а размер образа.
В MIPS/SPARC наоборот, при проектировании архитектур во главу угла ставилась эффективность.
Поэтому, армы предазначались для персоналок и встраиваемых решений, а MIPS/SPARC — для рабочих станций и серверов.
И когда сегодня говорят, что вот сервак на армах делают...
Это
Понятно, что из-за массовости камни эти дешевле при топовых процессе исполнения, но не лучше ли массово выпускать на том же процессе более пригодные для сервера архитектуры? ))
V>>>>По тем временам — типичная задача для подобных комплексов, бо на управляющей машине монитор периферии, графики в реальном времени и это всё.
N>>>А какая доля таких комплексов от всех PC?
V>>Ну, тогда еще во всех офисах PC не стояли, поэтому доля инструментального применения персоналок была весьма высокой.
N>Ты хоть бы приблизительно цифру прикинул...
Где-то в разы меньше, чем в офисах, но разницы даже на порядок не видел.
Сегодня же любые терминалы, любые пульты управления станками, любое локальное серверное хранилище — это тоже персоналки по архитектуре, просто исполнение внешне другое.
Поэтому, можно поспорить и о сегодняшних раскладах. ))
Возможно, что "там" инструментальное исполнение было доступным "сразу", но у нас были только массово хлынувшие б/у персоналки, поэтому вся инструменталка одно время делалась на них.
V>>>>Для разных регистров получилась разная кодировка, плюс префиксы для новых команд, чтобы "остальные" регистры стали "как все" и т.д.
N>>>Ты о каком этапе-то? Для x86-16, x86-32 она тут одинаковая, в 32 даже ровнее.
V>>Разве ровнее? ))
N>Я про то, что база и индекс адресации — любой из 8.
Но кодировки под разные регистры иногда разные, в отличие от ортогональных архитектур.
V>>https://3dnews.ru/1087156/intel-predlogila-x64s-iskonno-64bitniy-variant-arhitekturi-x86-dlya-budushchih-cpu
N>Да, тут было обсуждение. Я одного не понял — они хотят чтобы страничная адресация вообще не выключалась, а кто её будет настраивать со старта? ME в южном мосту?
Со старта можно в плоскую память, ИМХО.
V>>https://3dnews.ru/1090501/intel-predstavila-apx-rasshireniya-arhitekturi-x8664-kotorie-uskoryat-lyuboe-po
N>Ну как наворот поверх существующей схемы — ok.
Не-не-не ))
Это позволит кодировать многие операции более чем одним способом — как в новом формате, так и в традиционном.добавление трёхоперандного формата большинству существующих целочисленных инструкций;
добавление дополнительных условных инструкций для облегчения предсказания переходов;
а также новую 64-битную инструкцию безусловного перехода.
То бишь, можно будет постепенно отказаться от "франкенштейна" в традиционной кодировке.
А потом однажды перекодировать команды, убрав уже ненужные префиксы, что сократит размер образа. ))
N>"Догнать и перегнать ARM". А когда от TSO начнут отходить?
Ну, ARM поступили правильно в ARM64 — в новую жизнь без старых долгов.
А вот AMD64 поднасрала, конечно...
N>Но если бы на этом этапе проектировали с нуля, то мне кажется, что подход с полностью переменной схемой (в стиле CBOR и отдельными элементами в le128) декодировался бы не дороже.
Речь идёт о том, чтобы сделать сам дешифратор проще.
Причём, в ортогональной схеме он получается проще в разы.
А это важно как для будущего увеличения кол-ва ядер, так и для будущего увеличения степени параллельности гипертрединга (до 16 аппаратных потоков на ядро было бы неплохо — и это самый начальный минимум).
(Самый первый гипертрединг в спарках был, вроде, сразу 4 потока — ИМХО, потому что дешифратор в разы дешевле, чем в x86/x64 архитектуре)
Re[14]: История компьютеров в СССР
Здравствуйте, netch80, Вы писали:
V>>Если сегодня самые-самые простые RISC-микрики имеют конвейер длиной 4, как сам думаешь? ))
N>А зачем вспоминать "самые-самые простые", когда по контексту они точно ни при чём?
Просто самые простейшие уже отвечают на вопрос (исполняют одну команду за несколько шагов).
Более навороченные и подавно.
N>Коды условий должны быть — как в SPARC, ARM, POWER — или нет, как в MIPS, Alpha, RISC-V? Собери обоснования и попробуй доказать, кто из них прав, а кто презренный самец большой мерзкой кошки.
Это смотря какой файл регистров.
Например, в PIC-ах есть операция наложения маски на любой регистр из файла 128 штук и последующего ветвления по нулю или не нулю (через пропуск команды).
Часть регистров — системные, например, флаги нуля предыдущей операции, флаг переноса и т.д.
Т.е. одной командой покрыли как ветвление по маске обычного регистра, как и системных (как флагов, так и IO на ногах).
Поэтому, сравнимые возможности есть, но их умудрились упаковать в продуманный набор инструкций.
Т.е., набор инструкций влияет на архитектуру чипа и наборот тоже верно — это взаимосвязанные вещи, разрабатываемые в комплексе.
N>ARM/32 имел хитрую схему векторных регистров, когда, например, D0 состоит из S0 и S1. ARM/64 похерил это. В MIPS-R раннем 64-битном (поздние не видел) 64-битный регистр это пара 32-битных (типа R2+R3),
ХЗ, в MIPS64 всё те же 32 регистра, просто уже 64 бит.
N>распределители в компиляторах сходят с ума в попытке укладки. Кто прав?
А что тут не так, в сравнении с другими архитектурами? ))
В целом, задумка MIPS была понятной — инструкции фиксированной длины в слово, что позволило упростить дешифратор, упорядочить внутреннюю синхронизацию, а потом в камне разогнать частоту проца вдвое выше пней.
N>ARM по умолчанию когда кладёт более короткое значение в регистр — расширяет его нулями.
В MIPS есть команда загрузки беззнакового байта — lbu.
N>RISC-V аналогично расширяет знаково, размножая старший бит, причём настаивает в ABI на таком расширении при передаче через границу функции даже для коротких беззнаковых.
N>Оба почти что с пеной у рта доказывают свою правоту (RISC-V — в родной доке, ARM — в высказываниях сотрудников).
N>Кто прав?
Зависит от возможности независимого оперирования частями регистра.
В эпоху битовыжимания это было важно.
Сейчас не особо актуально, т.к. исходник оперирует обычно тупо интами или size_t, хотя почти никогда этого не требуется, просто никто уже не жмётся на ширине переменных, берут с запасом.
Давно ты в исходниках видел short и byte, если речь не идёт о строке или бестиповых байт памяти? ))
То бишь, сейчас можно уже автоматом расширять, не боясь, что это создаст сложности там, где расширять не требуется, потому что таких мест в реальной программе исчезающе мало.
N>MIPS-R содержит пачку команд с trap-ом на знаковом переполнении. Реально даже родные компиляторы их не использовали, а уж тотально всё победившие gcc + clang — тем более. Поддерживать надо, использование — фиг. Лучше бы как в ARM сделали adds/subs/etc. в отдельный регистр.
Какой отдельный?
N>Они правы или опять ХЗ что?
MIPS позволяет указывать dst-регистр явно.
И по-другому в этом огромном (на момент разработки архитектуры) файле регистров было бы неразумно.
Зато исключаются бесконечные внутрирегистровые пересылки и прочие пары push/pop.
Я же говорил выше — система команд зависит от архитектуры и наоборот тоже верно.
Например, трехрегистровая кодировка позволила ввести команду условного move, когда перемещение м/у двумя регистрами выполняется, в зависимости от значения в третьем.
Тут простор для оптимизаций большой, разве что MIPS давно не основной мейнстрим, т.е. я бы не ожидал от gcc многого.
N>И почему нет аналогичных для беззнакового переполнения?
А в чём заключается вопрос?
По ARM-у я не очень, скорее никак — просто на уровне представлений об архитектуре проца, но в возможности ни разу глубоко не вникал, бо нелюбопытно — когда вникал всего один раз давно, то увидел, что эта архитектура не проектировалась для упора на вычисления, в отличие от того же MIPS, который изначально был неплох даже в качестве сигнального проца.
Поэтому, для меня ARM несколько скучен...
Хотя, я понимаю причины, почему он когда-то взлетел — из-за низкого энергопотребления.
Но сегодня ARM64 уже не торт, уже всё всерьёз, на уровне MIPS... но мейстрим уже был захвачен армами.
Хотя, китайцам пох, они развивают архитектуру MIPS аж бегом, просто не в мобильном сегменте.
N>Часть архитектур знает пустой регистр (крайне ценно для RISC), часть — нет (ARM/32 не имел). Нужен или нет? Методы построения всей системы после этого меняются чуть более чем полностью.
Дык, кодировка же! ))
Если нулевой регистр — то имеем абсолютную адресацию...
А команда та же, что и для относительной адресации по регистру+смещение.
N>Ладно, предположим, ты только про "кодировку", хотя это ничтожная часть всей задачи... В SPARC вызов функции по смещению от PC получает 30-битное смещение (да-да, 1/4 всего пространства кодов), после сдвига влево на 2 бита получаем полное 32-битное пространство. Это правильно или нет, по сравнению с более короткими в конкурентах? Обоснование — в студию.
Спарки можно рассматривать как продолжение MIPS-архитектуры в сторону увеличения эффективности (окна регистров).
Там слишком много похожего.
V>>Например, гарвардское семейство PIC имеет 12-битные инструкции, ветвление там происходит через трюк "условно пропустить следующую инструкцию", адрес инструкции — не в байтах, это адрес слова. Зато уложились в 12 бит.
V>>В ARM и AVR условный переход всегда относительный (относительно текущего счётчика команд), т.к. ширина адреса `уже, чем полное адресное пространство.
V>>В то же время, каждая инструкция в ARM имеет 32 бита, поэтому младшие 2 бита адреса в команде не кодируются.
V>>В этом месте очевидно, что безусловные jmp/call должны кодироваться не более 4-мя битами, отдавая остальные биты под адрес границы 32-битного слова.
N>Смотрю в AArch64. "B", "BL" — 6 фиксированных, 26 бит на смещение. Итого 28 бит (со знаком). А вот SPARC, наоборот, сделал ещё шире этот литерал. Не соглашаются они с тобой, оба, но по-разному
Значит, арму не хватило пространства кодов, что не смог выделить больше бит под адрес.
В целом, это более экономная, более жадная архитектура -пытается повысить не эффективность исполнения, а размер образа.
В MIPS/SPARC наоборот, при проектировании архитектур во главу угла ставилась эффективность.
Поэтому, армы предазначались для персоналок и встраиваемых решений, а MIPS/SPARC — для рабочих станций и серверов.
И когда сегодня говорят, что вот сервак на армах делают...
Это
Понятно, что из-за массовости камни эти дешевле при топовых процессах исполнения, но не лучше ли массово выпускать на том же процессе более пригодные для сервера архитектуры? ))
V>>>>По тем временам — типичная задача для подобных комплексов, бо на управляющей машине монитор периферии, графики в реальном времени и это всё.
N>>>А какая доля таких комплексов от всех PC?
V>>Ну, тогда еще во всех офисах PC не стояли, поэтому доля инструментального применения персоналок была весьма высокой.
N>Ты хоть бы приблизительно цифру прикинул...
Где-то в разы меньше, чем в офисах, но разницы даже на порядок не видел.
Сегодня же любые терминалы, любые пульты управления станками, любое локальное серверное хранилище — это тоже персоналки по архитектуре, просто исполнение внешне другое.
Поэтому, можно поспорить и о сегодняшних раскладах. ))
Возможно, что "там" инструментальное исполнение было доступным "сразу", но у нас были только массово хлынувшие б/у персоналки, поэтому вся инструменталка одно время делалась на них.
V>>>>Для разных регистров получилась разная кодировка, плюс префиксы для новых команд, чтобы "остальные" регистры стали "как все" и т.д.
N>>>Ты о каком этапе-то? Для x86-16, x86-32 она тут одинаковая, в 32 даже ровнее.
V>>Разве ровнее? ))
N>Я про то, что база и индекс адресации — любой из 8.
Но кодировки под разные регистры иногда разные, в отличие от ортогональных архитектур.
V>>https://3dnews.ru/1087156/intel-predlogila-x64s-iskonno-64bitniy-variant-arhitekturi-x86-dlya-budushchih-cpu
N>Да, тут было обсуждение. Я одного не понял — они хотят чтобы страничная адресация вообще не выключалась, а кто её будет настраивать со старта? ME в южном мосту?
Со старта можно в плоскую память, ИМХО.
V>>https://3dnews.ru/1090501/intel-predstavila-apx-rasshireniya-arhitekturi-x8664-kotorie-uskoryat-lyuboe-po
N>Ну как наворот поверх существующей схемы — ok.
Не-не-не ))
То бишь, можно будет постепенно отказаться от "франкенштейна" в традиционной кодировке.
А потом однажды перекодировать команды, убрав уже ненужные префиксы, что сократит размер образа. ))
N>"Догнать и перегнать ARM". А когда от TSO начнут отходить?
Ну, ARM поступили правильно в ARM64 — в новую жизнь без старых долгов.
А вот AMD64 поднасрала, конечно...
N>Но если бы на этом этапе проектировали с нуля, то мне кажется, что подход с полностью переменной схемой (в стиле CBOR и отдельными элементами в le128) декодировался бы не дороже.
Речь идёт о том, чтобы сделать сам дешифратор проще.
Причём, в ортогональной схеме он получается проще в разы.
А это важно как для будущего увеличения кол-ва ядер, так и для будущего увеличения степени параллельности гипертрединга (до 16 аппаратных потоков на ядро было бы неплохо — и это самый начальный минимум).
(Самый первый гипертрединг в спарках был, вроде, сразу 4 потока — ИМХО, потому что дешифратор в разы дешевле, чем в x86/x64 архитектуре)
V>>Если сегодня самые-самые простые RISC-микрики имеют конвейер длиной 4, как сам думаешь? ))
N>А зачем вспоминать "самые-самые простые", когда по контексту они точно ни при чём?
Просто самые простейшие уже отвечают на вопрос (исполняют одну команду за несколько шагов).
Более навороченные и подавно.
N>Коды условий должны быть — как в SPARC, ARM, POWER — или нет, как в MIPS, Alpha, RISC-V? Собери обоснования и попробуй доказать, кто из них прав, а кто презренный самец большой мерзкой кошки.
Это смотря какой файл регистров.
Например, в PIC-ах есть операция наложения маски на любой регистр из файла 128 штук и последующего ветвления по нулю или не нулю (через пропуск команды).
Часть регистров — системные, например, флаги нуля предыдущей операции, флаг переноса и т.д.
Т.е. одной командой покрыли как ветвление по маске обычного регистра, как и системных (как флагов, так и IO на ногах).
Поэтому, сравнимые возможности есть, но их умудрились упаковать в продуманный набор инструкций.
Т.е., набор инструкций влияет на архитектуру чипа и наборот тоже верно — это взаимосвязанные вещи, разрабатываемые в комплексе.
N>ARM/32 имел хитрую схему векторных регистров, когда, например, D0 состоит из S0 и S1. ARM/64 похерил это. В MIPS-R раннем 64-битном (поздние не видел) 64-битный регистр это пара 32-битных (типа R2+R3),
ХЗ, в MIPS64 всё те же 32 регистра, просто уже 64 бит.
N>распределители в компиляторах сходят с ума в попытке укладки. Кто прав?
А что тут не так, в сравнении с другими архитектурами? ))
В целом, задумка MIPS была понятной — инструкции фиксированной длины в слово, что позволило упростить дешифратор, упорядочить внутреннюю синхронизацию, а потом в камне разогнать частоту проца вдвое выше пней.
N>ARM по умолчанию когда кладёт более короткое значение в регистр — расширяет его нулями.
В MIPS есть команда загрузки беззнакового байта — lbu.
N>RISC-V аналогично расширяет знаково, размножая старший бит, причём настаивает в ABI на таком расширении при передаче через границу функции даже для коротких беззнаковых.
N>Оба почти что с пеной у рта доказывают свою правоту (RISC-V — в родной доке, ARM — в высказываниях сотрудников).
N>Кто прав?
Зависит от возможности независимого оперирования частями регистра.
В эпоху битовыжимания это было важно.
Сейчас не особо актуально, т.к. исходник оперирует обычно тупо интами или size_t, хотя почти никогда этого не требуется, просто никто уже не жмётся на ширине переменных, берут с запасом.
Давно ты в исходниках видел short и byte, если речь не идёт о строке или бестиповых байт памяти? ))
То бишь, сейчас можно уже автоматом расширять, не боясь, что это создаст сложности там, где расширять не требуется, потому что таких мест в реальной программе исчезающе мало.
N>MIPS-R содержит пачку команд с trap-ом на знаковом переполнении. Реально даже родные компиляторы их не использовали, а уж тотально всё победившие gcc + clang — тем более. Поддерживать надо, использование — фиг. Лучше бы как в ARM сделали adds/subs/etc. в отдельный регистр.
Какой отдельный?
N>Они правы или опять ХЗ что?
MIPS позволяет указывать dst-регистр явно.
И по-другому в этом огромном (на момент разработки архитектуры) файле регистров было бы неразумно.
Зато исключаются бесконечные внутрирегистровые пересылки и прочие пары push/pop.
Я же говорил выше — система команд зависит от архитектуры и наоборот тоже верно.
Например, трехрегистровая кодировка позволила ввести команду условного move, когда перемещение м/у двумя регистрами выполняется, в зависимости от значения в третьем.
Тут простор для оптимизаций большой, разве что MIPS давно не основной мейнстрим, т.е. я бы не ожидал от gcc многого.
N>И почему нет аналогичных для беззнакового переполнения?
А в чём заключается вопрос?
По ARM-у я не очень, скорее никак — просто на уровне представлений об архитектуре проца, но в возможности ни разу глубоко не вникал, бо нелюбопытно — когда вникал всего один раз давно, то увидел, что эта архитектура не проектировалась для упора на вычисления, в отличие от того же MIPS, который изначально был неплох даже в качестве сигнального проца.
Поэтому, для меня ARM несколько скучен...
Хотя, я понимаю причины, почему он когда-то взлетел — из-за низкого энергопотребления.
Но сегодня ARM64 уже не торт, уже всё всерьёз, на уровне MIPS... но мейстрим уже был захвачен армами.
Хотя, китайцам пох, они развивают архитектуру MIPS аж бегом, просто не в мобильном сегменте.
N>Часть архитектур знает пустой регистр (крайне ценно для RISC), часть — нет (ARM/32 не имел). Нужен или нет? Методы построения всей системы после этого меняются чуть более чем полностью.
Дык, кодировка же! ))
Если нулевой регистр — то имеем абсолютную адресацию...
А команда та же, что и для относительной адресации по регистру+смещение.
N>Ладно, предположим, ты только про "кодировку", хотя это ничтожная часть всей задачи... В SPARC вызов функции по смещению от PC получает 30-битное смещение (да-да, 1/4 всего пространства кодов), после сдвига влево на 2 бита получаем полное 32-битное пространство. Это правильно или нет, по сравнению с более короткими в конкурентах? Обоснование — в студию.
Спарки можно рассматривать как продолжение MIPS-архитектуры в сторону увеличения эффективности (окна регистров).
Там слишком много похожего.
V>>Например, гарвардское семейство PIC имеет 12-битные инструкции, ветвление там происходит через трюк "условно пропустить следующую инструкцию", адрес инструкции — не в байтах, это адрес слова. Зато уложились в 12 бит.
V>>В ARM и AVR условный переход всегда относительный (относительно текущего счётчика команд), т.к. ширина адреса `уже, чем полное адресное пространство.
V>>В то же время, каждая инструкция в ARM имеет 32 бита, поэтому младшие 2 бита адреса в команде не кодируются.
V>>В этом месте очевидно, что безусловные jmp/call должны кодироваться не более 4-мя битами, отдавая остальные биты под адрес границы 32-битного слова.
N>Смотрю в AArch64. "B", "BL" — 6 фиксированных, 26 бит на смещение. Итого 28 бит (со знаком). А вот SPARC, наоборот, сделал ещё шире этот литерал. Не соглашаются они с тобой, оба, но по-разному
Значит, арму не хватило пространства кодов, что не смог выделить больше бит под адрес.
В целом, это более экономная, более жадная архитектура -пытается повысить не эффективность исполнения, а размер образа.
В MIPS/SPARC наоборот, при проектировании архитектур во главу угла ставилась эффективность.
Поэтому, армы предазначались для персоналок и встраиваемых решений, а MIPS/SPARC — для рабочих станций и серверов.
И когда сегодня говорят, что вот сервак на армах делают...
Это
Понятно, что из-за массовости камни эти дешевле при топовых процессах исполнения, но не лучше ли массово выпускать на том же процессе более пригодные для сервера архитектуры? ))
V>>>>По тем временам — типичная задача для подобных комплексов, бо на управляющей машине монитор периферии, графики в реальном времени и это всё.
N>>>А какая доля таких комплексов от всех PC?
V>>Ну, тогда еще во всех офисах PC не стояли, поэтому доля инструментального применения персоналок была весьма высокой.
N>Ты хоть бы приблизительно цифру прикинул...
Где-то в разы меньше, чем в офисах, но разницы даже на порядок не видел.
Сегодня же любые терминалы, любые пульты управления станками, любое локальное серверное хранилище — это тоже персоналки по архитектуре, просто исполнение внешне другое.
Поэтому, можно поспорить и о сегодняшних раскладах. ))
Возможно, что "там" инструментальное исполнение было доступным "сразу", но у нас были только массово хлынувшие б/у персоналки, поэтому вся инструменталка одно время делалась на них.
V>>>>Для разных регистров получилась разная кодировка, плюс префиксы для новых команд, чтобы "остальные" регистры стали "как все" и т.д.
N>>>Ты о каком этапе-то? Для x86-16, x86-32 она тут одинаковая, в 32 даже ровнее.
V>>Разве ровнее? ))
N>Я про то, что база и индекс адресации — любой из 8.
Но кодировки под разные регистры иногда разные, в отличие от ортогональных архитектур.
V>>https://3dnews.ru/1087156/intel-predlogila-x64s-iskonno-64bitniy-variant-arhitekturi-x86-dlya-budushchih-cpu
N>Да, тут было обсуждение. Я одного не понял — они хотят чтобы страничная адресация вообще не выключалась, а кто её будет настраивать со старта? ME в южном мосту?
Со старта можно в плоскую память, ИМХО.
V>>https://3dnews.ru/1090501/intel-predstavila-apx-rasshireniya-arhitekturi-x8664-kotorie-uskoryat-lyuboe-po
N>Ну как наворот поверх существующей схемы — ok.
Не-не-не ))
Это позволит кодировать многие операции более чем одним способом — как в новом формате, так и в традиционном.добавление трёхоперандного формата большинству существующих целочисленных инструкций;
добавление дополнительных условных инструкций для облегчения предсказания переходов;
а также новую 64-битную инструкцию безусловного перехода.
То бишь, можно будет постепенно отказаться от "франкенштейна" в традиционной кодировке.
А потом однажды перекодировать команды, убрав уже ненужные префиксы, что сократит размер образа. ))
N>"Догнать и перегнать ARM". А когда от TSO начнут отходить?
Ну, ARM поступили правильно в ARM64 — в новую жизнь без старых долгов.
А вот AMD64 поднасрала, конечно...
N>Но если бы на этом этапе проектировали с нуля, то мне кажется, что подход с полностью переменной схемой (в стиле CBOR и отдельными элементами в le128) декодировался бы не дороже.
Речь идёт о том, чтобы сделать сам дешифратор проще.
Причём, в ортогональной схеме он получается проще в разы.
А это важно как для будущего увеличения кол-ва ядер, так и для будущего увеличения степени параллельности гипертрединга (до 16 аппаратных потоков на ядро было бы неплохо — и это самый начальный минимум).
(Самый первый гипертрединг в спарках был, вроде, сразу 4 потока — ИМХО, потому что дешифратор в разы дешевле, чем в x86/x64 архитектуре)