Побитовые функции на МК-61

Вопрос к знатокам ПМК.

В регистрах имеются два числа диапазона 0:65535. Необходимо получить результат их побитового исключающего или. Как можно это сделать, уложившись не более, чем в 20 команд?

Наличие побитовых функций выглядит весьма соблазнительно, но их применение - дело не из самых простых. Полагаю, опытные программисты ПМК должны знать методику, позволяющую полноценно их использовать.

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

Побайтово выполняем операцию K XOR. Потом объединяем два байта результата в одно число «диапазона 0:65535». Конечно, если это требуется.

Разобьём. Хорошо, разбили на два байта. Но с этих пор начинается интересное: мы имеем два десятичных числа. Искл. ИЛИ (в МК-61 - (+), в БЭСМ-6 - НТЖ) их обработает как представления 16-чных чисел, будто бы они и не десятичные вовсе, а 16-чными цифрами записаны. В итоге имеем нужду преобразовать в 16-чные числа перед этой операцией.

Набросал такую программку, без особой оптимизации она выглядит так:
П0 0 П3 П4 1 П2 ИП0 П1 1 6
/ [x] П0 1 6 * ИП1 - /-/ П1
8 - x>=0 31 П1 ИП2 8 * ИП4 +
П4 ИП1 ИП2 * ИП3 + П3 ИП2 1 0
* П2 ИП0 x=0 07 ИП2 ИП3 + ИП2 ИП4
+ \/ С/П

Ровно половина памяти. Как-то не очень красиво получается.

K XOR в ПМК. Ваш вопрос распадается на несколько.

Для МК-61/52 это практически невозможно. Логические операции в этих ПМК совершаются над числами в специальном формате. Кроме того, что результат будет неудобочитаем, чтобы ввести в программу произвольные данные придётся предварительно перевести их в шестнадцатиричный формат, а при наличии цифр от A до F ещё и потрудиться с операцией ИЛИ.

Например, для Вашего примера из соседней ветки следует набрать: 8,3039 ↑ 8,8707 K(XOR) после чего в RX оказывается 8,L73E - это и есть искомое 0xB73E в записи ПМК.

Но обратную операцию выполнить уже не так просто, поскольку ввести 8,L73E с клавиатуры нельзя. Поэтому такая операция выполняется в две или три стадии:
8,3736 ↑ 8,8008 K(OR) после чего RX = "8,L73E"
далее набираем:
8,3039 K(XOR) - и получаем искомое RX = "8,8707"

Не следует также забывать, что получение цифры F (пробела) в первом знакоместе приводит к сбою ПМК. Чтобы не допускать этого в числах приходится иметь ещё один технический разряд, за содержимым которого следует следить. В примере выше это опущено для наглядности.

Всё вышеизложенное делает логические операции в ПМК МК-61/52 малоприменимыми по прямому назначению. Чаще всего их использовали для вывода нечисловых сообщений в программах.

Это понятно, но ведь это сложная и не до конца изученная система. Неужели нельзя каким-нибудь образом "по-быстрому" преобразовать числа в 16-ное представление или, например, проводить арифметические операции непосредственно над ними?

Система. Изученная. Микрокод МК-61/52 считан и на его основе был создан эмулятор.

А вот "по-быстрому" - не получится.

Микрокод считан. Эмулятор создан. А прочитан ли код? Покажите мне в коде ПЗУ хоть тот же легендарный ЕГГОГ или число пи. Преобразуйте его во что-либо читаемое, иначе говоря (судя по Вашему сообщению, уже сделано).

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

Поищите описание секционированных микропроцессорных комплектов или ПЛМ, для примера. А в случае ПМК разбор микропрограмм усугубляется ещё и последовательной однобитной шиной. :)

Если действительно хотите разобраться откуда берётся "Error" или число π - книга Трохименко Вам в помощь: http://pmk.arbinada.com/node/89

А можете пообщаться с теми, кто вскрывал программу ПМК и делал эмулятор. Думаю, они много интересного могут рассказать. Но начать лучше с книги: вопросы будут более разумными.

