Про Motorola, IBM, DEC, ...

[Lethargeek]

Возьмем типичную команду

А ну стоп! Хватит уходит от ответа! Вопрос был не про "типичные команды", а про КОНКРЕТНЫЙ код - где гарантия, что в ds будет нужное значение перед вызовом?

типичную команду загрузки из памяти MOVE data(a3),d0. В этой команде a3 - база, а data - это 16-БИТНОЕ смещение,

Таким способом адресуются типичные структуры с известными заранее смещениями, и на них вполне хватает даже менее 16 бит.

если вам нужны данные, которые не влазят в 64 КБ (например, data2), то базу надо менять. Это абсолютно аналогично ситуации с х86.

Если мне нужны такие большие данные, то и базы для интересующего куска, и смещения для них будут вычисляться в регистрах, и вот здесь у 16-битных x86 абсолютно НЕаналогично начинаются проблемы и тормоза.

Ничего не понял. Повторю, что естественно все данные небольшого размера держать в DS. А во времена дефицита памяти, когда даже 512 КБ было очень много, это было более чем нормально. Что тут не так? Если вы про CS, то меняя его легко получаем 1 МБ для подпрограмм, которые используют один и тот же DS. И тут что для вас не так? Два типа подпрограмм тяжело использовать?

Повторю: где гарантия, что перед вызовом процедуры распечатки значения ds не испорчен типичной процедурой доступа к большому массиву (из которого, скорей всего, и берутся эти числовые данные для печати)?

Извините, но никак не пойму. Может скажете более конкретно, что именно вам не понраравилось в приведенных кодах?

cферовакуумное самозарождение входных параметров сразу же в удобных регистрах

У меня получилось для АРМа 16 тактов, а для 8086 более 300.

я оценивал для арма с динамической памятью

Деление на 8086 выполняется за разное число тактов для разных аргументов, поэтому подсчитать точное число тактов очень непросто и неоднозначно.

144...162 относительно небольшой разброс, если даже только минимум брать, то картина практически не изменится

Это, как говорят, не спортивно.

неспортивно убирать из процедуры часть процедуры

универсальное 32-битное деление на 80286 - это примерно 51 такт, специализированное деление на 10 у Арма - это 40 тактов.

40 БАЙТ, но только 10 ТАКТОВ! и ведь только что сам же говорил про 16 тактов на ИТЕРАЦИЮ...

Получаем 51/40 = 1.275, т.е. выигрыш Арма на примерно четверть. Если в универсальном делении использовать делитель 10, то для 80286 получим уже примерно 64 такта. В этом случае получаем 64/40 = 1.6 и опять и близко не 3.6

я для полной итерации подсчитал - 72 такта 286 против ~20 армовских

универсальное 32-битное деление на 80386 - это 38 тактов - обгонит и на той же частоте.

да что ж такое то! снова растечение мысью
для вот этого конкретного примера - НЕТ, НЕ обгонит!

Универсальное 32-битное деление на 80386 - это одна команда от 2 до 4 байт, на Арме, если делать побыстрее без циклов, то более 200 байт,

да и пофиг, сколько там займёт ПРОЦЕДУРА, многократно вызываемая в коде ОДНОЙ командой
причём сам вызов процедур таких на арме довольно "дешёв", по сравнению даже с 386

И это про Арм-варианты, когда делимое 32 бита. На 80386 оно 64 бита. На 80286 и 8086 делимое 32 бита.

На x86 длинное делимое в 99.9% случаев нахрен никому не сдалось, ибо требует дополнительных проверок на возможную ошибку переполнения или перехвата прерывания по ошибке. Для 286 еще проверки имеют смысл (сам писал быстрое 32-битное деление для Форта), но для 386 в edx тупо пишут ноль или расширение знака.

Писал деление для Арма, чтобы получилось максимально быстро. Получилось примерно за 100 тактов, почти в три раза медленнее 80386 и при том меньшем делимом. Eсли ограничить делитель 16 битами, то 80286 обгонит Арм почти в 5 раз. Возможно есть и более быстрые деления для ARM2, но мне такие не встречались.

мне встречались цифры 32...116 с утверждением, что средневзвешенно меньше среднего
и процедуры с ограничением делителя тоже побыстрее будут наверняка

