Про 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 парубайтки существенно гибче для таких случаев

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

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

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

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

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

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

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