Надежда на лучшее. Я не общался с теми, кто вскрыл ПЗУ, да и дедушка Трохименко, к сожалению, умер, но уверен, что сегодня никто не скажет, где находится тот самый ЕГГОГ (вероятно, кто-то из разработчиков и сказал бы при наличии документации, но и её нету; книга "Устройство ПМК" не в счёт). И уж тем более никто не опишет во всех подробностях алгоритмы работы МК-61/52, потому что, как Вы верно заметили, код уж слишком низкоуровневый для нынешних программистов.

Потому надежда на то, что преобразование чисел ещё содержит в себе непознанные (по крайней мере, мною) тайны, остаётся.

"Some experiments with hacking the ЭЛЕКТРОНИКА МК-61". Тут интересная статья на английском:
http://www.alfredklomp.com/technology/mk-61/


"The МК-61, a hacker's system?
Compared to western programmable calculators, the МК-61 is far less refined, certainly when it comes to locking the machine down against abuse. It seems like the people who designed it were counting on the fact that anyone competent to use a programmable calculator would have the common sense to not push it past its limits and expect it to stay orthogonal.
... If you use the МК-61 as a normal programmable machine you will never experience any odd behaviour, but if you decide not to play fair and willingly inflict some good old torture, you will have it squealing in no time."

---------------------------
Истина где-то рядом
aldebaran.ru/author/samurov_vitaliyi/kniga_dozvonitsya_do_devyi/

Статья любопытная, хотя ничего нового в ней нет. Впрочем, автор и сам говорит:

I would like to apologize to all the Russian calculator hackers of the 1980's for stealing their turf, because I'm certain that they pioneered everything I discovered back then and probably considered it child's play. It's just because these people don't publish (or maybe only in Russian) that I haven't seen any of their articles and had to figure out everything by myself.

Кстати, код 3Dh кое-что всё же делает - копирует RX в RX1. Хотя, вообще-то, эта команда, наряду с 3Eh, была предназначена для работы с внешним ЗУ.

К слову о "дизайнерах". Статья оформлена со вкусом настоящего промышленного дизайнера. Подбор цветов, аккуратное форматирование, ракурсы. Культура.

Весьма интересная статья, автор проделал большую работу (интересно, что его на это сподвигло?). Хотя собранная им информация несколько отрывочна, ибо он шёл методом экспериментов, не имея под рукой никакой документации, она внушает надежду на то, что быстрое преобразование 10-ных и 16-ных чисел всё-таки возможно. К решению задачи может быть три пути. Либо преобразуем числа в 16-ные изначально, но тогда как проводить над ними арифметические операции? Либо работаем с 10-ными и в нужный момент переводим их, но в этом случае объём кода недопустимо велик. Либо только с 10-ными числами и работаем, но тогда зачем калькулятору вообще функция "(+)", объём кода не слишком-то и сократится?

Жёсткая книга. Книга Трохименко весьма сурова. Читать приходится с блокнотиком в руках, восстанавливая прошивки. Но каждое прочитанное там и понятое предложение даёт много понимания о том, как работали наши ПМК.

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

Даже те, кто делал эмулятор, до конца работы ПМК не представляют. Насколько я понял из их сообщений, они просто педантично восстановили считанный микроскопом код, как некий артефакт — и сами в нём до сих пор копаются.

Как. Руками она разрабатывалась, и головой. Автоматизированных средств в те годы было по минимуму - те же ПМК, к примеру. Зато всё работало, в отличие от.

Однако, ничего сумасшедшего или заумного там нет. Только для "века четырёхгиабайтных флешек", с его переизбытком "великих программистов" и засильем абстрактных языков сверхвысокого уровня это несколько непривычный подход. Если же на этом уровне хоть немного поработать, убожество современных "достижений" становится гораздо заметнее. ;)

На предыдущих разработках работа над ПМК основывалась, разумеется. Серия 145 (и родственные) имела немало любопытных контроллеров: http://www.155la3.ru/k145_2.htm - причём каждый из них содержит свой микрокод, поверх некоторой базовой схемы. И на этой базе много чего интересного делалось, вовсе не для бытовой аппаратуры.

Что в коде разбираются - это правильно. Значит не остановились на эмуляции и действительно хотят понять, как оно работает.

Сколько человек над микрокодом ПМК трудилось - лучше Генерального спросить, пока возможность есть. Скорее всего, рабочая группа, значит человек десять.

