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

[Hunta]

Помогут, драйверы - это тоже программы.

Аха. Конечно.

Мы говорим о довольно редких вещах. Читал когда-то, что пытались использовать эти регистры базы с системой RT11 и были проблемы.

Это вы расскажите виртуальным массивам фортрана под SJ на системах с ДП. Или моему драйверу CF под RSX, который только что начал играться с регистрами ДП

А что там такого особенного?

Вот именно что ничего особенного и сложного.

Не нашел там электронных таблиц. Помогите.

Ищите да обрящете. А у меня своих дел хватает. Нет.

Извините, но без вашей помощи не смогу понять, как можно 128 кб кода в 64 кб адресном пространстве.

Документация на RSX-11M-Plus и на, скажем, J-11

Отлично, но об этом и предыдущем случае вы не упомянули.

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

Это про то, что 8086 гораздо более новая и продвинутая технология?

Это про то, что более старая машину уделает более новую

Так не долго и в маргиналы попасть.

Мне как то фиолетово, что не и мало знакомые люди обо мне думают

А макрос такой очень даже полезный

Вот в качестве домашнего задания и напишите его

Адиос

[litwr]

Аха. Конечно.

Так я думал - вам и показать нечего.

Это вы расскажите виртуальным массивам фортрана под SJ на системах с ДП. Или моему драйверу CF под RSX, который только что начал играться с регистрами ДП

Ваш драйвер? У мощного DEC сил не нашлось сделать, а самоделкин демку сделал? Вот о том и речь, что эти возможности - это только современные надуманные изыскания, которые в штатных системах были на обочине развития.

Ищите да обрящете. А у меня своих дел хватает. Нет.

Так нет ничего. Википедия про Мультиплан: есть для CP/M, Apple II, Macintosh, MS-DOS, Xenix, Commodore 64, CTOS, TI-99/4A, TRS-80, Thomson computers - для PDP-11 нет; Supercalc: есть для CP/M, MS-DOS, VMS - для PDP-11 нет; Visicalc: есть для Apple II, Apple SOS, CP/M, Atari 8-bit family, Commodore PET, TRSDOS, Sony SMC-70, DOS, HP series 80 - нету для PDP-11. Не было для пидипей таблиц. Может самоделкины сделают? У меня знакомый для 8-битки сделал класные таблицы. Неужели для 16-битки никто не возьмётся? Все только "драйвера" пишут для магазина?

Документация на RSX-11M-Plus и на, скажем, J-11

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

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

Так сами написали якоды исчерпывающий список. Вот и подумал, не знаете, решил помогать. Где же мне добыть телепатию или телепата?!

Вот в качестве домашнего задания и напишите его

Помню всем БК-миром пробовали, не осилили - слаб макро-11 для настоящих макро.

[Hunta]

Так я думал - вам и показать нечего

Беда-беда-печаль.

аш драйвер? У мощного DEC сил не нашлось сделать, а самоделкин демку сделал?

Штатный механизм, предусмотренный DEC

Википедия

Прям светоч знаний

Вас просили помочь. Нужно лишь несколько слов.

Несколько слов - читаем доки

Помню всем БК-миром пробовали, не осилили - слаб макро-11 для настоящих макро

Или слаб мир БК

[Lethargeek]

LDS для работы с памятью, размером с десяток байт?!

а где гарантии, что в ds нужное значение перед вызовом? то, что там всегда одно значение - не предлагать! тогда это не полноценный аналог того кода 68k

Передавать параметры в регистрах - штука обычная.

как и чтение из памяти их в регистры (разве что результат долгих вычислений требуется сразу в ascii)

А про арм-код не понял, где он? У арм2 нет аппратного деления, поэтому подобный код для арма должен быть весьма большим, сомневаюсь, что 56 байт хватит.

так это же деление на константу - вот что предлагают в древней книжке 1994 года:

	SUB	a2, a1, #10             ; keep (x-10) for later
	SUB	a1, a1, a1, lsr #2
	ADD	a1, a1, a1, lsr #4
	ADD	a1, a1, a1, lsr #8
	ADD	a1, a1, a1, lsr #16
	MOV	a1, a1, lsr #3
	ADD	a3, a1, a1, asl #2
	SUBS	a2, a2, a3, asl #1      ; calc (x-10) - (x/10)*10
	ADDPL	a1, a1, #1              ; fix-up quotient
	ADDMI	a2, a2, #10             ; fix-up remainder

итого 10 команд, 40 байт, 10 тактов - ха-ха, против ~300 тактов пары аппаратных интелевских делений
(притом даже универсальное деление на арм2 емнип в среднем вдвое быстрее аппаратного 8086)

