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

[litwr]

Тогда не несите чушь и слушайте, что говорят те, кто работает с RSX с 84-ого года.

Слушают вас, уважаемый. Только не могли бы дать ссылки на свои программы? Вот у меня под пдп-11 архитектуру есть 3 больших проекта (кросс-компилятор бейсика, лаборатория клеточных автоматов, текстовый редактор) и один маленький (π-затвор).

Запросы к ядру

Оно и понятно.

Вообще то первый уровень - это каталог [0,0]. Рабочие каталоги - это уже второй уровень. Файловая система ODS-1. Третий уровень делали в P/OS. Поддержка третьего и дальше уровней штатно - ODS-2 и выше. Не могу сказать точно, почему не сделали, но судя по тому что я виде в исходниках VMS - это слишком ресурсно-затратно для тех времён. Хотя у меня есть мысль - добавить это дело на современных процессорах PDP-11

Если корень считать за уровень, то все файловые системы поддерживают каталоги. RSX-11 нет поддержки нормальной подкаталогов, в отличие от VMS. Добавить можно, но фирменного софта для этого нет. BQT сам такое написал - можете у него спросить - должен поделиться - зачем опять колесо изобретать?

Продвинутый пользователь перенес на неё RSX примерно лет за 10 до того, как на этом форуме поднялся вопрос (и долго муссировался), что RSX на ВМ3 не заработает, потому что в нём ошибки. Хорошо, что я примерно так в 91-92 годах об этом не подозревал и просто перенёс.

С этим Вам - респект.

Вы не спрашиваете. Вы утверждаете вещи, в которых не разбираетесь, по вашему же признанию

Уважаемый оппонент, давайте факты. Признаю, что считал, что с большими кодами поддержка в RSX-11 существенно похуже и разговор с вами помог мне с этим разобраться. Нашел даже некоторые большие файлы на серверах BQT: компилятор бейсика - DU:[3,54]BP2IC2.TSK (992 блоков), си-компилятор DU:[3,54]PDP11C.TSK (985 блоков)... Однако, базовый вопрос был о том, что получить более 64 КБ в PDP-11 системах - это намного сложнее и тормознее, чем в ДОСе. И всё, что вы сообщаете, это подтверждает.

А ничего, что первая RSX вышла в 74 году? Или тогда тоже ставили "много" памяти?

И первый ДОС вышел в 1981, когда по 64 КБ ставили. Думаю в это время на хорошие пдп-11 системы ставили уже все 4 метра, но для пользователя всё за пределами 64 кб получалось что-то типа памяти EMS для первых IBM PC, что-то типа продвинутого банкования.

Ещё одна полная хрень. Для RSX и XM монитора RT - отлично документировано и достаточно легко используется. Причём можно насчитать аж три подхода.