Никакого засилья "высокоабстрактных" языков нет. Ява и пошарпанный си - языки все того же третьего поколения, что и приплюснутый си с объектным паскалем. При этом языки 4 поколения вроде SQL вызывают у "великих программистов" непонимание и последующее неприятие.

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

Вопрос только в грамотности программистов. Среди пишуших на низкоуровневых языках непрофессионалов, как правило, меньше. Поскольку ассемблер за программистом код не чистит и ошибок не прощает. Да и выдать свои ошибки за глюки компилятора, чаще всего, не получится. При том, результат достаточно очевиден, а настойчивое требование программиста к инженерам добавить гигагерц тактовой частоты и пару гигабайт к ОЗУ для восстановления работоспособности устройства - может закончиться плачевно. :)

Полагаю, если бы изучение программирования начинали пусть не с ЭКВМ, что тоже неплохо, но с того же ассемблера - случайных и малограмотных людей в профессии было бы куда меньше.

Никакая среда не "чистит код" и не "прощает ошибок". У нерадивых программистов на яве исполнение программы сопровождается широко известным NPE (null pointer exception). Разница с ассемблерной в том, что среда исполнения не даёт программе упасть сразу, а спрашивает разрешения продолжить со следующей команды. Статические анализаторы кода существуют, но и для их использования нужно хотя бы представлять, что за термины в диагностике они выдают.

Относительное число некритичных к качеству проектов растет и будет расти, поэтому число программистов, не имеющих специального образования будет расти еще большими темпами. В критичных областях все по-прежнему. Просто в РФ число этих областей сократилось до уровня невидимости РосАтома и оборонных разработок, поскольку и в РосКосмосе падение качества уже заметно, и довыводом спутника на орбиту занимаются французы из Thales.

Век. Ну, не век в этом виноват.

Сейчас на Западе достаточно программистов, работающих на уровне микрокоманд и создающих разнообразные микропроцессоры. Просто в России государство ставит педагогической задачей №1 воспитание потребителей западной продукции — а природный интерес к тому, как устроен мир, осознанно глушат в людях религией.

Для гармоничного развития технологий обществу нужны люди, работающие по призванию на различных уровнях и любящие своё дело. В 90-х же годах прошлась мощная компания дискредитации не только по всему советскому, но и по низкоуровневому программированию. То, что мы вынуждены строить электронные устройства на зарубежных процессорах, а народ пользуется зарубежными устройствами — следствие той поистине хрущёвской «hate speech» ко всему, что тянуло и всем, кого тянуло к самым низким уровням технологического стека.

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

Век. Целенаправленное сворачивание технического прогресса на Западе тоже идёт полным ходом. Причины достаточно очевидны: господа Маркса внимательно изучали, это для внешнего потребления ими рекомендован Священный Экономикс.

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

16-битный XOR в ПМК. Если записать 16-битные числа в R1 и R2, то 16-битный XOR в старых ПМК (без использования быстрой и удобной K XOR, применяемой в ЭКВМ) будет где-то такой:

00. Cx П3
02. 1 П4
04. 16 П0
07. ИП1 2 ÷ K[x] П1 FВх K{x}
14. ИП2 2 ÷ K[x] П2 FВх K{x}
21. ↔ FR -
24. Fx≠0 30
26. ИП4 ИП3 + П3
30. ИП4 В↑ + П4
34. FL0 07
36. ИП3 С/П
37. КБП0

В МК-161 тоже должно работать, жаль проверить не могу. Программу особенно не оптимизировал. Основная логика побитового XOR закодирована на шагах 23 и 24, а на шагах 04 и 05 можно поставить большее (или меньшее) число бит, чем 16.

FRА что это за команда FR?

Поворот стека, то есть F c круговой стрелкой над клавишей "запятая".

Команда записана в латинской транскрипции по ГОСТ 24097-86.

Команда FR имеет код 25 и описана в пп. 4.4.2.4.3. «Руководства по эксплуатации» ЭКВМ.

Её традиционная русская мнемоника, к сожалению, плохо передаётся средствами Юникода. Поэтому я использовал её современное латинское обозначение. То, в котором ИП9 выглядит, как RM9.

