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

[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

[Advertiser]