если к этому куску добавить обвязку:

	LDR	a4, _BUFFER
_LOOP:	udiv10	из примера
	ORR	a2, a2, '0'
	STRB	a2, [a4, #1]!
	CMP	a1, #0
	BNZ	_LOOP
	MOV	pc, lr

получилось 64 байта с инлайном (чуть наврал, в уме забыл учесть две команды)

...но всё равно

Похоже нужен урок английского.

точно нужен, вот только совсем не мне

сode density is less so an application in RISC is likely to consume more memory than the equivalent in CISC - переводится как "плотность кодов [у RISC] - МЕНЬШЕ, так что приложение для RISC cкорее всего потребит больше памяти, чем эквивалентное для CISC"

и? что здесь противоречит моим словам о неконкретности этой части утверждения? при том, что здесь даже не "highly likely" )))

however the ARM has a few tricks up its sleeve to reverse this assumption - "однако, АРМ имеет несколько трюков в рукаве, которые могут опровергнуть это предположение"

а вот здесь как раз однозначно "ЧТОБЫ опровергнуть" без всяких "могут"

Я встречал и другие с примерно теми же результатами. 2010-е - это не 90-е.

вот именно, SIMD уже играли слишком большую роль и на десктопных интелах были тупо шире мобильных армовских
положение стало выправляться совсем недавно

Если у вас есть обратные данные, дайте ссылку, сам таких не встречал.

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

Амиговцев понять можно - код 68000 довольно плотный, но армовцы никогда тут не спорили - зачем бы тогда нужно было Пальцы изобретать?

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

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

на заборе тоже пишут много чего

Хотя более плотные коды из-за лучшей утилизации кэша могут иметь и преимущества по скорости.

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

Менеджмент менеджментом, но отсутствие доступного по цене компа на 68к, способного запустить Дум - это тоже фактор.

это тоже следствие менеджмента

Мне кажется, вы путаете понятие индексного и базового регистра.

Именно что кажется (как всегда) - собственные сообщения забываем?

У х86 роль адресных играют сегментные регистры,

итак, кто сам же и сказал "адресных"? АДРЕСНЫХ - не индексных и не базовых! но ПОЛНЫЙ адрес x86 содержится в ДВУХ регистрах

Сегменты х86 - никак не индексы, а только базы.

и никак не базы, потому что BASE pointer - это bp у нормальной базы не должно быть ограничений на положение

В 68к адресные регистры базы могут быть использованы, пусть и с накладками, как индексы.

нет, как раз там они могут быть действительно использованы как АДРЕСНЫЕ, то есть содержащие ПОЛНОЦЕННЫЙ адрес в ОДНОМ регистре

А как же без возни с регистрами?!

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

Это общий момент программирования на ассемблере.

...для процессоров с вопиющим дефицитом даже неуниверсальных регистров (то есть восьмибитных и старых интелов))

Это верно, отбросим один-два адресных 16-битных регистра для этих нужд и всё-равно у х86 получим 8 байтовых регистров и один-два парубайтовых. А пары байт можно брать и из стека, без адресных регистров (только SP).

но уже только последовательно (вот она, возня, уже началась)))

Пары байт в х86 отлично работают, а вот 68000 не работают вообще. Там поменять местами байты в слове - это большой тормоз - быстрее из памяти оба байта достать.

А вот не нужно байты в слове менять - можно поменять слова и работать с младшим байтом каждого слова, забив на старшие. Встречный вопрос - а как в x86 поменять без тормозов местами байты в суперудобных "парубайтовых" di/si/bp? Ааась?

И даже если вы поместите два байта в адресный регистр, вам чтобы достать их для обработки потребуется больше тактов, чем загрузить их оба из памяти в регистры данных. Итого по 68к имеем 8 байтовых регистров и всё, а х86 имеет чуть, но больше.

неееет, итого имеем в мотороле:
= 8 байтовых регистров (младшие байты регистров данных)
= 8 байт еще для обмена с ними (третьи байты регистров данных)
+ до 7 байт-источников в адресных регистрах
А что же в 8086? 8 байтовых регистров и до 3 "парубайтовых", с которыми непонятно как работать, кроме xchg. Но так можно и в мотороле.

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

Вы опять про ДОС, который был ОДНОЗАДАЧНЫМ.

и почему же он с таким расчудесным супер-пупер-ММЮ на сегментах был однозадачным?

Могу только удивляться оперативности Интел, который сделал поддержку многозадачности ДОС уже к 1985.

об чём речь? на пц многозадачность стала робко пробиваться с 386 (а скорости хватать стало только с 486)

У меня была Амига-500 с 1988 и экранчик Guru Meditation возникал очень даже нередко.

