Который 32-bit/64-bit архитектура ЦП имеет самую легкую систему команд?

Question

Который 32-bit/64-bit архитектура ЦП имеет самую легкую систему команд?

Если существует тип значения, который имеет определенные ограничения на его значение, сделайте класс, где те ограничения осуществляются кодом. Некоторые примеры:

public class SanitizedHtmlString
{
private string val;

public SanitizedHtmlString(string val)
{
  this.val = Sanitize(val);
}

public string Val
{
  get { return val; }
}

//TODO write Sanitize method...
}


public class CarSpeed
{
private int speedInMilesPerHour; 

public CarSpeed(int speedInMilesPerHour)
{
  if (speedInMilesPerHour > 1000 || speedInMilesPerHour < 0)
  {
    throw new ArgumentException("Invalid speed.");
  }
  this.speedInMilesPerHour = speedInMilesPerHour; 
}

public int SpeedInMilesPerHour
{
  get { return speedInMilesPerHour; }
}
}

6

assembly powerpc

задан sigjuice 5 September 2009 в 06:35

8 ответов

Без определения «простой» я почти уверен, что большинство людей согласятся, что набор инструкций x86 является самый ужасный для массового популярного процессора.

Если бы кто-то составил список хороших или передовых практик, которым следует следовать при разработке набора команд, x86 был бы хорошим примером всех противоположностей.

Не ортогонален, не все регистры одинаковы по функциональности .
Небольшое ограниченное количество специализированных регистров - приводит к слишком большому количеству операций со стеком.
Противные операторы префикса.
...

4

ответ дан 8 December 2019 в 03:10

Думаю, вам следует определить, что для вас означает «легкий».

Я бы предпочел судить о машинных языках с точки зрения ортогональности (что означает: любая часть инструкции может быть заменена альтернативами и все же дать действительную инструкцию)

команда (добавить, sub, mul, div)
параметры (регистр, память, литерал)
размер параметра (байт, слово, длинное число, число с плавающей запятой)
согласованный порядок параметров (источник x источник -> dest или dest <- источник x источник)

и возможности / сложности инструкций

количество доступных регистров
индексированная адресация
неявные / явные параметры

и другие.

Вероятно, вам следует привести примеры того, какие части x86 вы считаете «непростыми» по сравнению с другими архитектурами и почему.

3

ответ дан 8 December 2019 в 03:10

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

Правка: По какой-то причине я предположил, что вы имели в виду формат машинного кода. Сборка X86 проста - собрать ее в машинный код ... не так уж и много.

3

ответ дан 8 December 2019 в 03:10

Адвокат дьявола защищает архитектуру x86

Я не собираюсь защищать сам ассемблер MS x86, но мои комментарии по нему см. Здесь . (Возможно, вы захотите использовать один GNU, возможно, через Cygwin .) И, конечно же, отсутствие регистров, специализированный характер большинства из них и странная, извращенная, неортогональная организация все это действительно представляло собой классический пример , не делайте этого таким образом . Ой, подождите, как насчет чрезвычайно сложных функций просто эпической сложности, которые никто никогда не хотел и никогда не использовал? Вы знаете, модуль сегментации?

Что касается сложности обучения, я думаю, что писать ассемблер x86 весело , хотя я не могу понять, почему это так. Никакая архитектура с набором инструкций на самом деле не такая сложная, поэтому я думаю, вы сможете понять x86 с достаточно небольшим уровнем усилий, хотя я согласен, что в ней определенно больше элементов, чем в RISC ISA. Но это забава , несколько необычно разделенных регистров, несколько других специальных регистров и ряд форматов инструкций, но в основном с использованием того же формата адреса 1.5.

Вернемся к защите:

Вкл. Отсутствие регистров : В конце концов, это не имело значения. Даже архитектуры RISC в конечном итоге переименовали регистры , несмотря на загруженность ими архитектурных регистров, им все еще требовалось больше для повышения производительности. Так что x86, возможно, лучше, потому что каждый получает миллионы автоматически переименованных, но x86 нужно только сохранить небольшое количество регистров архива.

On Complex ISA : Intel всегда справлялась с этим, сначала с помощью технологии грубого перебора (286 был довольно быстрым в свое время), а сегодня путем перевода: коды операций x86 в ОЗУ транскодируются в микрооперации , поскольку они считываются в кеш, таким образом изолируя ядро процессора от x86! Сегодня x86 - это своего рода схема «сжатия инструкций», просто кодировка, которая раскрывается, когда программный код читается ЦП. Иногда они разбивают инструкции, иногда объединяют последовательные, а иногда просто переводят их.

2

ответ дан 8 December 2019 в 03:10

Я изучил сборку ARM и считаю ее довольно простой и мощной. Я не думаю, что перестановка операндов и тому подобное сбивает с толку. По крайней мере, потому, что я сначала изучил ARM asm, а затем прочитал кое-что о x86 asm.

Я обнаружил, что большинство функций, отсутствующих на x86, являются сильными сторонами ARM, например, несколько регистров для хранения / чтения и условного выполнения. Pl.us, мне очень полезно иметь такое количество регистров.

Я думаю, что это обычная «религиозная война»: RISC против CISC, ARM против x86. ИМХО слишком субъективен, чтобы быть универсальным принципом. Например, Мартин фон Лёвис считает ARM неэлегантным, в то время как я считаю его намного более элегантным, чем x86.

Я также попробовал ассемблер микроконтроллера (Texas Instruments, не могу вспомнить точное название модели) и нашел его вполне неэлегантный, в то время как многие другие люди могут найти его «идеальным».

