Полигон-2

о, спасибо!!!

так, я понял — посмотрю внимательно п. 8
похоже, для этой части надо логику поменять

В общем, пока ехал домой, разобрался, что к чему.
Симулятор я переделал... но не в сторону к Б3-23, а, наоборот

Получается, что в к145ип11 всего четыре регистра (в общем то, я так и думал изначально):
1. Регистр первого операнда, он же - регистр клавиатуры/индикатора
2. Регистр второго операнда, он же - регистр константы (в операциях с константой)
3. Вспомогательный регистр для операций умножения и деления. Точно не могу знать, но он либо формирует (накапливает) в себе произведение/частное, либо удерживает множимое/делимое
4. Регистр памяти (доступен только в Б3-26, МК-57)

В процессе выполнения операции деления, например 200 / 40 =, делимое (200) уничтожается, т.к. из него в цикле вычитается делитель (40), пока в регистре делимого в остатке не окажется 0 (ну или пока счётчик сформированных разрядов частного не досчитает до 8). Делитель же (40) в процессе деления сохраняется, и далее служит константой.

Когда мы вычисляем обратный процент, например 10 / 5 %, в сущности необходимо выполнить деление 10 / 5 (в ответе 2) и потом подвинуть запятую на два разряда вправо (чтобы получить искомое 200). Сотвесна, делимое (10 - база) уничтожается, а делитель (5 - ставка процента) становится константой... Нажимать после этого клавишу = лишено всякого смысла, конечно же.

Сейчас у меня реализована другая логика. Константой становится не ставка процента, а база для вычисления процентов. Это необходимо в операциях вычисления наценки/скидки (например, 200 + 5 % =). Но правильно ли делать константой базу при вычислениях процентов (но не наценки) — это вопрос.

Хммм... наверное, всё-таки логика, реализованная в Б3-23, более правильная, т.е. при вычислении просто процентов (но не скидок) константой должна становиться именно ставка процента. Если в калькуляторе при этом есть M-регистр, то это позволяет вести расчёт суммы налога по ведомости. То есть типа такого: 200 * 13 % M+ 207 % M+ 204 % M+ ... — в итоге даст 200 * 13/100 + 207 * 13/100 + 204 * 13/100 ... Хотя, не понятно, какой смысл вести расчёт именно так, если можно так: (200+207+204) * 13/100

Логика, реализованная у меня, позволяет, наоборот, вычислять разные проценты от одной и той же базы. Например, 200 * 5 % (даёт 10), далее 6 % (даёт 12) и т.д.

Логика, которую я реализовал в симуляторе, в к145ип11 в любом случае не влезла бы, т.к. для её реализации требуется пятый регистр — в нём необходимо запомнить базу (10) на время выполнения операции деления, чтобы потом восстановить это значение как константу (делимое в процессе деления разрушается). Так что, в случае с настоящими калькуляторами ответ на вопрос, какую логику выбрать, был предопределён чисто соображениями минимализма "железа".

В общем, надо ещё поразмышлять, какой вариант лучше/правильнее.

---

... в общем, подумал, и сделал два варианта:
1. в точности, как у Б3-23
2. как у Б3-23, но улучшенный

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

итак, первый вариант в "примере 8", как и положено, возвращает 111.11111 — хотя это и совершенно бессмысленная операция, но пусть будет "в точности как Б3-23" — просто в дань уважения

во втором варианте я попытался наделить "нажатие клавиши =" в операциях вычисления прямых и обратных процентов каким-то вразумительным смыслом, а именно:
- если ввести 200 * 5 %, то, как и положено, получаем 10 — но далее, если нажать =, то теперь получаем обратно 200
- по аналогии, если ввести 10 / 5 %, получаем, как и положено, 200 — и далее, если нажать =, то теперь получаем обратно 10
- в общем, в обоих случаях клавиша = выполняет действие обратное клавише %
- действия можно чередовать % = % = и т.д.
- в остальном логика не изменилась
- в операциях вычисления наценки/скидки функция клавиши = не менялась, но осталась как у Б3-23

Ну, вроде, на этом всё.

Поправил логику процентов — updated-комментарий выше. Код перезалил, ссылки на проект обновил.

Статистика:
1. Код симулятора занимает 560 строк
... если убрать декларации, пустые строки, и строки-со-скобочками, то чистого кода будет где-то около 300 строк
2. На написание и отладку собсна симулятора я потратил период времени с 09 октября по 23 октября — это ровно 2 недели
... чистого времени - где-то в среднем по 3-4 часа в день, в расчёте 2 дня из трёх — т.е. итого около 30-40 человеко-часов

Даже если положить, ну, пусть хотя бы по 3 байта машинных команд в среднем на одну строку Си-шного кода (а это очень скромная норма), то выйдет, оценочно, около килобайта кода!
... и это ещё при том, что я НЕ реализовывал извлечение квадратного корня, работу с регистром памяти, ну и пр. мелочёвку, которые есть в к145ип11.

Ума не приложу, КАК это было впихнуто в к145ип11...

Но что для меня непонятно, каким образом инженеры это всё сделали в 70-х годах прошлого века.
У меня для этой работы был современный компутер, на котором работать - удовольствие.
И это я сделал ещё всего лишь симулятор, т.е. я не запихивал этот код в мягко-говоря-своеобразную архитектуру микро-ЭВМ 145ип11.
Либо у них тогда на это ушло реально на пару порядков больше сил и времени, либо у них был какой-то технологический секрет (суперкомпутер??), либо... эти люди были на самом деле оооочень талантливыми.
// я не знаю, кто разработал прошивку для конкретно 145ип11, — может наши сделали это сами, а может скопировали у американцев (вроде был такой чип Rockwell A5901 — http://www.arithmomuseum.com/a...ang=en)... но ведь кто-то же это изначально сделал

---

MM, надо делать железку!

MM написал:

[q]

ИМХО, по аналогии с Паскалем, порядка 20 байт ( 10-14 ( 8 ) слов ) на 1 оператор Паскаля, с точностью переменных 2 байта.

[/q]

... я брал оценку "3 байта на строку" — это не для системы команд PDP-11, а так, чисто абстрактно — в плане "как это вообще могло вместиться изначально в 145ип11"
для PDP-11, боюсь, имеющийся у меня Си компилятор даст ооочень много байт на строку — вряд ли он умеет хорошо оптимизировать выхлоп — много будет "накладных расходов" на прологи/эпилоги функций


MM написал:

[q]

Текст на ассемблере следует заранее писать в перемещаемом по адресам варианте.

[/q]

да, я понимаю — это типа когда для работы с переменными (не со страницей В/В) используются инструкции с режимом адресации 6 и 7 — например, 010067 XXXXXX, где XXXXXX - смещение — вместо того, чтобы использовать 010037 AAAAAA, где AAAAAA - адрес... и когда всякие вызовы подпрограмм и дальние переходы тоже идут с режимом адресации 6 и 7

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

хммм....

какой из двух взять?:
- http://zx-pk.ru/threads/18351-emulyator-dvk.html
- http://zx-pk.ru/threads/24755-emulyator-rt-11.html
// вторая ссылка, вроде, более свежая (по дате) — начну с неё