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

[Lethargeek]

Чувствуется, что не делали вы кодов для 68000. Там если смещение более 64 кб, нужно менять базовый адресный регистр.

уже не помню, но при чём тут вообще смещение? когда нужен просто инкремент указателя

И добавим к этому немного здравого смысла: все маленькие данные естественно хранить в одном сегменте.

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

И в чем тут у вас проблема?

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

Благодарю за интесный алгоритм. Явно АРМ уделывает 8086 по скорости раз в 30,

в 18 раз на одинаковой частоте (если брать всю итерацию, а не только деление)

но по размеру кода проигрывает почти в два раза.

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

Если сравним с более близким по времени 80286, то по скорости для 32-битных данных 80286 проиграет раза в полтора при том же выигрыше по размеру кода, а для 16-битных он уже существенно обгонит АРМ.

ага, щяз на 32-битных проиграет в 3.6+ раза (и на 16-битных не должен обогнать)

Ровестник АРМ, 80386, обгонит его и по слегка скорости,

вот конкретно в этой задаче не обгонит даже на удвоенной частоте (а первые 386 шли от 12мгц)

и сильно (раз в 30) по размеру кода.

шта? опять смешались мухи с котлетами... в данном случае размер кода будет близок к 8086 варианту
для универсального же деления, в армокоде будет просто "BL udiv", который всяко нужен неоднократно

Для универсального деления АРМ сильно отстает от 80286 и 80386.

да не так уж сильно, раза в полтора в среднем (и это для полностью программной реализации!)
зато очень быстрое умножение, которое нужно намного чаще, в том числе неявно (адрес в массиве)

LDR - это макрос и он может быть и 8 и даже более байт.

а может и не быть, конкретно здесь хватит результата PC+N

Хотя если заменить ADDPL на ADDPLS, то можно убрать CMP,

здесь нельзя, ADDPL не каждый раз выполняется

несмотря на все очень непростые алгоритмические трюки в более два раза больше, чем 8088, и почти в два раза больше, чем 68000.

а с вызовом универсальной (или частных случаев) процедуры - меньше!

Смысл от этого не меняется, "могут" означает способны сделать, делают иногда.

да мне пофиг, какой смысл у слова "могут" - ЕГО ТАМ НЕТ!

На всех примерах, где использовали очень сложные трюки (ваш алгоритм деления на 10 или код английского эксперта для рисования линии), преимущества для АРМ не получилось.

трюки есть и менее сложные (например, прочесть пачку аргументов одной командой там, где 386 вынужден уныло копаться в стеке) и результаты следует оценивать комплексно

Вам предложили научные исследования,

совершенно к делу не относящиеся

Можно поконкретнее? Может надо объяснить, если чего не поняли? У вас 68к с АРМ реально путалось...

поконкретнее - я там забытое напомнил сразу СЛЕДУЮЩЕЙ СТРОКОЙ

В смысле PC? Вы бы ещё вспомнили трансляционные таблицы для линейного адреса в современных системах, там не два, там много! Но это всё за кулисами, а юзер просто работает с РС. Так и с древним 8086, там там CS подразумевается в абсолютном большинстве случаев. Явно его указывать нужно только для длинных переходов. Такая же ситуация и с данными, а на 68к нужно, повторю, ЯВНО указывать базовый регистр. Неужели не понимаете, что явное указание регистра, это и головная боль программеру и лишний тормоз в системе.

какой PC? какой базовый регистр? для начала - просто ПОЛНОЦЕННЫЙ АДРЕС ЯЧЕЙКИ ПАМЯТИ

А вы с х86 знакомы?

лучше, чем с 68k или армом (на ассемблере последний раз писал Форт себе со встроенным отладчиком спектрума)

BP - это для работы со стеком, довесок к SP. База нужна, чтобы использовать более коpоткие адреса относительно неё.

база нужна, чтоб адресовать НАЧАЛО СТРУКТУРЫ (в широком смысле)
и уж точно без дурацких лишних ограничений на аж 16-байтовое выравнивание

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

нет, база всегда - НАЧАЛО отсчёта (порции) данных

Тут я описался, имелось в виду не адресные, а базовые. Хотя это лишь оттенки смыслов,