так это аналог BSOD, то есть сбоя в компонентах самой системы, который и под виндой с настоящим MMU (а не "мемею") регулярно

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

нет, речь о том, что лучше уж раз в полгода запустить лишнюю софтварь ради ерунды, чем всю жизнь таскать харварные костыли

[litwr]

Несколько слов - читаем доки

Или слаб мир БК

Оказывается всё просто, юзер использует системные вызовы как подпрограммы - это не настоящие 128 кб кода, а только что-то похожее на них. И, уважаемый эксперт, поделились бы своим знанием, не хоронили бы его, просветили публику. Мне вот представляется, что многие ограничения макро-11 - это следствие его 2-проходности, которой часто не хватает, например, даже .word . он не осилит. FASM запросто может делать по 4 и более проходов.

а где гарантии, что в ds нужное значение перед вызовом? то, что там всегда одно значение - не предлагать! тогда это не полноценный аналог того кода 68k

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

как и чтение из памяти их в регистры (разве что результат долгих вычислений требуется сразу в ascii)

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

так это же деление на константу - вот что предлагают в древней книжке 1994 года:
итого 10 команд, 40 байт, 10 тактов - ха-ха, против ~300 тактов пары аппаратных интелевских делений
(притом даже универсальное деление на арм2 емнип в среднем вдвое быстрее аппаратного 8086)

Благодарю за интесный алгоритм. Явно АРМ уделывает 8086 по скорости раз в 30, но по размеру кода проигрывает почти в два раза. Если сравним с более близким по времени 80286, то по скорости для 32-битных данных 80286 проиграет раза в полтора при том же выигрыше по размеру кода, а для 16-битных он уже существенно обгонит АРМ. Ровестник АРМ, 80386, обгонит его и по слегка скорости, и сильно (раз в 30) по размеру кода. Для универсального деления АРМ сильно отстает от 80286 и 80386.

если к этому куску добавить обвязку:
получилось 64 байта с инлайном (чуть наврал, в уме забыл учесть две команды)

LDR - это макрос и он может быть и 8 и даже более байт. Хотя если заменить ADDPL на ADDPLS, то можно убрать CMP, с учетом LDR получим опять примерно те же 64 байта, т.е. несмотря на все очень непростые алгоритмические трюки в более два раза больше, чем 8088, и почти в два раза больше, чем 68000.

а вот здесь как раз однозначно "ЧТОБЫ опровергнуть" без всяких "могут"

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

вот именно, SIMD уже играли слишком большую роль и на десктопных интелах были тупо шире мобильных армовских положение стало выправляться совсем недавно

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

Для АРМ компиляторы стали делать хорошо к концу 90-х, поэтому сомневаюсь, что найдете. Мощные у АРМ команды, но и большие.

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

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

на заборе тоже пишут много чего

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

Именно что кажется (как всегда) - собственные сообщения забываем?

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

итак, кто сам же и сказал "адресных"? АДРЕСНЫХ - не индексных и не базовых! но ПОЛНЫЙ адрес x86 содержится в ДВУХ регистрах

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

и никак не базы, потому что BASE pointer - это bp у нормальной базы не должно быть ограничений на положение

А вы с х86 знакомы? BP - это для работы со стеком, довесок к SP. База нужна, чтобы использовать более коpоткие адреса относительно неё. Поэтому BP по сути - это индексный регистр стека. На каком-то вторичном уровне восприятия это база стековых данных. Понятия индекса и базы иногда смешиваются, поскольку база тоже может быть относительной, а относительная база - это индекс.

нет, как раз там они могут быть действительно использованы как АДРЕСНЫЕ, то есть содержащие ПОЛНОЦЕННЫЙ адрес в ОДНОМ регистре

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

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

...для процессоров с вопиющим дефицитом даже неуниверсальных регистров (то есть восьмибитных и старых интелов))

Специализация давала возможность иметь более плотные коды (код 8086 более плотный, чем у современных х86). Сколько вы кодов х86 написали? Я более 100000 строк и считаю, что проблема специализации надуманная. Конечно, иметь много регистров - это хорошо, но не однозначно хорошо. Если иметь быструю память (а сегодня поставить даже гигабайт статической нетормозящей память вполне бюджетно), то можно и с минимумом регисторов получить отличную скорость. Пример 6502 это подтвреждает, который в почти три раза уделывал z80 на той же частоте. У z80, напомню, было гораздо больше регистров, чем у 6502. Пока только англичане со своим Графкор пробивают зомби-пелену, наведленную Интел/Нвидия с архитектурой очень медленная память плюс много кэшей.

но уже только последовательно (вот она, возня, уже началась)))

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

