Pull to refresh

Comments 43

UFO just landed and posted this here
PDPшный ассемблер был образцом лаконичности и удобства для программиста. Изучался буквально за пару часов, причем в результате можно было писать программы прямо в машинных кодах и позволял делать, например, вот такие трюки:
MOV -(PC), -(PC)
PDPшный имеет более простой синтаксис. Но может это просто от того, что его я помню до сих пор, хотя прошло уже 30 лет.
Крис Касперский как то написал статью как в результате спора классика «HELLO WORD»
для BSD -Linux ужали до 96 байт.Самое прикольное-до 300 байт вообще не напрягались, в течение часа ужали.А дальше дым коромыслом-убили 4 часа…
Вот теперь, похоже, всё.

А если так:


    MOV #NUMBER,R1
    CLRB -(R1)
1:  CLR (R5)
2:  INC R5
    SUB #10.,R0
    BHIS 2
    ADD #58.,R0
    MOVB R0,-(R1)
    MOV R5,R0
    SOB R0, 1
    RET

14 слов, 11 инструкций.
Счетчик вычитаний в R5 начинается с нуля и после цикла будет на единицу больше, чем должен.
Команда SOB вычтет лишнюю единицу, проверит на 0 и выполнит переход к началу цикла.

Гениально. Только скобки вокруг R5 лишние.
Сейчас погоняю тесты на реальной БК 0010 (хотя, что может пойти не так?) и добавлю в статью со ссылкой на Вас.

Да, точно, со скобками явно ошибся.

Правильно ли я понял, как работает эта самая короткая программа? Она узнаёт остаток и частное от деления числа на 10 методом вычитания этих самых десяток? И если например у нее на входе будет 30000 то она будет заниматься вычитаниями 3 тысячи раз, в первом проходе по большому циклу? И сколько это времени займёт? Полсекунды на БК? Может, действительно такая процедура самая короткая, но в реальной жизни неприменима.

Да, алгоритм вычитает 10 много раз. Практика показала, что на БК 0010 числа от 60000 выводятся этой процедурой примерно по 7 штук за секунду. В реальной жизни аналогичный алгоритм всё же применялся в системе MKDOS.
В часах электронных используется, если программа на ассемблере.

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

Подпрограммка конечно маленькая и по своему красивая, но на практике ее ценность приближается к нулю. Гораздо практичнее будет добавить еще порядка 10 байт с табличкой: [10000, 1000, 100, 10, 1]. Функция станет не сильно больше, но скорость возрастет в тысячи раз.
С такой программы статья и начинается.
Еще, если помните, на БК был обалденный отладчик «PARADISE». Его особенность была в том, что он был полностью перемещаемым, ну очень функциональным и очень компактным. Все ядро занимало 6Кб. Его разработчики очень сильно поработали над оптимизацией по размеру кода. Не думаю что там будет магия какая-то, но вдруг: можно посмотреть как там реализован вывод 10-х целых.

Там может вообще не быть вывода десятичных чисел, только восьмеричных.

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

Не застал тех времён, но "перемещаемый" — значит мог запускаться вместе с другой программой, перезаписав все свои внутренние адреса?

Перемещаемая программа — это программа которая может работать будучи загружена по любому произвольному адресу. Обычно программы на ассемблере писались в расчете на то, что они будут загружены по конкретным адресам. Как правило это о1000. PDP-11 имела 8 режимов адресации. Некоторые из этих режимов задавали не абсолютный адрес операнда, а текущий адрес команды (PC) + смещение. Таким образом, используя вместо абсолютных адресов относительные, программа не зависела от адреса загрузки.
Обычно никто не старался, но в случае отладчика нужно было очень сильно экономить память, т.к. сама отлаживаемая программа занимала место + отладчик. Отладчик нужно было размещать в области памяти не используемой самой программой, поэтому было очень важно использовать режим адресации памяти не зависящий от фактического адреса загрузки.
UFO just landed and posted this here

Bы не правы. B linux например, даже 32битном, все .so (динамические библиотеки, аналог .dll в шиндошс) компилируются с флагом -fPIC (position-independent code) и не нуждаются в релокации при маппинге в разные виртуальные адреса каждому процессу. Tак что это сугубо вендовая недоработка.


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

UFO just landed and posted this here
Кстати, никогда не вдавался в подробности самого процесса. На БК-шке таких проблем с перемещаемым кодом не было, так как практически все команды поддерживали относительный режим адресации, но сам перемещаемый код работал медленнее. С чем это связано мне до конца не понятно. Неужели нельзя было использовать отдельный сумматор для этого случая, ведь мы всегда складываем регистр со значением и получать абсолютный адрес за один такт?
А как с этим делом на i386?
Не хотели усложнять процессор. К1801ВМ1 по тем временам (1981) и так был сложным процессором для советской промышленности. Исходя из таблицы длительности команд, загрузка абсолютного адреса в счётчик команд длится столько же, сколько прибавление смещения к текущему счётчику команд. Снижение скорости перемещаемых программ надо искать в другом месте. А именно, в прах команд MOV PC,R1 и ADD #N,R1 – такое часто встречается (например, если в R1 надо занести адрес текстовой строки или что-то подобное). А в неперемещаемых можно обойтись одной командой MOV #M,R1.
Да, все так. Возможно причина в подобном коде. Я сейчас уже плохо помню. Но в подавляющем числе случаев проблем с перемещаемым кодом не было. Ну, а так как с этим делом на i386?
UFO just landed and posted this here
По 386-ому ассемблеру я не спец. Вроде, уже ответили про EIP из стека.
Комментарий не по теме. Но…
БК. Это мое детство. Именно на ней я в 7 лет начинал изучать Бейсик, именно на ней в 12 лет на ассемблере в 98м году написал операционку DOS98 с FAT16 файловой системой :-D
Сколько игр на ней сыграно… А операционные системы? ANDOS, MKDOS, CSIDOS, NORD, RT-11… А демосцена? Не знал, что для нее еще пишут демки — честь и хвала вам!
P.S> В серверной, на полке в дальнем углу до сих пор лежит две пачки пятидюймовых дискет с софтом и наработками. Все еще надеюсь что записи прочтутся, что когда-нибудь найду комплект БК+флоповод и прочту все это. Не хочется выкидывать детство))
Очень интересно посмотреть Вашу DOS98!
С прочтением дискет могу помочь (Москва). Есть активные БКшники в Питере и в Казани – они тоже могут помочь.
Я бы сам не против ее посмотреть, но для этого надо найти дискету… а на ней исходники…
По поводу прочтения — это супер, как кончится карантин я с Вами постараюсь связаться!)
А я то думал чем вдохновлялись создатели игры Human Resource Machine
UFO just landed and posted this here
Строго говоря, инструкции деления и умножения подразумевают наличие в процессоре соответствующего микрокода для универсальных вычислений. В 1801ВМ1 такого микрокода нет. А деление и умножение на 2 традиционно называют «сдвигами».
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here

В свое время на zx spectrum делал печать числа в Dec путем сдвига числа на 2 и на 8. Остатки сдвигов — и есть ваше очередное число с конца. Точный алгоритм не помню но работало это очень быстро

Sign up to leave a comment.

Articles