не "оттенки смыслов", а принципиально разные вещи

Чем адрес в сегментном регистре неполноценный? Не хватает 4 бит, так для базы выравнивание - это норм.

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

Специализация давала возможность иметь более плотные коды (код 8086 более плотный, чем у современных х86). Сколько вы кодов х86 написали? Я более 100000 строк и считаю, что проблема специализации надуманная.

см. выше - дохренища я написал и специализация надоела

Конечно, иметь много регистров - это хорошо, но не однозначно хорошо. Если иметь быструю память (а сегодня поставить даже гигабайт статической нетормозящей память вполне бюджетно), то можно и с минимумом регисторов получить отличную скорость. Пример 6502 это подтвреждает, который в почти три раза уделывал z80 на той же частоте.

во-1 не в три раза, а от силы в два, иначе прямые спектрумовские порты так заметно на комоде не тормозили бы (в отличие портов на атари с его как раз ровно вдвое меньшей частотой камня); во-2, пример 6502 подтверждает как раз обратное, потому что он вообще не мог работать на таких частотах, чтобы догнать, будучи привязанным к памяти; в-3, если память не ограничивает скорость проца вообще, то она регистрами и является (потому что даже кэш на одном кристалле даёт задержки)

Не понял, где вы тут увидели проблему?

в возне со стеком (но да, на x86 это не "проблема", там это жизнь)))

Загрузить, например, в AX и сделать XCHG - в 68000 так не получится, там нет XCHG.

точно, XCHG нету есть EXG - обмен между регистрами; и между половинками регистра данных (SWAP называется)

Реально вы хоть какой-то код для 68000 делали?

спрашивает человек, не знающий команд обмена 68000

Как вы там сможете использовать "третьи байты регистров данных"?

еще раз, для закрепления материала: SWAP

Никак или с такими тормозами, что быстрее их брать прямо из памяти.

не быстрее

Про адресные регистры уже писал - они мало приспособленны для данных, хотя как временный кэш для байт для загрузки-выгрузки из/в регистров данных подойдут.

а я писал, что и в арифметике подойдут

Но 8086 парубайтки существенно гибче для таких случаев

для КАКИХ? в вычислениях применять их можно только парой, только для логики
что ни гибче, ни тем более "существенно" гибче

Шутим? Не было там нормального ММЮ,

то есть "отличный ММЮ" раньше было в смысле "Хопёр-Инвест отличная компания (от других)"?

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

чувствуется закономерность результата

Не понял, вам дают маленькое удобство, свободу от компоновщика, а вам плохо.

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

[Advertiser]

[litwr]

Ещё раз. Про вызовы к ядру MACRO-11 ни сном ни духом. Поэтому возможности языка можно показывать, транслируясь под ЛЮБОЙ операционкой.

А каким образом число 65536 влезет в 16 бит - вы подумали?
А те кто думает, пишут так MEMSZ = 65535.-.+1
И всё нормально считается. Ну кроме случая, когда программа занимает всю память

Что за ерунда? Откуда опять ядро?! Вам про то, что вы тут RSX-11 якобы продвигаете, а сами втихомолку являетесь поклонником RT-11. Про числа написал ясно - любые.
А макрос вы теперь очевидно и сами не знаете как делать. Как и писал, несколько лет назал знающие люди на БК форуме (среди них возможно и вы были) искали и не нашли.

уже не помню, но при чём тут вообще смещение? когда нужен просто инкремент указателя

Возьмем типичную команду загрузки из памяти MOVE data(a3),d0. В этой команде a3 - база, а data - это 16-БИТНОЕ смещение, если вам нужны данные, которые не влазят в 64 КБ (например, data2), то базу надо менять. Это абсолютно аналогично ситуации с х86.

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

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

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

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

в 18 раз на одинаковой частоте (если брать всю итерацию, а не только деление)

У меня получилось для АРМа 16 тактов, а для 8086 более 300. Деление на 8086 выполняется за разное число тактов для разных аргументов, поэтому подсчитать точное число тактов очень непросто и неоднозначно.

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

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

ага, щяз на 32-битных проиграет в 3.6+ раза (и на 16-битных не должен обогнать)

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