А вот не нужно байты в слове менять - можно поменять слова и работать с младшим байтом каждого слова, забив на старшие. Встречный вопрос - а как в x86 поменять без тормозов местами байты в суперудобных "парубайтовых" di/si/bp? Ааась?

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

неееет, итого имеем в мотороле:
= 8 байтовых регистров (младшие байты регистров данных)
= 8 байт еще для обмена с ними (третьи байты регистров данных)
+ до 7 байт-источников в адресных регистрах
А что же в 8086? 8 байтовых регистров и до 3 "парубайтовых", с которыми непонятно как работать, кроме xchg. Но так можно и в мотороле.

Реально вы хоть какой-то код для 68000 делали? Как вы там сможете использовать "третьи байты регистров данных"? Никак или с такими тормозами, что быстрее их брать прямо из памяти. Про адресные регистры уже писал - они мало приспособленны для данных, хотя как временный кэш для байт для загрузки-выгрузки из/в регистров данных подойдут. Но 8086 парубайтки существенно гибче для таких случаев

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

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

и почему же он с таким расчудесным супер-пупер-ММЮ на сегментах был однозадачным?

Шутим? Не было там нормального ММЮ, но если бы развитие пошло по ПДП-11 варианту, то такое полу-ММЮ могло бы неплохо сработать для бюджетных систем. А ДОС - это копия СР/М - с чего бы ему быть многозадачным?

об чём речь? на пц многозадачность стала робко пробиваться с 386 (а скорости хватать стало только с 486)

Не понятно о чем это вы пишите. В 80386 сделали отличную поддержку многозадачности для ДОС. Софт не успевали делать и была проблема эмуляции видео и звука, которых на РС становилось всё больше и процессор с этим не справлялся.

так это аналог BSOD, то есть сбоя в компонентах самой системы, который и под виндой с настоящим MMU (а не "мемею") регулярно

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

нет, речь о том, что лучше уж раз в полгода запустить лишнюю софтварь ради ерунды, чем всю жизнь таскать харварные костыли

Не понял, вам дают маленькое удобство, свободу от компоновщика, а вам плохо. Типа, хочу тупить лишние операции? Может в современных супертяжелых системах такие удобства маловостребованы, но когда-то, когда всё только начиналось, это было неплохим подспорьем.

[Hunta]

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

Доки читайте внимательней. Инструкция (а не системный вызов) CSM

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

Документации в инете - валом. Научились бы читать на английском и пользоваться гуглом.

например, даже .word . он не осилит.

Правда?

TEST	MACRO V05.06R Sunday 23-Feb-20  Page 1


      1						.TITLE	TEST
      2						.MCALL	.EXIT
      3
      4	000000				START:
      5	000000					.EXIT
      6	000002	000002'			W:	.WORD	.
      7		000000'				.END	START
TEST	MACRO V05.06R Sunday 23-Feb-20  Page 1-1
Symbol table

START   000000R  	W       000002R

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

*** Assembler statistics


Work  file  reads: 0
Work  file writes: 0
Size of work file: 60 Words  ( 1 Pages)
Size of core pool: 13056 Words  ( 51 Pages)
Operating  system: RT-11

Elapsed time: Unknown
DK:TTT,DK:TTT=DK:TTT

[litwr]

Документации в инете - валом. Научились бы читать на английском и пользоваться гуглом.

Так помогите нам, неумелым, никак не можем найти. На вас вся надежда.

Правда?

Всё про RSX-11 писали, а тут до RT-11 снизошли. He понятно... Ho по существу вы правы, проблема была в том, что адрес не был выровнен, на х86 такой проблемы не возникло бы. Ho это - мелочь, главный вопрос как макро-11 уговорить на макрос с правильным переходом.

[Hunta]

Так помогите нам, неумелым, никак не можем найти. На вас вся надежда.

Юродствуем? Ну ну.

Всё про RSX-11 писали, а тут до RT-11 снизошли.

А причём здесь операционка? MACRO-11 один и тот же. И про вызовы к ядру ОС он вообще ни сном ни духом

[litwr]

Юродствуем? Ну ну.
А причём здесь операционка? MACRO-11 один и тот же. И про вызовы к ядру ОС он вообще ни сном ни духом

Если вы на просьбу о помощи только хамите, ваше право. И про ядро не писал - это вы выдумали. А вот макро-11 не смог у меня посчитать размер памяти, например, MEMSZ = 65536 - .
Можно вместо 65536 взять другое число, минус не работает.

[Hunta]

И про ядро не писал - это вы выдумали.

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

А вот макро-11 не смог у меня посчитать размер памяти, например, MEMSZ = 65536 - .

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