FR, RM, ЭКВМ... Учитывая чрезмерную ориентацию "ЭКВМ" на западного потребителя, я уже ничему не удивляюсь. А русские люди обычно рисовали для этой команды стрелочку: "->", если не получалось с кружком.

Обозначения. Для этой команды, как правило, использовали обозначения "F O" или "F ,".

А ссылка на советский стандарт, в котором описана латинская транскрипция команд ПМК, приведена выше.

Причина, по которой для команд используется латинский алфавит достаточно тривиальна: программы ЭКВМ в такой записи можно без искажений записывать в КОИ-7 или передавать семибитным кодом. В том числе телеграфом, например, или азбукой Морзе. А также распечатывать на Консуле и АЦПУ. :)

Но если ориентация на "русского" потребителя в Вашей интерпретации подразумевает рисование вычурных знаков на бересте - никто не мешает выпустить свой ПМК, с лаптой и блудницами: http://habrahabr.ru/post/41561/

Зачем тогда вообще русский язык нужен? Латинская часть стандарта, очевидно, добавлена для изделий, идущих на экспорт. В остальных случаях обосновать её применение трудно. Но в случае ЭКВМ предлагаю вообще отказаться от русских обозначений, это избавит от многих проблем. И в КОИ-7 всё будет помещаться, и телеграфом передаваться, да и вообще, как Вы говорите, писать по-русски - всё равно что рисовать на бересте, а продвинутое человечество пишет по-английски (ну или по-китайски).

Тупым не понять. Тупому человеку не объяснить, зачем нужен русский язык. Точно также ему не понять, почему в медицине активно используется латынь, в каратэ-до японский язык, а в компьютерных науках — английский язык.

Я крайне рад, что разработкой ЭКВМ занимается Михаил Борисович, а не вы. Т.к. ваше предложение «вообще отказаться от русских обозначений» в ЭКВМ иначе, как диверсионным, не назовёшь.

Обоснования применению латинской мнемоники здесь приводилось. Если бы вы поменьше вставали в позу учителя и диктатора, которыми вы не являетесь — и побольше бы изучали материалы, приведённые здесь настоящими русскими людьми, то смогли бы давно их узнать.

Последовательность. Я просто предлагаю быть последовательными. Комплектующие китайского производства? Ладно. Слова языка калькулятора на английской базе? На здоровье. Только тогда уж доведите мысль до конца - надо и названия клавиш писать соответственно словам языка программирования, и документацию, и вообще всё перевести на английский. И систему команд возьмите у каких-нибудь импортных калькуляторов (правда, их разработчикам придётся заплатить, а то ещё плагиат узрят; это вам не мёртвого льва пинать).

Что касается использования иностранного языка, то ничего плохого в этом нету. Только надо знать меру.

Компилятор. Латинская транскрипция используется, в основном, для кросс-компиляторов. На экране ЭКВМ команды ЯМК представлены в русском варианте, хотя вывод латинского тоже возможен. В частности, и для нужд экспорта.

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

Но если есть желание - покажите пример. Напишите для сообщества новый "русский" кросс-компилятор ЯМК. Только вряд ли Вы за это возьмётесь: рассуждать о "пинании львов" или "надругательствах" - оно куда проще, нежели написать работающий код хотя бы для вычисления функции "исключающего ИЛИ". ;)

Кодировки. Так что, если имеется куча кодировок, русские буквы вообще лучше не использовать? Сразу транслитом писать, а потом и по-английски? Возьмите одну кодировку, лучший вариант - двухбайтовый Юникод, и только с ней и работайте. Не вижу тут никаких проблем.

Юникод UTF-16? А почему бы не UTF-8, например? Не говоря уж о UTF-7 или UTF-9. ;)

Как будем разбираться с порядком следования байт, четырьмя формами нормализации и т.п?

Что порекомендуете делать с компиляторами для DOS-совместимых систем, либо для Windows ранних версий? Или вообще не для IBM-совместимых СВТ?