вот конкретно в этой задаче не обгонит даже на удвоенной частоте (а первые 386 шли от 12мгц)

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

шта? опять смешались мухи с котлетами... в данном случае размер кода будет близок к 8086 варианту
для универсального же деления, в армокоде будет просто "BL udiv", который всяко нужен неоднократно

Универсальное 32-битное деление на 80386 - это одна команда от 2 до 4 байт, на Арме, если делать побыстрее без циклов, то более 200 байт, а с циклами - не менее 60. И это про Арм-варианты, когда делимое 32 бита. На 80386 оно 64 бита. На 80286 и 8086 делимое 32 бита.

да не так уж сильно, раза в полтора в среднем (и это для полностью программной реализации!)
зато очень быстрое умножение, которое нужно намного чаще, в том числе неявно (адрес в массиве)

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

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

а с вызовом универсальной (или частных случаев) процедуры - меньше!

Повторю, не спортивно.

трюки есть и менее сложные (например, прочесть пачку аргументов одной командой там, где 386 вынужден уныло копаться в стеке) и результаты следует оценивать комплексно

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

совершенно к делу не относящиеся

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

см. выше - дохренища я написал и специализация надоела

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

во-1 не в три раза, а от силы в два, иначе прямые спектрумовские порты так заметно на комоде не тормозили бы (в отличие портов на атари с его как раз ровно вдвое меньшей частотой камня); во-2, пример 6502 подтверждает как раз обратное, потому что он вообще не мог работать на таких частотах, чтобы догнать, будучи привязанным к памяти; в-3, если память не ограничивает скорость проца вообще, то она регистрами и является (потому что даже кэш на одном кристалле даёт задержки)

У Коммодора менее мегагерца, поэтому если считать 6502 в 2.5 раза шустрее, то отставание от спека на 40%, а в Атарях процентов 30-40% частоты штатно съедало видео - поэтому и там имеем те же 2.5 раза. 6502 нужна была память побыстрее и с этим были проблемы, но дело портилось ещё тем, что почти все или даже все компы на 6502 использовали память одновременно для видео и процессора, что очень снижало скорость, и требовало в 2 РАЗА более быстрой памяти, чем процессор. А у Спека была быстрая память, без тормозов. Но 6502 работал с памятью как с регистрами, не тормозя, такт на обращение. В когда-то популярном в Штатах TI-99, процессор вообще не имел регистров - если память не тормозит, то это очень неплохое решение.

в возне со стеком (но да, на x86 это не "проблема", там это жизнь)))

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

точно, XCHG нету есть EXG - обмен между регистрами; и между половинками регистра данных (SWAP называется)

Точно. Попутал меня 8086, где для обоих случаев XCHG. А SWAP действительно хорошая вещь, сильно помогает для кодов 68000.

а я писал, что и в арифметике подойдут

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

для КАКИХ? в вычислениях применять их можно только парой, только для логики
что ни гибче, ни тем более "существенно" гибче

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

то есть "отличный ММЮ" раньше было в смысле "Хопёр-Инвест отличная компания (от других)"?

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

чувствуется закономерность результата

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

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

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

- - - Добавлено - - -

И всё нормально считается. Ну кроме случая, когда программа занимает всю память

Вот набрал пример в RSX-11 - не работает.

.MAIN.	MACRO V05.05  Monday 24-FEB-20 11:33  Page 1


      1					    .mcall exit$s
      2	000000				start:
      3	000000	012700 	000004'		    mov #b,r0
A     4		037174 			    a = 16000.-.
      5	000004				b:    exit$s
      6		000000'			    .end start

.MAIN.	MACRO V05.05  Monday 24-FEB-20 11:33  Page 1-1
Symbol table

A     = ******   	B       000004R  	START   000000R

. ABS.	000000    000	(RW,I,GBL,ABS,OVR)
      	000012    001	(RW,I,LCL,REL,CON)
Errors detected:  1

*** Assembler statistics
Work  file  reads: 0
Work  file writes: 0
Size of work file: 201 Words  ( 1 Pages)
Size of core pool: 9260 Words  ( 35 Pages)
Operating  system: RSX-11M/M-PLUS