По умножению Арм2 скорее нетороплив, от 2 до 17 тактов, и это только полуумножение без старшего слова.

См. выше - длинный результат разве что немногим чаще длинного делимого нужен (при расчёте 32-битных адресов никогда не нужен). Как-то с толком применять его потом затруднительно, разве что для */ операций (но опять же, требуются проверки, да и для арма комбинацию */ можно реализовать быстрее суммы двух процедур)

80386 с полным умножением от 9 до 38. Таким образом, полное умножение у Арм только незначительно быстрее 80386 и гораздо больше по коду.

НЕТ, "таким образом" наиболее востребованное умножение у арма в лучшем случае быстрее в 4.5 раз, в худшем - быстрее в 2.2+ раз, а в среднем - быстрее в 2.47+ раз. Ничего себе "незначительно"! Причём худшего случая на арме легко избежать ценой одной проверки и всего двух лишних тактов, тогда в среднем выйдет почти в 3 раза.

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

Ахахах! Очень редкий? Да это именно что типичный в армах способ доступа к любой структуре небольшого размера. Например, прочитали разом 6 координат треугольника, рассчитали поворот, записали разом обратно. Сортировка - прочитали несколько значений, отсортировали в регистрах, записали разом обратно, переходим к следующему куску. Все куски прошли - дальше будет проще с ними работать, начиная с крайних значений. Распаковка, включая кодеки - из потока тянем биты в несколько регистров, насколько хватит. И так далее.

Говорим о плотности кодов, дал вам ссылку по исследованиям по плотности кодов, а вы - это к делу не относится?!

нет, мы говорили там не о плотности, а о том, ЗАЧЕМ НА САМОМ ДЕЛЕ придуман палец
причём, кстати, даже с разрешённым пальцем код для армов генерится всё-таки смешанный

Возможно, это дело вкуса. Мне она не мешала. Там даже интересно, все регистры с именами АХ - аккумулятор, ВХ - базовый, СХ - счетчик, DX - данные, SI - источник, DI - приемник. В Интеле работали с воображением, не пpосто циферки для регистров делали как 68к, PDP11 или ARM.

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

У Коммодора менее мегагерца, поэтому если считать 6502 в 2.5 раза шустрее, то отставание от спека на 40%, а в Атарях процентов 30-40% частоты штатно съедало видео - поэтому и там имеем те же 2.5 раза.

нет, не сходится - тогда атари был бы не быстрей комода (для которого основное торможение от видео в этот мегагерц не входит) в портах со спектрума, а он всё-таки заметно быстрее (а комод - медленнее спека явно не всего на 40%)

6502 нужна была память побыстрее и с этим были проблемы, но дело портилось ещё тем, что почти все или даже все компы на 6502 использовали память одновременно для видео и процессора, что очень снижало скорость, и требовало в 2 РАЗА более быстрой памяти, чем процессор. А у Спека была быстрая память, без тормозов. Но 6502 работал с памятью как с регистрами, не тормозя, такт на обращение.

Нееет, как раз всё ровно наоборот - 6502 работает ПОСТОЯННО ТОРМОЗЯ до уровня памяти

В когда-то популярном в Штатах TI-99, процессор вообще не имел регистров - если память не тормозит, то это очень неплохое решение.

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

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

это интелострадальцы должны страдать, потому что просто деваться некуда, а рискобоярам необязательно - в том и состоит преимущество

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

оптимизация формата исходных данных - часть оптимизации в целом

Скорее в полуарифметике, так как там даже флаги не ставятся и добавлять/отнимать можно только слова.

не помню про флаги, но если в старших разрядах адресного нули, то какая разница

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

ага! тут мы сразу вспоминаем, что данные из памяти грузить надо! а как код для x86 - так сразу "типично передавать в регистрах"

Отличный (очень хороший) для специальных случаев.

для каких-то очень уж "специальных" (как "особенный ребёнок" политкорректно)))

Нет там защиты памяти.

а многозадачность есть искаропки - видать, был приспособлен лучше "очень хороших"

У других было ещё хуже, там сразу два, а иногда и три костыля шли в комлекте.

пхе, явно не у арма с 68000