То, что Вы не видите "тут никаких проблем", увы, говорит только об уровне знакомства с вопросом. :(

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

Кодировка внутри ЭКВМ как раз фиксирована и документирована с точностью до ширины образа символов.

Проблемы возникают при стыковке ЭКВМ с зарубежными компьютерами — и не только в области кодировок. Эти проблемы успешно решаются. Но это не так просто, как вы здесь это пытаетесь представить. Поэтому места, где отечественные технологии и зарубежные пересекаются, сведены к минимуму.

Если же следовать вашим идеалистическим советам, они сведутся к максимуму. Это приведёт к нежизнеспособному проекту (вашему «мёртвому льву»), т.к. средств, отпускаемых зарубежными корпорациями (HP, Касио, TI,…) в Новосибирске нет.

КБП0 38. КБП0 ;)

А программа на МК-161 работает, куда ж она денется. Приведённый выше тестовый пример: 12345 XOR 34567 = 46910

А ведь действительно работает. Спасибо и на том, интересный код.

K XOR в ЭКВМ. В МК-152 и других ЭКВМ этой серии логические операции совершаются непосредственно над целыми десятичными числами в диапазоне от 0 до 255. При необходимости, аргументы функции предварительно приводятся к этому виду.

В этом случае операции над числами размером больше байта проводится так, как говорил AtH. Но размер доступной памяти в ЭКВМ не требует втискивания данного алгоритма в 20 команд.

Для ввода и вывода шестнадцатиричных чисел в ЭКВМ есть специальные функции. Используя которые нетрудно сделать, к примеру, простейший шестнадцатиричный калькулятор.

ЭКВМ. Как Вы, наверное, догадываетесь, платить $150 ради того, чтобы посчитать побитовое исключающее ИЛИ, - не в моих интересах.

? Да Вам, собственно, никто ЭКВМ для этого и не предлагает.

А для требуемых вычислений - если они Вам действительно необходимы - попробуйте освоить калькулятор из Windows.

Да как-то освоил уже, не в том нужда.

А в чём? Практически любой инженерный калькулятор имеет режим работы с шестнадцатиричными числами. Это если вопрос в вычислениях.

Если имеется желание самостоятельно соорудить шестнадцатиричную математику для системы команд ПМК, боюсь, без возможностей МК-152 (и сопутствующих -$150) обойтись не получится. ;)

Расскажите, что хотелось бы получить в итоге - может быть, кто-нибудь и поможет.

Впрочем, можно поработать с расширенными возможностями ЯМК и без ЭКВМ, поскольку существуют эмуляторы. Например, VK6, разработанный AtH.

Хотя имеются и другие расширения ЯМК, несовместимые с рядом МК-152, но сохраняющие большую или меньшую преемственность с системой команд ПМК. Выполненные как аппаратно, так и программно - на различных кросс-платформах.

ЯМК. Если бы в том состояла моя нужда, я бы обошёлся каким-нибудь простым высокоуровневым языком, не слишком загружая себе мозги и разгружая кошелёк. Однако мне интересно, как это сделать на русских калькуляторах.

То есть, основная цель - продемонстрировать так называемый "стыд и позор". :)

$150 «платить $150 ради того, чтобы посчитать побитовое исключающее ИЛИ, - не в моих интересах»

Ну-ну. 4700 рублей, и даже больше, можно просто подарить НПП «СЕМИКО» — одно это будет добрым делом. Поддержкой производителя. Возможно, самым главным и лучшим поступком в жизни некоторых людей, получающих зарплату от врага напрямую или через нефтедоллары… Тут же за эту сумму ещё и ЭКВМ получаешь. На которой не только побитовые функции считают, которая внешними устройствами управлять по твоей программе умеет!

Люди сейчас больше денег тратят на женщин или пьянки с друзьями на выходных. Да и на другие сомнительные развлечения, включая неизбежно выходящие из моды зарубежные гаджеты, которые потом годами в шкафу пыль собирают.

Чем больше средств Новосибирск соберёт и чем больше получит нашей поддержки, тем быстрее появятся новые разработки. Тем более, что Михаил Борисович знакомится с пожеланиями владельцев ЭКВМ и учитывает их при разработке прошивок и новых моделей.

Пожелания. Но следует учесть, что пожелания высказываются не только посетителями сайта Кон-Тики. И вопросы эти решаются не единолично. :)

Не совсем понятно. Из описания не совсем понятно, что надо получить, в чем собственно, проблема и почему команда "K искл.ИЛИ" не подходит?

