Войти
ФлеймФорумЖелезо

Блеск и нищета 8/16-битных консолей и ПК (63 стр)

Страницы: 162 63 64 65 66 Следующая »
#930
15:09, 22 мар. 2020

Gradius
> Есть жёсткая конфа: Spectrum 48K и Pentagon 128K. Другие стандарты НЕ
> признаю!
А, у меня еще и остались платы с Profi несобранного компьютера (какое то количество микросхем распаял :)


#931
(Правка: 15:16) 15:10, 22 мар. 2020

Я ненавидел компьютеры и программирование вплоть до 1998 г.  По причине того, что в школе преподы объясняли информатику неинтересно, а своего ПК у меня не было.  Был только Дендик для игр.  В то время хотел разобраться как сделаны игры на Дендике и как оно работает.  При этом я даже и не догадывался о связи программирования с игростроем :) Так как игры на ПК были настолько убогими, что я  не проводил параллель с играми NES. Это породило мнение, что ПК создан не для игр, а для работы. А для хороших игр создают приставки )))

В 2000 г произошло радикальное событие: товарищ с которым снимали квартиру имел комп Целерон 300 МГц.  Он пробудил интерес к программированию и научил с нуля писать на Borland pascal и немного ассемблера.  В 2001 уже был свой ПК, дальше развивался самостоятельно.

#932
15:13, 22 мар. 2020

innuendo
> лол - шо такое магнитофон для спекки ты не в курсе

Коррекция ошибок данных на магнитной ленте отдыхает! :) Только хардкор и только хромовая плёнка и тюнинг головок магнитофона :)

#933
17:03, 22 мар. 2020

Gradius
> А для хороших игр создают приставки )))

какие там стратежки на приставках ?

#934
8:50, 23 мар. 2020

Не знаю сколько тут бит, т.к. комп вообще использует 10-ричную систему https://tjournal.ru/retro/85737-ibm-1401  (там есть видяшка с запуском Fortran на нём)

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

#935
9:25, 23 мар. 2020

0iStalker
> Не знаю сколько тут бит, т.к. комп вообще использует 10-ричную систему

На вики почитал - АЛУ тут в сущности 4-битный BCD обрабатывает за раз 1 десятичный разряд.
Но элементарные машинные операции типа сложения или вычитания без участия машкода могут обрабатывать сколь угодно большие цепочки BCD-чисел ориентируясь на стоп-флаг в цепочке чисел, т.е. предельный размер операндов диктуется только размером памяти.
Сами же ячейки памяти в информативном наполнении 7-битные, причём 1 бит это как раз стоп-флаг для чисел и инструкций.
Шесть остальных бит формируют алфавитно-цифровые последовательности при этом цифры это одновременно и их символы и их представление в АЛУ.
В общем с современной точки зрения это ближе всего к 4-битным калькуляторам, но с блекджеками.

#936
9:27, 23 мар. 2020

=A=L=X=
> На вики почитал - АЛУ тут в сущности 4-битный BCD обрабатывает за раз 1
> десятичный разряд.

Ага, значит BCD рудименты в x86  ногами оттуда растут?

#937
9:48, 23 мар. 2020

0iStalker
> Ага, значит BCD рудименты в x86 ногами оттуда растут?

Я бы так не сказал.
Ориентация на BCD была у многих первых ЭВМ. Приматив бинарной арифметики далеко не сразу занял прочную оборону в головах.
Но т.к. машины электронные, то биты были по факту. Поэтому как именно десятичные разряды укладывались в биты - тоже целая история.
У вот этой же IBM 1401 написано что цифра/символ '0' кодировался как 1010(2) в то время как цифры 1-9 были судя по всему шли от 0001 до 0101 как положено. Т.е. арифмометр там с нулём явно какие то исключения делал.
Встречал еще забавную кодировку цифр в подобных машинах (если склероз не изменяет - ENIAC использовал) когда цифры 0-9 начинают свои коды не с 0, а с 3. Это интересно тем, что облегчается обнаружение того что произошло десятичное переполнение цифры - например 9+1 становится 12+4, т.е. 16 и получается что переполнение обнаруживается по одному четвёртому биту результата, а не более сложным анализом >10. Правда результат потом надо еще править даже если переполнения не было, но кому как показалось проще.
В общем времена были смутные, делали как хотели.

Но у i8086 корни я всё-таки усматриваю в i8080 который в свою очередь коренится в i8008 который уже в свою очередь скорее всего (через авторов) вдохновлялся i4004. А вот i4004 был реально BCD-процессором для калькуляторов и BCD-коррекции в нём были хлебом. Я думаю всё-таки при разработке i8008 решили не упускать возможности сделать его ядром калькулятора, раз уже механика процесса была хорошо отработана, и всего лишь. А дальше затянуло через вопросы обратной совместимости накрепко.

#938
11:37, 23 мар. 2020

=A=L=X=
> могут обрабатывать сколь угодно большие цепочки BCD-чисел ориентируясь на
> стоп-флаг в цепочке чисел

