Программирование на УКНЦ как?

[Titus]

К тому, чтобы лучше понимать программы и не городить идиотизм вроде

ERROR:  SEC
        RETURN
OK:     CLC
        RETURN

Чем советские (да и не только) программы частенько страдают

Все же твоя таблица напоминает что-то PDP-11, а не ВМ2. Взять те же ASC и ASCH. Никаких непредсказуемых результатов в них нет. Да и в других командах непонятно, чего там непредсказуемого?

[Advertiser]

[form]

Все же твоя таблица напоминает что-то PDP-11, а не ВМ2. Взять те же ASC и ASCH. Никаких непредсказуемых результатов в них нет. Да и в других командах непонятно, чего там непредсказуемого?

В пределах одной отдельно взятой машины вообще непредсказуемых результатов не будет. А если тебе захочется чтобы программа работала не только на УКНЦ, но и еще где-нибудь - надо считаться с возможными вариантами. Взять те же ASH и ASHC которые по разному себя поведут в описанном случае

[Patron]

К тому, чтобы лучше понимать программы и не городить идиотизм вроде

ERROR:  SEC
        RETURN
OK:     CLC
        RETURN

Чем советские (да и не только) программы частенько страдают :)

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

...

Например,

MTPS 0

вместо

MTPS #0

- это гораздо хуже. ( А я именно так и отличился недавно - у половины MTPS забыл решётки к числам добавить и очень потом удивлялся странному поведению программы :)

[form]

DEC наверное не случайно ошибку Z пишет почти на все эти команды?

[Titus]

В пределах одной отдельно взятой машины вообще непредсказуемых результатов не будет. А если тебе захочется чтобы программа работала не только на УКНЦ, но и еще где-нибудь - надо считаться с возможными вариантами. Взять те же ASH и ASHC которые по разному себя поведут в описанном случае

Лично я не ставлю себе задачи писать на УКНЦ, чтобы это потом работало на PDP11 каких-нить. На ДВК - куда не шло. Но как справочная таблица отдельных команд, которые работаю по-разному на разных процессорах - полезно.

[form]

у половины MTPS забыл решётки к числам добавить и очень потом удивлялся странному поведению программы

Ну это просто ошибка - всякое бывает

---------- Post added at 02:47 ---------- Previous post was at 02:43 ----------

Лично я не ставлю себе задачи писать на УКНЦ, чтобы это потом работало на PDP11 каких-нить. На ДВК - куда не шло. Но как справочная таблица отдельных команд, которые работаю по-разному на разных процессорах - полезно.

Так для того и есть таблица. Команды собственно даны так, чтобы место заполнить. Кроме ASH и явно косячных JMP на регистр, все остальные компилятор и так посчитает ошибкой

Куда важнее таблица признаков, особенно если будешь разбирать чьи-то программы. Далеко не всегда очевидно почему автор так уверен, что вот в этом месте скажем бит C сброшен, а в этом установлен итд. Или к примеру встречал такую ошибку - при 32битном счетчике пытались оперировать командой INC вместо нужного ADD #1.

[Patron]

при 32битном счетчике пытались оперировать командой INC вместо нужного ADD #1.

Поэтому, чтобы сэкономить одно слово в обработчике прерывания таймера RT-11 - в PSW его вектора установлен бит C (в чём легко можно убедиться, выполнив в KMON команду "E 102"):

.E 102
000341
.

а сам обработчик выглядит так:

LKINT::
	ADC	$TIME+2
	ADC	$TIME
	RTI

[form]

Поэтому, чтобы сэкономить одно слово в обработчике прерывания таймера RT-11 - в PSW его вектора установлен бит C (в чём легко можно убедиться, выполнив в KMON команду "E 102"):

.E 102
000341
.

а сам обработчик выглядит так:

LKINT::
	ADC	$TIME+2
	ADC	$TIME
	RTI

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

И здесь опять таки таблица признаков помогает. Можно к примеру сравнить R1,#1, а можно и #1,R1 и мы можем сэкономить на чем-нибудь за счет этого

[Titus]

А как на PDP11 реализуются 32-битные сумматоры, чтобы можно было пользоваться флагом арифметического переполнения V?
На тех процессорах, где есть команда ADC R0,R1, понятно. Просто делаешь ADD #low_byte,R0; ADC #high_byte,R1.
А на PDP11 как? И еще раз, я имею ввиду конечный флаг V, а не результат.

[form]

А как на PDP11 реализуются 32-битные сумматоры, чтобы можно было пользоваться флагом арифметического переполнения V?
На тех процессорах, где есть команда ADC R0,R1, понятно. Просто делаешь ADD #low_byte,R0; ADC #high_byte,R1.
А на PDP11 как? И еще раз, я имею ввиду конечный флаг V, а не результат.

ADC - базовая команда и есть везде.
Что до флага V, тут он мало поможет ибо переполнение - это переход от 77777 к 100000