[Hunta]

Что за ерунда? Откуда опять ядро?! Вам про то, что вы тут RSX-11 якобы продвигаете, а сами втихомолку являетесь поклонником RT-11. Про числа написал ясно - любые.

Вот набрал пример в RSX-11 - не работает.

Программирование на MACRO-11 подучите - и заработает

LOGIN.CMD;1                                  !  2!LOGIN.CMD
                                             !   !MOUDISKS.CMD
                                             !   !
                                             !  1!DU1:[BATCH]MICROS.DIR
                                             !  3!DU1:[ACD2]MICROS.DIR
...                                          !   !TEST.MAC
                                             !   !TMP.LST
[* КОНЕЦ ТЕКСТА *]



MCR > TYP TMP.LST





TEST    MACRO V05.05  Monday 2020-02-24 14:43  Page 1


      1                                         .TITLE  TEST
      2                                         .MCALL  EXIT$S
      3 000000                                  .ASECT
      4         001000                          .=1000
      5 001000  012700  001004          START:  MOV     #B, R0
      6         036174                          A = 16000.-.
      7 001004                          B:      EXIT$S
      8         001000                          .END    START




TEST    MACRO V05.05  Monday 2020-02-24 14:43  Page 1-1
Symbol table

A     = 036174          B       001004          START   001000

. ABS.  001012    000   (RW,I,GBL,ABS,OVR)
        000000    001   (RW,I,LCL,REL,CON)
Errors detected:  0

*** Assembler statistics


Work  file  reads: 0
Work  file writes: 0
Size of work file: 201 Words  ( 1 Pages)
Size of core pool: 13506 Words  ( 51 Pages)
Operating  system: RSX-11M/M-PLUS

Elapsed time: 00:00:00.01
TEST;1,TMP;1/-SP/NL:TTM=TEST
MCR >

А макрос вы теперь очевидно и сами не знаете как делать. Как и писал, несколько лет назал знающие люди на БК форуме (среди них возможно и вы были) искали и не нашли.

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

- - - Добавлено - - -

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

data - база, а a3 смещение

- - - Добавлено - - -

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

И не дай бог не тот регистр для операции использовать. А в PDP-11 - можно любой (кроме MUL и DIV). И если уж сильно захочется - можно регистры и переименовать. Так что для x86 - в минус запишем

- - - Добавлено - - -

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

А на PDP-11 - отличный для любых случаев

[litwr]

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

От жадности не лопните. Мне-то это только для архива, не особо и нужно. Хотите схоронить, дело ваше. Но вроде вы же из МГУ, вроде как святоч премудростей - должны просветлять народ. И это форум, не приватный разговор - тут не только мы с вами. Хотя уверен, что сами не знаете.

data - база, а a3 смещение

Какая чушь! У меня переменные называются data, data2, ...

И не дай бог не тот регистр для операции использовать. А в PDP-11 - можно любой (кроме MUL и DIV). И если уж сильно захочется - можно регистры и переименовать.

И низачем это не нужно, вот в х86 всё гораздо лучше. Нужен счетчик (counter) берем CX, нужна база - BX и т. д. - просто совершенство почти и не надо пространство кодов захламлять излишними индексами ронов как это сделано в почти ортогональных ассемблерах. Ортогональность - это тяжкое наследие 70-х, подражание которому сгубило Моторолу. В ПДП-11 R5 и R6 тоже вроде как обычные регистры с номерами, но нормально все-таки писать SP и PC - Интел научило как правильно.

А на PDP-11 - отличный для любых случаев

Только для одного, для потерявшихся во времени некоторых расейских магазинах. А по честному - это начавшая устаревать с начала 80-х система, устаревшая полностью к началу 90-х.

[Hunta]

И это форум, не приватный разговор - тут не только мы с вами.

И это должно меня волновать?

Какая чушь!

Чушь пока вы порете

Нужен счетчик (counter) берем CX, нужна база - BX и т. д

Шаг вправо-влево - расстрел на месте, прыжок - попытка улететь. Нравится программировать в узких рамках - ваши проблемы

. А по честному - это начавшая устаревать с начала 80-х система, устаревшая полностью к началу 90-х.