Прикольно, что-то типа префикса REP для операций сложения/вычитания? Только вот даже с операциями умножения не прокатит уже. Разве что только в виде умножения большого числа на число единичного (одна ячейка) размера... Будешь реализовывать это в симплетоне (не для десятичных, для длинных двоичных)? ;-)

#939
11:41, 23 мар. 2020

Dmitry_Milk
> Будешь реализовывать это в симплетоне (не для десятичных, для длинных
> двоичных)? ;-)

Simpleton уже поддерживает длинные числа по вполне стандартной схеме ADD/ADC и смысла делать какие то усложения над этим еще никаких не вижу. Тем более что это таки Simple-ton, а не Complex-ton. :)

#940
12:22, 23 мар. 2020

Dmitry_Milk
> Прикольно, что-то типа префикса REP для операций сложения/вычитания? Только вот
> даже с операциями умножения не прокатит уже.
Для длинных умножений обычно используют такой вариант инструкции MUL, который перемножает два n-битных числа, получает полный 2n-битный результат и затем раскидывает его по двум разным регистрам, нижние n бит в один, верхние во второй.
В x86 - это IMUL r/m32, умножает EAX на gpr/память, сохраняет нижнюю половину в EAX и верхнюю - в EDX.
В PPC - это пара mulld RT, RA, RB/mulhd RT, RA, RB, которые раздельно считают нижнюю и верхнюю половину соответственно.
В ARM - это SMULL RdLo, RdHi, Rn, Rm.
Вот здесь можно посмотреть, как этими инструкциями пользуются компиляторы.

#941
13:53, 23 мар. 2020

Delfigamer, да я ж не про современные высокоразрядные процессоры, я про воображаемые упрощенные "ортогональники" типа алексовского симплетона. А асм x86 (и не только его) я знаю, я недавно на нем демки писал :)

#942
(Правка: 14:24) 13:57, 23 мар. 2020

Dmitry_Milk
> Прикольно, что-то типа префикса REP для операций сложения/вычитания? Только вот
> даже с операциями умножения не прокатит уже.

Хехе. У них прокатило. :)
Я это еще утром заметил - но у них есть операции MUL/DIV и они тоже runlength.
Сейчас дошли руки поискать как оно вообще работало то: https://web.archive.org/web/20100809033646/http://www.bitsavers.o… nce_Apr62.pdf

Для начала желательно понять как работает сложение.
Команда сложения (литерал 'A' от ADD) имеет два аргумента - адрес A и адрес B (адреса имеют размер в 3 ячейки памяти, т.е. инструкция 'A001980' сложит числа по адресам 001 и 980).
По этим адресам располагаются самые малозначащие цифры чисел, но числа при этом растут в памяти от больших адресов к меньшим и последняя цифра отмечена тем что в ней зажжён бит "word mark" - стоп-бит.
Складывает машина так - она начинает к цифрам в адресе B прибавлять цифры с адреса A с переносами и идёт (декрементируясь по адресам) до тех пор пока не встретит стоп-бит к числе B. Если раньше чем это условие будет выполнено она увидит стоп-бит в цифрах числа A, то вместо считывания из A из этого потока данных просто будут до конца команды впредь поступать цифры '0'. Но останов команды происходит только и всегда при встрече стоп-бита в B.
Иными словами в числе B должно быть заранее выделено достаточно памяти чтобы в нём поместился результат - если число A будет длиннее, то его остаток отбросится.

Что же касается умножения, то оно описано следующим образом:
Команда @AAABBB умножит число (по адресу) BBB на число (по адресу) AAA, но тут вот какое дело - в числе A имеем первый множитель, в числе B в старших разрядах (нижних адресах) находится второй множитель, но в нижних разрядах (старших адресах начиная с самого адреса BBB) должно быть зарезервировано места столько же сколько цифр в A + 1.
Как я понял умножение делает следующее - сперва заливает нижние (сколько цифр в A+1) цифр B нулями, а потом начинает прибавлять к B (нижним разрядам) число A*нижнюю_текущую_цифру_множителя_в_B сдвигаясь каждый раз правее на разряд. При этом эффективный множитель в B разряд за разрядом стирается, но это и нестрашно, т.к. нижние разряды поучаствовав в операции уже неважны) и в конце концов замещается результатом умножения целиком.

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

Стоит наверное еще заметить, что runlength в машине было действительно сильно - например была команда переброски одной ячейки памяти (D, data), но была и M - move, которая копировала строку символов/цифр с одного адреса в другой ориентируясь как раз на стоп-бит.

#943
14:25, 23 мар. 2020

А, ну понятно, фактически при умножении "столбиком" частичные произведения считаются начиная со старшего разряда, а не с младшего, как учили в школе. Это позволяет использовать хранилище (расширенное до 2N) множителя сразу же как сумматор для частичных произведений, т.к. младшие разряды множителя при сложении старших частичных сумм не участвуют.

#944
14:32, 23 мар. 2020

Но для симплетона с его 16 разрядами наверное проще поступить как у PowerPC, отдельными инструкциями для старшей и младшей половины произведения.

Страницы: 162 63 64 65 66 Следующая »
ФлеймФорумЖелезо