10-ные и 16-ные числа. Имеются два числа в регистрах, например, 12345 и 34567. Необходимо из них получить 46910 (0xB73E = 0x3039 (+) 0x8707). Если скормить их калькулятору (добавив префикс "8,", как он любит), получим отнюдь не 46910, а (8,)26622 (0x12345 (+) 0x34567 = 0x26622). Оно в принципе и правильно, ибо префикс подразумевает 16-чное число. Но тогда как обработать 10-ные числа?

То есть, в применении к реализации логических функций на МК-52/61, задача состоит из этапов:

  1. Перевод числа в 16-ричный вид
  2. Применение лог.операции
  3. Перевод результата в 10-ный вид

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

Оффтопик, но для иллюстрации (+). Просто для иллюстрации, программа для HP-35s занимает 15 байт и выглядит так:

A001 LBL A
A002 INPUT A
A003 INPUT B
A004 XOR
A005 RTN
----
LN=15
CK=A0DD

Результат работы:

XEQ A
A?
12345
R/S
B?
34567
R/S
46910.0000

---------------------------
Истина где-то рядом
aldebaran.ru/author/samurov_vitaliyi/kniga_dozvonitsya_do_devyi/

Ну так есть же разница - 2007 год и начало 80-х.

Конечно, разница есть, хотя дизайн обеих ПМК - классический :)
http://pmk.arbinada.com/system/files/hp35s_vs_mk61.JPG

Возвращаясь к программе, мне кажется, что эту же программу можно запустить на HP-41c - модели 1979года.

---------------------------
Истина где-то рядом
aldebaran.ru/author/samurov_vitaliyi/kniga_dozvonitsya_do_devyi/

Главное здесь — наличие команды XOR, а не год изготовления. Вся «программа для HP-35s» — всего лишь сервисное обрамление этой команды. Те же 15 байт можно потратить, скажем, на операцию сложения или умножения. На деле для выполнения операции «Исключающее ИЛИ» над 16-битными числами никакой программы на этих калькуляторах не нужно, достаточно исполнить команду XOR.

В советских ПМК команда K⊕ использовалась чаще всего для видеосообщений, заточена была под это. Лишь в небольшом числе программ её действительно использовали для логической операции XOR.

Видео. Не думаю, что разработчики так заботились о том, чтобы облегчить вывод видеосообщений. Просто эти функции были реализованы весьма специфически.

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

Скажем так, реализованы они были через одно всем известное место, благодаря чему никаких серьёзных программ с использованием логики и поразрядного сравнения сделано не было. Кроме игровых, где они использовались для видеосообщений (были также попытки использовать их в шашечных программах для кодирования позиций, но занятый восьмеркой старший разряд мешал).

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

Интересно. Кстати, интересно, хоть одна такая программа для ПМК была? Всё-таки использование логических функций ПМК даже в восьмеричном коде - занятие нетривиальное.

Если бы в ЭКВМ поддерживались логические операции с данными более 8 двоичных разрядов - а такие варианты рассматривались - можно было бы составить аналогичную приведённой программу. Впрочем, Русскому и иже с ним неизбежно понадобились бы операции с Nmax+1 разрядом. :)

Из изданного «Кстати, интересно, хоть одна такая программа для ПМК была? Всё-таки использование логических функций ПМК даже в восьмеричном коде - занятие нетривиальное.»

Из опубликованного я могу вспомнить лишь «Пещеру сокровищ» (ТМ №7/87)
http://pmk.arbinada.com/node/150

Но в КЛК и на сайте LordBBS я встречал несколько самоделок.

«логические операции с данными более 8 двоичных разрядов - а такие варианты рассматривались»

Меня тоже возмущает ограничение 8 битами. Понятно, что для внутренних структур данных ЭКВМ больше и не требуется. Но в задачах (той же «Пещере сокровищ») большее число бит не редкость. Как и востребованность шестнадцатеричного ввода/отображения чисел в режиме F АВТ, арифметики и т.п. Надеюсь, что при разработке ЭКВМ с типами данных и «бесконечным» стеком эти ограничения снимут.

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

Кроме того, установка разрядности всё равно потребовалась бы для корректной работы команды инверсии. Но изменение способа выполнения основных команд ЭКВМ в зависимости от установки дополнительных функций является неправильным подходом.