Так чего вы к ней лезете - забудьте как страшный сон.

[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

[litwr]

Так чего вы к ней лезете - забудьте как страшный сон.

Трудно мне вас понять. Откуда такие суждения? Была системка, в чем-то неплохая. В чем проблема?

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

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

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

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

Всё, кроме последнего, непонятно про что. А в последнем явная ошибка. Зачем менять ds для массивов, для этого предназначен ES?

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

Типа, что если регистров не очень много, то придется часть из них сохранять при вызове функции. Отчасти верно.

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

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

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

Одна команда - это 4 байта и ещё 4 байта на возврат. На 80386 это типично 4 байта на обе команды.

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

Отстаёте от жизни. Сейчас 64 бита - стандарт, а компиляторы нормальные уже 128 бит на целое предлагают.

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

Буду очень благодарен на ссылку на такое супер-арм-деление. Мне не получилось найти ничего быстрее 100 тактов при 32-битном делителе. В пи-затворе для деления 32 бит на 16 получилось 54 такта в среднем, но это при том что у пи-затвора очень редко случается тормозной случай на 88 тактов. В настоящем среднем получилось бы 71 такт.

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

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

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

Это уже оптимизация. И примерно также можно работать и х86-64 - там 16 регистров, а у АРМ - 15. Кстати, команды по загрузке/выгрузке регистров в/из стека 1-байтовые, поэтому одна команда АРМ по загрузке данных займет столько, сколько 4 на х86. Конечно, в целом у Арм тут преимущество, но не огромное.

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

Начали абстракто, что плотнее. А для чего Пальцы, это ваша тема, которую вы ничем кроме своего мнения не подтвердили.

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

А что их надо называть одинаково? Сапожник, спеки булку!

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

Торможение у Коммодора от видео небольшое, всего примерно 5%, а частота почти на 80% меньше, чем на Атарях. Но видео у Атари тормозное. В итоге, Атари на процентов сорок быстрее Коммодора. Что тут не так? 40% очень заметно в играх. С другой стороны, если переносить игры с С64 на Спектрум, то Спек тормозить может очень сильно при очень существенной потере качества.

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

Повторю, на большинстве 6502 систем, память должна была быть быстрее процессора. Почитайте, например, про ВВС Micro в википедии - они там расписывают проблему доставания памяти на 4 МГц в 1980, при том, что процессор на 2 МГц.

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

Это из 70-х, памяти было в обрез. А если бы поставили нормальную память всю в 80-е, то получилось бы неплохо. Не зря IBM среди процессоров для РС серьёзно рассматривало и это, но им было мало адресуемости только 64 КБ.

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

Опять вас не понял. В современных х86 регистров как и в Арм. Арм-64 - это отдельная тема.

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

А при чем тут нули в старших разрядах? И не нули там, а что напишут.

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

Вы о разном, о вызове функций и загрузке данных.

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

Многозадачность там как и под первыми виндузами - до запуска первой игры или даже демки.

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

Зря вы их смешиваете. Арм - это достойный конкурент х86, который будь у Акорна больше ресурсов мог бы его существенно превзойти. 68к - скорее неудачное развитие технологий DEC, VAX - гораздо удачнее. Из 68к только 68000 получился реально конкурентным, но и он в себе содержал такие недостатки, что развивать его не получилось. А 68020/30 эти недостатки только усугубили. Хотя интересные тоже были процессоры, до сих пор где-то в контроллерах используют.

[litwr]

Про близость архитектур ARM и x86 идеям мейнфреймов Белоснежки - https://habr.com/ru/post/514096/

[Lethargeek]

снова ересь про "соединение risc и cisc" - один журналамер некогда ляпнул, а другие до сих пор повторяют
эти термины относиться могут только к МАКРОархитектуре, то есть к уровню ассемблера, доступному программисту
а на нём x86 как был всю историю чистейшим цыском, так и остался

- - - Добавлено - - -

не распарсил сразу про "два бита вместо привычных флагов"
вообще-то это те же самые флаги, просто смысл их от контекста зависит
что должно быть привычно кодерам Z80 с его контекстным флагом P/V
и далее по тексту мутно, то 2 бита, то 4, поди пойми