3

ответ дан 8 December 2019 в 03:10

Перейти с ARM. После 20 с лишним лет работы инженером-программистом я каждый день пишу ассемблер для различных платформ, но мне никогда не нужно писать ассемблер x86. Отчасти потому, что это ужасно, отчасти потому, что я бы никогда не встраивал x86, поэтому я запускаю только настольные компьютеры / ноутбуки с x86 и C или все, что вы хотите запустить на linux / windows достаточно низкого уровня.

2

ответ дан 8 December 2019 в 03:10

Я думаю, что вы переживаете феномен, заключающийся в том, что второй язык ассемблера (снова) трудно выучить (я предполагаю, что изучение PPC также было трудным, когда вы начинали, тогда). Чем больше новых архитектур вы знакомы, тем легче становится - в какой-то момент вам понравится найти какую-нибудь архитектурную (неправильную) особенность, которую вы никогда раньше не видели.

Проблема второй архитектуры в том, что вам еще не ясно, что является общепринятой практикой и что характерно для первой архитектуры. Таким образом, вы ожидаете, что определенные вещи будут выполняться на x86 так же, как они были сделаны на PPC, хотя на самом деле x86 имеет свой собственный (возможно, даже более элегантный) способ работы.

Чем больше новых архитектур вы знакомы, тем легче становится - в какой-то момент вам понравится найти какую-нибудь архитектурную (неправильную) особенность, которую вы никогда раньше не видели.

Проблема второй архитектуры в том, что вам еще не ясно, что является общепринятой практикой, а что характерно для первой архитектуры. Таким образом, вы ожидаете, что определенные вещи будут выполняться на x86 так же, как они были сделаны на PPC, хотя на самом деле x86 имеет свой собственный (возможно, даже более элегантный) способ работы.

Чем больше новых архитектур вы знакомы, тем легче становится - в какой-то момент вам понравится найти какую-нибудь архитектурную (неправильную) особенность, которую вы никогда раньше не видели.

Проблема второй архитектуры в том, что вам еще не ясно, что является общепринятой практикой и что характерно для первой архитектуры. Таким образом, вы ожидаете, что определенные вещи будут выполняться на x86 так же, как они делались на PPC, тогда как на самом деле x86 имеет свой собственный (возможно, даже более элегантный) способ работы.

3

ответ дан 8 December 2019 в 03:10

Другие вопросы по тегам:

assembly powerpc

Похожие вопросы:

score 10 · Accepted Answer

Ну, большинство RISC очень похожи, поэтому, если вы хорошо знаете PPC, то переход на ARM, MIPS или SPARC будет несложным. На самом деле я сначала изучил SPARC, а затем за пару часов смог освоить MIPS и PPC.

То, что сбивает с толку x86, на самом деле не его язык ассемблера, а конструкция процессора. Люди склонны зацикливаться на:

Сегментированной адресации памяти - все эти регистры ds, cs, es: что они означают, как они сочетаются с индексным регистром, чтобы получить полностью разрешенный адрес памяти? На самом деле существует три разных способа, так что вы изучаете множество различных режимов.
Неортогональный набор инструкций - некоторые инструкции работают только с определенными регистрами, другие инструкции имеют перекрывающиеся значения, некоторые вещи выглядят так, как будто они должны быть быстрыми, но очень медленными и т. Д.
Архитектура регистровой памяти - x86 разработан так, чтобы иметь несколько (именованных) регистров, так что каждый код операции обычно имеет один аргумент, который является регистром, и другой аргумент, который является адресом памяти. Это отличается от архитектуры загрузки-хранилища PPC, в которой операции с памятью явны. Поскольку указатель стека имеет тенденцию часто подпрыгивать, это может затруднить определение того, какая переменная действительно используется!
Спастический указатель стека - там, где в большинстве соглашений о вызовах PPC вы перемещаете указатель стека только один раз при входе в функцию, а затем один раз при возврате, обычно код x86 будет ] push ing и pop ping повсюду. Вы в конечном итоге подсчитываете количество нажатий и всплывающих окон, чтобы выяснить, куда попал указатель стека, что всегда вызывает у меня головную боль.

Итак, чтобы освоиться с x86, разделяй и властвуй: выберите одну из этих точек, научитесь как это работает, а затем переходите к следующему. Это может помочь начать с изучения соглашений о вызовах, потому что это сделает все остальные инструкции, которые ссылаются на указатель стека, более понятными.

обычно код x86 будет push ing и pop ping повсюду. Вы в конечном итоге подсчитываете количество нажатий и всплывающих окон, чтобы выяснить, куда попал указатель стека, что всегда вызывает у меня головную боль.

Итак, чтобы освоиться с x86, разделяй и властвуй: выберите одну из этих точек, научитесь как это работает, а затем переходите к следующему. Это может помочь начать с изучения соглашений о вызовах, потому что это сделает все остальные инструкции, которые ссылаются на указатель стека, более понятными.

обычно код x86 будет push ing и pop ping повсюду. Вы в конечном итоге подсчитываете количество нажатий и всплывающих окон, чтобы выяснить, куда попал указатель стека, что всегда вызывает у меня головную боль.

Итак, чтобы освоиться с x86, разделяй и властвуй: выберите одну из этих точек, научитесь как это работает, а затем переходите к следующему. Это может помочь начать с изучения соглашений о вызовах, потому что это сделает все остальные инструкции, которые ссылаются на указатель стека, более понятными.