Поэтому, как обычно, использован компромиссный вариант. Обратите внимание на функции 9100 и 9103.

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

К ИНВ. Инверсию можно оставить 8-битной. Она легко имитируется K XOR'ом с маской нужного размера — гораздо легче, чем реализация многобайтовых логических операций через 9100/9103 и универсальный буфер.

Если доводить до ума логические функции, имеет смысл также предусмотреть побитовые операции над дробной частью. Например 2,5 XOR 6,25 = 4,75 ($2,8 XOR $6,4 = $4,c). Результат, не укладывающийся в разрядную сетку (1 ВП 50 XOR 1), должен вызывать авост.

Впрочем, выбранная bcd-реализация регистров стека делает полную реализацию логических функций не таким уж простым делом.

Зачем оно мне? Увидев значок (+) на калькуляторе, я несколько соблазнился мыслью о возможности написания криптографической программки, ибо раньше таких не видал. Поняв, что использование этой функции не так просто, как хотелось бы, я несколько разочаровался, но изначальные наработки в этом направлении было жаль выкидывать. А решил я выбрать для реализации алгоритм ГОСТ 28147-89, точнее говоря, основной шаг криптопреобразования (соответственно, метод простой замены). На текущий момент после многочисленных актов оптимизации имею такой вот код.

Ввод происходит двухбайтовыми разрядами. Открытый текст располагается в регистрах Р4 - Р7, причём Р7 - самый младший, а Р4 - старший разряд. После пуска программы вводятся разряды ключа, сперва старший, потом младший. После этого вводится элемент таблицы замен с номером строки, идущим по порядку (от 0 до 7) и номером столбца, указанным на индикаторе. Кроме того, изначально забиваются числа: РB = 16; РC = 32; РD = 2048; РE = 65536.

Итак, прибавление ключа по модулю 2^32.
ИП6 С/П + П6 ИП7 С/П + П7 ИПE -
x>=0 14 П7 КИП6 ИП6 ИПE - x>=0 20 П6

Замена 4-битовых блоков:
8 П2 П3 2 П1 4 П0 0 П8 1
П9 КИП2 ИПB / [x] ПA Вх {x} ИПB *
С/П ИП9 * ИП8 + П8 ИП9 ИПB * П9
ИПA L0 32 ИП8 КП3 L1 25

Циклический сдвиг на 11 битов в сторону старших разрядов:
8 П0 ИП7 ПП 94 П1 ИП6 ПП 94 ИП5
+ П6 ИП1 ИП4 + П7

Подпрограмма на адресе 94 для этого циклического сдвига:
ИПC / [x] КП0 Вx {x}
ИПC * ИПD * В/О

Как полагаете, есть ли шанс впихнуть в оставшиеся шаги программы исключающее ИЛИ и обмен младших и старших 4-байтовых блоков текста?

Вообще то перестановка левого и правого 32-х разрядных слов уже не относятся к элементарной функции шифрования, а относятся к сбалансированной сети Фейстеля.

Мои программируемые калькуляторы:
Б3-21, Б3-34, МК-61, МК-52, МК-85
CASIO: cfx-9850GB+, fx-9750G+, fx-9750GII, fx-9860G, Algebra fx-2.0, fx-5800P, fx-7400G+
HP: 50G, 48G, 35s
TI: Nspire-CAS, Voyage-200, 89Titanium
SHARP EL-9600G

Ну так основа алгоритма шифрования по ГОСТу - она и есть.

И зачем > "соблазнился мыслью о возможности написания криптографической программки, ибо раньше таких не видал"

Вот, например: http://pmk.arbinada.com/node/670

Не говоря про существование специализированных моделей, таких как МК-85Б/МК-85С.

Загнать не самый простой криптографический алгоритм в память ПМК - это, конечно, сурово. Примерно так же, как подметать плац зубными щётками или убирать снег ломами. Но почти так же эффективно.

ПМСМ, гораздо разумнее переписать программу для ЭКВМ: оно было бы и проще, и не впустую. Особенно, с учётом сущестования в устройстве раздельных областей памяти для текстовых и двоичных данных. ;)