- прямая работа с соответствующими запросами к ядру системы
- непрямая работа - оверлеи, резидентные в памяти - в RSX. Вроде что то подобные было и в XM мониторе, но учитывая его убогую многозадачность, я RT практически не использую, поэтому сходу не могу не подтвердить, не опровергнутью
- массивы Virtual (теоретически - только под данные, но мы в своё время научились хитрить, но не получив от этого никакой пользы - для кода вернулись к пункту 2

Через прямые запросы к ядру много не наработаешь - хлопотно очень. Оверлеи - там надо со сценариями компоновщика колдовать (хотя некоторые компиляторы могут с этим помочь) и сама система очень тормознутая с множеством ограничений. Помню с чем-то таким на СР/М сталкивался. А для примитивной СР/М были даже хорошие электронные таблицы, которых на пдп-11 почему-то не хватило.

Могу ещё вам, эксперту (хотя скорее только опытному пользователю), кое-что подсказать. Можно ещё создавать отдельный сегмент для данных и получать адресуемых 128 КБ на процесс, но возможно ВМ3 этого не поддерживает, а KB11 и J11 поддерживают. Кроме того, есть ещё путанная возможность компоновать разделяемые библиотеки с исполняемой программой - плохо представляю, что это такое - разбирайтесь сами. Ещё есть что-то типа маппинга памяти - это как-то связано с виртуальными массивами - работать это должно очень небыстро. Осмелюсь предположить, что Х86 с перезагрузкой сегментного регистра для работы с большими массивами тут окажется на порядок или даже больше быстрее.

Хотя да, поскольку создатели Unix поделок шли каким-то своим тёмным путём - возможно, в Unix это так и осталось тёмным шаманством.

И Юникс не уважаете?

Те, кто в курсе, не спорят, что по состоянию на начало 80-х PDP-11 была лучшей 16-разрядной машинкой, и "феномен IBM PC" имел место быть только потому, что руководство и IBM, и DEC относились к самой идее персонального компьютера с глубочайшим презрением. Мол, модные игрушки, мода пройдет, а наши изделия останутся...

Уже были недешёвые системы на 68000 и в Штатах было много всего другого, но возможно по совокупности полезных свойств пдп-11 и был лучшей такой системой до года 83-84. По поводу презрения - сомневаюсь. Скорее чувствовали угрозу своему основному бизнесу (персоналки с конца 70-х пошли быстро растущей массой). IBM до PC сделала довольно популярный DataCenter, потом уже после PC какой-то комп на 68000, возможно ещё что-то. Повторю для вас, главная тема - это открытая архитектура IBM PC, так никогда раньше не делали. Чтобы не повторяться дам ссылку, там всё довольно конкретно - https://www.quora.com/Why-did-IBM-PC...Travis-Casey-4

А тема началась с моего заявления, что 68000 не состоялся потому, что не он был выбран Межделмашем в ЦП для писюка. Все тут же полезли в детали, с пеной у рта доказывая, что интелёвые процессоры лучше - быстрее, удобнее для программирования и т.п. Забывая о том, что 68000 надо сравнивать не с 80386, и даже не с 80286, а с 8088 (не 86!). Именно между ними стоял выбор у Межделмаша.

Отстали мотороловцы, не было никакого выбора. Получилось у них позже, чем надо, и дороже, чем надо. Тупили они всегда много и с своими 8-битками и с 68к, много копировали, рекламировали, а про дело забывали. По мне 68000 был их реально лучший процессор, если сравнивать его относительно других, имевшихся тогда. В 1982 он начал теснить 8086/8088, но пришли 80286 и 80186...

И вперёд и назад

Ну если бы такое не сработало, но мы бы с вами ничего не знали про макро-11 и всю архитектуру пдп-11. Речь была о более сложном случае. Нужен макрос, который бы раскрывался в BR, когда переход короткий и в JMP, когда длинный. Его несложно написать, но он работает только для переходов назад, для переходов вперед он неправильно считает смещение.

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

странная какая конверсия в перевёрнутую строку, но ладно уж
только по-честному вместо mov для загрузки адреса буфера надо бы использовать lds
да и параметры в регистры dx:ax тоже как-то попадают сперва из памяти

но самое смешное, что код arm2, оптимизированный на скорость (~18 тактов на итерацию!) занимает не так чтобы очень много - 56 байт
а если вызывать деление процедурой (каковая всё равно еще где-нибудь в большой программе будет нужна) - только 20 байт

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

не-не-не, ничего такого там НЕ написано! первая часть:

...говорит о неких абстрактных "рисках", а вторая:

...говорит о том, что конкретно арм способен ОПРОВЕРГНУТЬ (дословно: "перевернуть") это предположение!

Похоже нужен урок английского. сode density is less so an application in RISC is likely to consume more memory than the equivalent in CISC - переводится как "плотность кодов [у RISC] - МЕНЬШЕ, так что приложение для RISC cкорее всего потребит больше памяти, чем эквивалентное для CISC". however the ARM has a few tricks up its sleeve to reverse this assumption - "однако, АРМ имеет несколько трюков в рукаве, которые могут опровергнуть это предположение"

это ссылка на исследование качества компиляторов 2010-х годов, причём после долгих лет застоя на поле арма

Я встречал и другие с примерно теми же результатами. 2010-е - это не 90-е. Если у вас есть обратные данные, дайте ссылку, сам таких не встречал.

сомневаюсь, что все поголовно не сомневались, почитав, как реагировали амижники

Амиговцев понять можно - код 68000 довольно плотный, но армовцы никогда тут не спорили - зачем бы тогда нужно было Пальцы изобретать? Вот ссылка на мой материал по Арму - https://litwr.livejournal.com/2509.html -в комментах по плотности никто не отметился.

это то, что сделали ради мобильного рынка, где преобладали 16-битные шины, и на самом деле вовсе не для плотности, а для скорости

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

к тому времени амиги прекрасно закрывались самостоятельно в результате "эффективного менеджмента"

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

нетушки, только половину этой роли они играют

Мне кажется, вы путаете понятие индексного и базового регистра. Сегменты х86 - никак не индексы, а только базы. В 68к адресные регистры базы могут быть использованы, пусть и с накладками, как индексы. Но писал про необходимую для всех операций с памятью базу. В 68к её надо задавать явно, в х86 она обычно присутствует неявно (можно задать префиксом для редкого случая). Конечно, с адресными регистрами можно работать более гибко, чем с сегментными. Но для простого задания базы - сегментные регистры х86 придуманы отлично.

вообще для знакомых с x86 архитектурой возня привычна, потому что программирование x86 - это и есть постоянная возня со ВСЕМИ регистрами

А как же без возни с регистрами?! Это общий момент программирования на ассемблере.

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

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

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

почему это нельзя? из регистров данных можно грузить; и в арифметике и логике применять как байты-источники

Пары байт в х86 отлично работают, а вот 68000 не работают вообще. Там поменять местами байты в слове - это большой тормоз - быстрее из памяти оба байта достать. И с адресными регистрами 68к байты никак не пойдут - байты туда грузить нельзя, только слова, а слова только с четного адреса (для байт - не пойдёт). И даже если вы поместите два байта в адресный регистр, вам чтобы достать их для обработки потребуется больше тактов, чем загрузить их оба из памяти в регистры данных. Итого по 68к имеем 8 байтовых регистров и всё, а х86 имеет чуть, но больше.

ага, нормальный такой мультитаскинг, при котором over 95% наличного софта не работает, всё отлично

Вы опять про ДОС, который был ОДНОЗАДАЧНЫМ. Разработчики 80286 просто не могли знать про ДОС. Могу только удивляться оперативности Интел, который сделал поддержку многозадачности ДОС уже к 1985.

- наблюдаемая в объективной реальности over 95% амижных юзеров

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

выключалку нужно написать один раз

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