Уважаемый читатель.
В прошлый раз я рассказал тебе как компьютеры складывают и вычитают. Теперь настала пора объяснить тебе как они умножают и делят.
И вот тут между нами и американцами появляются серьёзные различия (про разную форму представления чисел в компьютерах СССР/РФ и США я уже писал)
Как умножают советские/российские компьютеры.
В прошлой своей статья я тебя, Читатель, "немножко обманул": компьютер изначально умеет не только сравнивать числа в своих математических регистрах X и Y, но и сдвигать там информацию этих чисел по разрдам "влево" и "вправо". Операция эта называется "логический сдвиг" и может быть ЛС← или ЛС→ .
Что происходит с числом в двоичном виде, если биты в нём сдвигают влево с математической точки зрения? Оно умножается на 2. Соответственно если оно сдвигается вправо - то оно нацело делится на 2 (если число чётное и его последний бит =0 - то это будет абсолютно точно).
Итак, в процессоре ЭВМ в двух математических регистрах находятся числа:
Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰ и Y⁷Y⁶Y⁵Y⁴_Y³Y²Y¹Y⁰
и их надо перемножить
Как я уже рассказывал у процессора есть свой "внутренний" регистр Z. Но по нему для процесса суммирования будет гоняться "1" по разрядам и поэтому нужен ещё один "рабочий регистр" Σ. Там мы будем хранить "временную информацию" (для точно результата без переполнения там нам мало 1 байта, надо уже 2. Соответственно и в регистре Х нам уже мало 1 байта)
. Σ⁷Σ⁶Σ⁵Σ⁴_Σ³Σ²Σ¹Σ⁰_ᛊ⁷ᛊ⁶ᛊ⁵ᛊ⁴_ᛊ³ᛊ²ᛊ¹ᛊ⁰
Алгоритм умножения :
1 Если Y⁰=1, то складываем Σ и Х, оставляя сумму в Σ. Если Y⁰=0, то этого не делаем.
2 Логическии сдвигаем Х влево, тем самым умножая его на 2.
3. Логически сдвигаем Y вправо, тем самым деля его на 2. (бит Y⁰ мог хранить и "1", но мы этот бит уже обработали и нам это уже не важно)
4. Снова проходим пункты 1-3 до тех пор пока в Y остаётся хоть один ненулевой бит
То есть мы "столбиком" умножаем Х и Y, тем самым "школьным способом":
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Y⁷Y⁶Y⁵Y⁴_Y³Y²Y¹Y⁰
. —————————
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. ——————————————————
. Σ⁷ Σ⁶ Σ⁵Σ⁴_Σ³Σ²Σ¹Σ⁰_ ᛊ⁷ ᛊ⁶ ᛊ⁵ ᛊ⁴_ ᛊ³ ᛊ² ᛊ¹ ᛊ⁰
То есть умножая Ц1 на Ц1 - мы получаем Ц2. Возникает "переполнение" и пл сути нам нужен лишь младший брат этого Ц2
Вот так советская/российская ЭВМ умножает.
А как она делит? "Рисует" такую же "лесенку"', где под ней не складывает, а вычитает сдвигаемый вправо Х:
Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰. |
. | Y⁷Y⁶Y⁵Y⁴_Y³Y²Y¹Y⁰
. —————————. |
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. Х⁷Х⁶Х⁵Х⁴_Х³Х²Х¹Х⁰
. ————————————————
. Σ⁷Σ⁶Σ⁵Σ⁴_Σ³Σ²Σ¹Σ⁰_ ᛊ⁷ ᛊ⁶ ᛊ⁵ ᛊ⁴_ ᛊ³ ᛊ² ᛊ¹ ᛊ⁰
Мы конечно же в школе рисовали почти такую же "лесенку", со сдвигом вправо, только результат деления писали не внизу, а под Y вверху.
С нашими ЭВМ теперь всё понятно. А вот как это делают американцы и почему это к них получается гораздо быстрее и красивее?
Как умножают и делят американцы свои числа, записанные "задом наперёд?
У американских ЭВМ числа на регистрах будут выглядеть так:
Х⁰Х¹Х²Х³_Х⁴Х⁵Х⁶Х⁷
Y⁰Y¹Y²Y³_Y⁴Y⁵Y⁶Y⁷
Алгоритм умножения*:
1. Сдвигаем Z вправо
2. Если Y⁷=1, то Х⁷ переносим в Z⁰, если Y⁷=0, этого не делаем
3. Сдвигаем Х вправо
4. Сдвигаем Y вправо.
5. Повторяем пункты 1-4, перебирая все разряды Х.
Вы видели в этом алгоритме хотя бы одно слово "складываем"? Нам для этого нужно иметь Z не в один байт, а в два? У "американца" тут может быть "переполнение"?
Вот поэтому-то американские процессоры ЭВМ и умножали/делили раз в от 8 до 64 быстрее, чем процессоры, изготовленные в СССР.
... и теперь тебе не сложно будет самому написать алгоритм деления на американском компе.
* - проверил. Этот алгоритм работает только для чисел от 0 до F. У более крупных цифр возникает эффект "переполнения полубита" и его надо учитывать. Скорректированный алгоритм смотри в мое́м комменте с КАР13
@Маэстро
13.05.24
Комментарии
Не зря значит Хрущев на кибернетиков наезжал
Там было веселее: не могли договорится про бит, а про байт вообще речи не шло.
Жжоте, попробуйте вторым методом реально что-то умножить))
Ошибку я уже исправил... Вы слишком поторопились прочесть паблик и выразить своё "не согласен!" 😆
Ты, наверное, ФизМат закончил? За первые минуты паблик посмотрело человек 300 и только ты заметил в нём "ошибку". 🤔😉👍
Как американцы....))
Спасибо, повеселил.
А у меня почему-то видео не получается вставить. Как???
... не... опять наврал... щас придумаю - как они умножают... 🤨🤔
Придумал!
М=0 - маска "переполнения" полубайта числа
1. Если М=1, то Z⁷=1 и его ЛС вправо
2. Если Y⁷=1, то. если М=0, то Z⁰=X⁷
. если М=1, то Z⁰=¬Х⁷, М=0
3. Сдвигаем Х вправо
4. Сдвигаем Y вправо
5. Сдвигаем Z вправо
6. Обрабатываем следующий полубайт числа, выполняя 1-5
7. Если М=1, то Z⁷=1
Проверяй! ... по крайней мере для Ц1*Ц1 это работает
Этот механизм я придумал ещё в 90-ом году когда программировал на АссМ13. Только на том советском компе я "работал " с битами ⁷ , перенося Х⁷ в Z⁰ и потом сдвигая Z влево. Я не знаю каким способом умножали в ОС М-13, но после переопределения операции "*" - моя программа "41" стала исполняться на 10% быстрее. Кажись, потом её спецы НИИ-ВК ввели в свою ОС для всех пользователей ЭВМ радара.
...
А как у нас нынче в Си++ умножают?
Машина М13 не должна была знать про байты, как и прочие советские машины, у них - машинные слова.
Самые массовые советские машины знали и про байты, и про биты, и про слова, и про двойные, и про четверные. А ЕС знала даже про полубайты ;)
Чисто же про слова - это на БЭСМ-6 кончилось.
Это вы мне будетеирассказывать про М-13? Дамя уверен, что в те годы знал про неё лучше, чем её разработчики из НИИ-ВК... Про её адресные, математические регистры и маски Битов я знал всёидоскональноиуче через месяц послеиначаламработы с ней. Несмотря на то, что машина эта оказалась, прямо скажем, хер&вая, но она украшала внутреннее убранство башни приёма сигнала.
Какие "машинные слова? В конечном счёте пришлось выучить старые добрые "машинные коды"- в них зачастую и программировали.
Или вы имеете в виду машинные команды, длиной 1,2 или 3 "4-х-байтных слова"
Уважаемый, если вы "своим" алгоритмом "без сложения" пошагово распишете умножение хотя бы 1010 на 0101 и получите правильный результат - я признаю что он работает и выражу вам уважение.
Должно получиться 110010
Coгласен. Бред.
Умножаем 10 = 0101 и 5=101 (am) должно быть так
. 0101
. 101
. ———
. 0101
. 0101
. ————
. 010011. =50 (am)
теперь надо подумать... Там ты прав - я 5 строку из паблика в коммент не перенёс
При переносе в Z там где 1+1 возникает "переполнение бита" и нам надо
1. сменить полярность уже накопленной информации
2. сменить полярность переноса бита из Х⁷ в Z⁰
3. Взвести маску обратой смены полярности последнего полубайта после его накопления
Правильно?..
Нет!
1. Занести Z⁰=0. Пробежаться к старшим разрядам, меняя 1 на 0 пока не впишем 1 вместо 0
Перейти к следующему разряду накопления сдвигая Х и Y вправо и Z /тоже
Напишите на любом языке или псевдоязыке. Или алгоритмической схемой-графом.
Вот, блин, я с тобой посоветоваться хочу, а ты заладил: дай мне алгоритм и ч его проверю, умножая 5х10. Проверить его я и сам могу. В тесте коммента есть ошибочно забытая строка "5" - там где перебираю все 4 бита полубайта.
Ща кофе попью, подрихтую...
Да у нас 3-х летние дети уже правильно отвечают на этот вопрос. Хотя по "всем правилам образования" детей полагается обучать этому только лишь в 1-ом классе начальной школы. И вы абсолютно правы. Поэтому посмотрите небольшую рекламу:
А теперь продолжу свой паблик. Итак, как я узнал сколько будет 2х2.
Похоже я сам себя запутал. Нафига мне этот "американец", если я тот "Мультиплекс" писал для российского компа. Начинаем сначала по выданным тобой данным:
. 1010
. 101
. ———
. 1010
. 1010
. ————
. 110010 =50
И мне надо вспомнить тот алгоритм 89-го года. Попробуем...
Вспомнил свой метод с большим трудом. Ищи ошибки - только похоже что их там теперь нет:
https://aftershock.news/?q=node/1378788#new
Спасибо за найденные ошибки и советы.
Не понятно что Вы имеете ввиду под "американцы записывают числа задом наперед".
Типа как в память 16-битное слово сначала сохраняет младший байт, затем старший? Little-endian? Но внутри этих байт биты все равно нумеруются справа налево, т.е. 7-0, 15-8, но не 0-7, 8-15!
В советских ЭВМ в числе: крайний бит справа - младший разряд 2⁰ при любом Ц1, Ц2 или Ц4
в "американцах" : крайний бит справа - старший разряд 2⁷ при Ц1
. - старший разряд 2¹⁵ при Ц2
. - старший разряд 2³¹ при Ц4
В каких советских ? Назовите модели, где так.
В каких американских ? Назовите модели (архитектуры), где так.
Вы вообще, кроме интеловских процессоров, хоть с чем-то знакомы ;)
Советские - это у нас были наши Агаты и М-13. Естественно, что во внутренности наших ЕС я не лазал.
Американские - это все "персоналки", начиная с Эппл, которые к нам в СССР завозили
Ну так залезьте в американские IBM/360/370/systemZ, или в американские же PDP11 или VAX780. Откроете для себя много нового. После этого уже ничего нового в ЕС и СМ для вас не будет :)
Я уж не говорю об советских Минсках или БЭСМ.
Особенно интересно будет десятичное представление данных в упакованном и распакованном формате.
Всё намного многообразнее и сложнее. И да, все эти операции придуманы и продуманы до нас. Задолго. Ещё в начале 60-х годов.
Вот пожалуйста про "упаковки" не надо... Прошу... Я а 89-ом на них свой геморрой и заработал...
НИИ-ВК нам обещало, что уже через полгода летом 88-го оно окончательно соберёт на Балхаше для тестирования свой первый суреркомп М-13. Поэтому в мае 88-го программисты ЛПТП уехали на 9-ку "осваиваться". Многие в том числе и я "осваивали" М-13 уже полгода. Хрень а не работа выходила: у нас были рроги, отлаженные на яимиьаторах М-13, а эта дура никак не хотела работать "как имитатор". То видите ли у неё "конвейер" сбоит (из-за этого она начинала выполнять нижерасположенные в коде команды ранее располагавшихся выше - лечилось вставкой кода перехода "туда-сюда") то видите ли рвгистры АМ (адресных манипуляций) не слушаются выдаваемых на них команд .(лечилось по-разному). То видите ли конвейер на мат.регистрах R1-R6 уложен программистом "нестандартным способом" (из за чего в них не "складывали/умножали" а выясняли "кто тут самый главный/умный" из них длинных - и это в лучшем случае. В худшем они начинали сравнивать свою 256-байтную длину с ... "физическими параметрами" своего программиста - и нам мужикам было нечего им возразить.
Короче... Нет, длиннее... Нет. Примерно...
... Блин, тут я уже без всяких намёков рассказываю. Вот, просто: через примерно полгода мы эти рабочие трудности преодолели. Платы компа, запутавшиеся в многочисленных "временных проводках" были заменены на "усовершенствованные заводские". И мы ждали время на "супереомпе" с вожделением. Но оказалось, что нас программистов опять накололи:
1. Нам обещали 32 Мегабайта ОП, а предоставили всего 8.
2. Нам обещали "виртуалку - ГДЕНИБУДЬку" а дали "Физичку-неподвижку".
Многим пришлось даже тексты свои переписывать (не мне - папа Миша знал про такиеиеосчеи предыдущей М-10)
3. Из "щедрых 8 МБ (один из ни забирала сама Операционка и еще́один использовался как буфер между аппаратурой и ПОФ-процессор обработкиифункций, который для меня делал быстрые преобразования Фурье) моему "41" Обнаружению дали целых 2 МБ (треть памяти для разных программ БЗ, Помехи, Ионосферы, Дальней Связи, ДОСа, Имитатора, и ещё каких-то 3-х комплексов). Но мне всё равно было МАЛО. Я сократил количество траекторий до 320 вместо начальных 512), я ужался в нескольких ввжных "характеристиках траектории", но все равно не влезал. Тогда я решил не хранить параметры траектории в отдельных. ячейках типа П, Ц4, Ц2 и Ц1. А брать только "значащие биты" в этих ячейках и формировать одну "Строку Битов, чтоб хранить в памяти одну её. Суммарную "длину информации о цели" удалось сократить почти в 2.5 раза! Но при каждом запуске "41"-го я сперва распаковывал эту строку в информацию формата П, Ц4, Ц2, Ц1, Бит, СтрБитов". А после окончания работы программы "41-го, зпапковывал её обратно.
Нет, распакованный и упакованный форматы это совсем не про то. Это способ представления десятичного (не двоичного !) числа. Распакованный - это просто шестнадцатеричная кодировка цифры, занимающие один байт. Можно выводить на печать без всякого форматирования ;)
Упакованная - в байте каждый полубайт (4 бита) используется под кодировку одной десятичной цифры.
Это всё для экономических расчетов, не для научных.
И да, мэйнфреймы IBM как и советские ЕС могут выполнять арифметические действия прямо над десятичными числами, без преобразования в двоичную форму. Это существенно медленнее двоичных операций, но зато сильно экономит время на форматных преобразованиях. Иногда это важно.
Ах, да, про все персоналки начиная с Эппл. Я и забыл про чудо-машины DEC Rainbow и DEC Profissional. Я на Profissional даже UNIX как-то поставил, с 10-мегабайтным-то диском. Толку мало, но ведь получилось же. Да, процессор там был LSI11.
С Линуксом мне пришлось столкнктьсямужеив 06-ом на том же ОКяБ Карат.
Я тогда вернулся туда и мне предложили на выбор 2 работы. Либо с Виталиком пишуирроги для новых Воронежей. Либо я работаю на ВМФ и разрабатываю им Глобальную Систему Передачи Данных. Я решил, что Виталик справится без моей помощи (он ранее чуть ли не за год написал свои Винды для ворованного в США Крея - его ведь спёрли только с Домом. Вот дурак! Кто то из америкосов на этом мультимиллионером стал!) И решил потрудиться на военных.
Главный инженер ОКБ Миллер поручил мне писать под Винды на Си++. Но я ж не вчера родился - знаю что там Хрен знает что в их Виндах. И военные ни за что не согласятся на них работать - отключат из Америки их легко "по нажатию кнопки". Полистал Инет и выяснил, что писать на Си++ надо под GNU. - и тогда прога легко встанет и под Винды и под Линукс.
А общем, за полгода я написал "демонстрационный вариант ГСПД". И потом ещё месяца 4 его отлаживал и игрался с ним. (Хочешь посмотреть?)
К сожалению выяснилось, что нам4 этап работ Заказчик не согласен. То ли потерял интерес, то ли деньги потерял, то ли нашёл другого исполнителя. (Лично мне кажется, что он потерял Совесть - запросил 15% отката вместо согласованных ранее 10%) И в итоге он ничего нового для себя не нпшёл. - такой системы в ВМФ нет и поныне (а ведь прошло уже 18 лет)
Бог с вами, какой ещё Линукс в 88 году. Самый что ни на есть кондовый Юникс версия 7, который в книжке Борна описан. Без всякой виртуальной памяти и пейджинга. Вполне работоспособен был на машине PDP11 с 64 килобайтами (!!!) памяти.
Т.е. число 128 хранится в памяти как 00000001?
Тогда для "американцев" получается строго наоборот - сдвиг влево эквивалентен делению 2.
1. Да
2. Да
Нет, компьютеры работают не так.
Умножаю они так:
https://en.m.wikipedia.org/wiki/Dadda_multiplier
Часто с https://en.m.wikipedia.org/wiki/Booth%27s_multiplication_algorithm
Для ускорения обработки знаков.
Твой первый коммент я удалил за твою наглость. Если ещё раз повторится - выкину отсюда все твои комменты
Ну не знаю... Я глянул туда через Гугл транслейт и ни-чер-та не понял.
Может и на прогах ОС М-13 такой механизм был сделан. Только вот после моего перехода на "мой метод" моя прога "41" стала работать на 10% быстрее, хотя там операций умножения практически не было - все "обработки радиолокационного портрета" были сделаны исключительно на "логике". Экстраполяция траекторий - вот там я умножал. Это значит, что я раз в 1000 ускорил прогу из Операционки.
В какой последовательности лежат байты в памяти с точки зрения арифметики и логики не имеет никакого значения. Это синтаксис и работы инструкций загрузки из памяти.
С деление все намного печальнее. Для плавающий точки, используется приближенные алгоритмы
https://en.m.wikipedia.org/wiki/Division_algorithm#Goldschmidt_division
и подобные производные ньютона-рапсона с рзными вариациями таблиц инициализации. Для целых чисел, блоковые алгоритмы.
Там вся проблема была в загрузке "внешних данных" при использовании "американцев" у нас. Вот когда в 06-ом я увидел "ворованные через 5-е страны Креи" - то удивился очень неэстетичной "коробочки на шлейфе". Оказалось, это наши мудрецы придумали и спаяли: перед загрузкой в Крей все "русские цифры" надо "перевернуть" мадшими разрядами вперёд. И тогда всё работало правильно.
Не знаю что там с "плавающей" точкой. Я научился так умножать все Форматы.
Кажется, я степени складывал, а "цифирьки" из набора считал форматом Ц4 и перемножал "логикой". Естественно, что все "младшие разряды" числа формата П терялись.
Порядок записи не имеет значения, железо никогда не вычисляло столбиком, операция сдвига была известна не только американцам.
Примите душ - и прочие и мой паблик и мои комменты под ним с новым ясным содержимым головы
Извините, но Вы абсолютно не в теме.
То, что Вы описали является ПРОГРАММНЫМ способом реализации, который мог бы быть применен на самом раннем этапе становления компьютерной техники - к примеру на микропроцессорах i8080/580ВМ80 (1974/1977 гг).
Начиная с i8086/1810ВМ86 (1978/1986 гг) операции умножения/деления уже выполняются на АППАРАТНОМ уровне.
Различия между программной и аппаратной реализацией заключается в том, что в первом случае алгоритмы реализуются ПОСЛЕДОВАТЕЛЬНО, а во втором - ПАРАЛЛЕЛЬНО.
Причем, с каждым поколением, аппаратная часть модифицировалась, что прямым образом отражалось на времени выполнения этих операций.
Поэтому, со своими "объяснениями" Вы опоздали лет на сорок с гаком.
А вот этот вот бред: "Вот поэтому-то американские процессоры ЭВМ и умножали/делили раз в от 8 до 64 быстрее, чем процессоры, изготовленные в СССР" лишь характеризует Вас как полностью оторванного от тематики "компьютеро-/процессоро- строения".
Я не знаю, что там происходит на "программном" и "аппаратном уровнях".
Я видел содержимое только "суперкомпа М-13". Когда у нас на "отлаженной на имитаторах М-13" прогах вдруг возникала ошибка, то мы первым делом звали представителя НИИ-ВК и несколько часов пытались понять "что и почему там во внутри их железяки" правильно работать не желает. Часика за 2-3 причину затыка мы находили и устраняли "программным способом" А ВКшник потом неделю голову ломал - как это можно исправить "аппаратным способом". Потом он брал паяльник и прокладывал навесом по платам АЛУ или ОПГ или ещё каким другим сотню-другую проводов и просил нас отключить "программное ухищрение" . Иногда у него получалось с первого раза ..а иногда лишь с десятого.
По поводу твоей иронии про "полностью оторванного от реальности программёра" могу сказать лишь одно. Вернее повторить: после переопределения для своего "41" комплекса функции "Х" (умножение)- то есть я отказался от аппаратно-программного метода умножения ОС М-13 и заменил его на свою херню-программу "Мультиплекс" - комплекс стал работать на 10% тактов М-13 меньше.
Помнится , ему требовалось при "небольшом количестве траекторий" от 4 тыс. до 10-20 тыс. тактов
Просто ваш опыт получается очень специфичен и ограничен достаточно редкими архитектурами.
Спасибо за ваш вопрос. Отвечая на него я написал ещё один свой паблик.
Из его прочтения вы поймёте, что "старые редкие архитектуры" на самом деле - это весьма возможные "продвинутые технологии будущего".
Вот давайте представим: летит космолёт землян на Альфу-Центавру. И у них вдруг ломается компьютер - то ли кто-то случайно отвёрткой плату с математическим процессором ковырнул, то ли они свой "нейтронный бластер" ненароком направили на комп, то ли неподалёку рванула очередная звезда. Не важно. Но в результате этого ЧП "проводок" в аппаратном ускорителе рвётся/плавится, процессор накрывается, комп останавливается. Что делать? Поворачивать обратно на Землю? Вы ответите: "Не порите горячку - у них всегда будет запас плат/микросхем, которыми они быстро отремонтируют свой звездолёт!" Но у меня есть такие возражения:
1. А если тот "камешек", что попал в корабль - расфигачил весь тот отсек где хранились микросхемы для ремонта аппаратуры?
2. Амесли нет того "специалиста" - ккоторый сможет быстро найти и заменить покрорёженную микросхему?
3. А если этотому специалисту надо часов 5-10, чтобы выяснить - какой именно "проводок" погорел из-за взрыва "новой звезды" неподалёку, а работающий комп нужен "здесь и сейчас"?
Так вот я отвечу - надо отключать "аппаратные средства", переходить на "программные алгоритмы умножения/деления" и тогда абсолютно пофиг какой именно проводок погорел/перебит в том мат. процессоре. А какими методами осуществляется это "программное умножение/деление"? Да методом ХренЗнантКого - который "без поллитры не понять" и который работает "ХренЗнаетСколько времени". Хотя некто Маэстро ещё в 1989-ом предложил использовать на М-13 "очень быстрый способ программного умножения/деления". Кстати, надо посмотреть - а вдруг это действительно "моё Изобретение - которое пока что нигде не применяется??? (про другое своё "Изобретение" ГСПД я пока что особо не распространяюсь)
🤔🤨😆
Вот поэтому Вам и не следует упоминать слово "КОМПЬЮТЕР".
Написали бы просто: "Похождения бравого программиста ... на древнючей М13, 1984 года выпуска. Или как из мухи сделать неверные выводы обо всех вычислительных системах СССР" и было бы всё понятно.
Но Вы же пытаетесь на основе своего неудачного опыта делать ГЛОБАЛЬНЫЕ выводы, тем более в таком менторском тоне: "В прошлый раз я рассказал тебе как компьютеры складывают и вычитают. Теперь настала пора объяснить тебе как они умножают и делят."
Уверяю Вас, Вы абсолютно не знаете как делает это КОМПЬЮТЕР.
Во-первых, при написании этого паблика, я не рассчитывал распространяться о своём ЛИЧНОМ опыте в исследовании мозгов "старого древнего компа М-13.
2. Если уж об этом я стал писать - то надо посмотреть мои ответы на предмет выделения их в отдельные паблики: может кого и заинтересуют эти "мои воспоминания" то старой советской М-13
3.Из своего опыта работы с М-13 я вовсе не пытаюсь делать какие-то выводы о разработках вычислительной техники в СССР. По этому вопросу есть люди и поумнее и поопытнее меня.
4. Никаких "Глобальных выводов в менторском тоне" : Эй, вы, дураки! Щамя вас научу умножать/делить! " - я тут не делаю. ... вы что - того забавного видео вверху насмотрелись/нахохотались и от жажды "популизма" совсем "съехали с катушек"? 🤔🤐😄😆😂🤣
...
И наконец, десятое - если вы такой умный, то напишите свой паблик и расскажите как это делает компьютер. А пока что вы показали, что лишь "воздух" умеете хорошо портить...