DemosceneДело не в разумности, а в массовости и культовости платформы. МК-61 - массовая и культовая, в отличие от ЭКВМ. Криптография на МК-61 - это как отличное demo на ZX Spectrum.

---------------------------
Истина где-то рядом
aldebaran.ru/author/samurov_vitaliyi/kniga_dozvonitsya_do_devyi/

Именно так, Вы абсолютно правы.

Кому в голову придёт писать под эти самые "ЭКВМ", когда можно взять любой язык программирования ПК и не морочить себе голову, если на то есть нужда? А вот МК-61 - это мощь.

Кстати. Даже если ориентироваться только на ПМК, не обязательно загонять алгоритм в оставшиеся шаги программы.

Существуют программы для ПМК, которые состоят из нескольких частей, а данные между ними передаются в регистрах. На МК-52 эти части даже перенабирать не придётся - достаточно вызвать нужную из энергонезависимой памяти. Если двумя частями не ограничиваться, пожалуй, и полный алгоритм войдёт.

Вы правы, но проблема в другом: основной шаг ГОСТ 28147-89 рассчитан на многократное повторение. Т. е. вся программа есть итерация цикла, и в её конце подразумевается возврат к началу.

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

В конечном итоге остаётся 9 свободных шагов программы.

ИП6 С/П + П6 ИП7 С/П + П7 ИПE -
x>=0 14 П7 КИП6 ИП6 ИПE - x>=0 20 П6
8 П2 П3 2 П1 4 П0 0 П8 1
П9 КИП2 ИПB / [x] ПA Вх {x} ИПB *
С/П ИП9 * ИП8 + П8 ИП9 ИПB * П9
ИПA L0 32 ИП8 КП3 L1 25 8 П0 ИП7
ПП 94 П1 ИП6 ПП 94 ИП5 + П6 ИП1
ИП4 + П7 .. .. .. .. .. .. ..
.. .. ИП4 ИП6 П4 <-> П6 ИП5 ИП7 П5
<-> П7 БП 00 ИПC / [x] КП0 Вx {x}
ИПC * ИПD * В/О

Запихать бы туда что-то типа ИП4 ИП6 (+) П4 ИП5 ИП7 (+) П5...

С/П. Да запросто: "ИП4 ИП6 С/П П4 ИП5 ИП7 С/П П5".

После промежуточного останова - просмотр регистров X и Y через <-> и ввод данных в X по таблице, любезно прилагаемой автором к описанию программы. :)

Два ПМК. Если задача не решается на одном ПМК — можно взять два ПМК. И по мере того, как один выдаёт данные для расчёта, второй производит этот расчёт.

Но вообще все эти задачи, превосходящие по вычислительной мощности ПМК, в лёгкую решаются на современных ЭКВМ. Так и поступит тот, кто не русофоб, стремящийся загнать всю страну в лапти и деревянные дома. :)

В целом любовь к предкам — достойное дело. Но лишь если она учит хорошо относиться к тем русским людям, что живут здесь и сейчас. И тем, кто будет жить после нас. Любить трупы просто, а вот хотя бы просто поддержать живого, тут уже самому надо не быть трупом. Когда мы сами станем предками для будущих поколений (такими же, как изобретатели ПМК для нас), история расставит всё на свои места. Кто помогал, а кто мешал.

Два калькулятора - хорошая идея. В принципе, при нехватке ресурсов есть два пути: вычислительный бланк или использование нескольких модулей. Вычислительный бланк в этом случае - не слишком приемлемый вариант, ибо и так с таблицей замен и ключом придётся сидеть. Если действительно нельзя как-нибудь хитро вместить код с "исключающим или" в программу, то придётся делать так.

> Любить трупы просто, а вот хотя бы просто поддержать живого

> такими же, как изобретатели ПМК для нас

Ну Вы и сравниваете... МК-61/52 и ваши ЭКВМ... Слона с блохой. Зачем нам любить живую блоху, когда у нас целый труп слона есть? Пусть даже он уже не очень-то и шевелится, но всё ж наш, родной, не китайский и не американский, в отличие от блохи.

Ретроградство. Комментарий был перемещен и теперь находится здесь.

Нехилая табличка будет со стороной в 65536 значений...

Разумеется. Но разве это может остановить истинного любителя слонов? :)