Здесь принимаются все самые невообразимые вопросы... Главное - не стесняйтесь. Поверьте, у нас поначалу вопросы были еще глупее :)
Ответить

Re: Микропроцессоры: Попытки разработки собственной архитект

Сб янв 14, 2017 01:38:18

А мне вот по душе следующая архитектура. Имеется общая внутрипроцессорная шина. Имеются регистры, которые могут быть на чтение, запись, или и то и другое. Команд как таковых не имеется. Входное слово (команда) делится на 2 части: адрес откуда взять данные на шину и адрес принимающего с шины регистра. Регистры все одной битности, в своей поделке я буду делать 8 бит в силу отсутствия в моем владении завода по выращиванию кристаллов и наличии лишь микросхем 74 серии и аналогичных. Идеальным считаю 16 или 32 бита, главное, чтобы все регистры были одинаковой разрядности.
Собственно, вся программа состоит из пар "отправитель" - "получатель". Если регистр на чтение и на запись, то адреса для чтения и записи могут различаться (чтобы не потерять много адресов из-за односторонних регистров). А вот если получатель 00000000 (в моем случае 0000, т.к. в железе я планирую восьмибитную команду), то вместо отправителя команда без адреса (например, NOP, или перевод адреса с регистра адреса в счетчики адреса, по условию или без. Получатель 00000000 - это как бы модуль команд без параметров). Если 11111111, то вместо отправителя константа, которая пропихивается в следующие n-бит регистра для сбора константы (при полном заполнении регистра счетчик сбрасывается и заполнения регистра сборки константы начинается опять с младших битов). Вот вам и конструктивная особенность, связанная с железной реализацией - выбор 11111111 и 00000000 адресов для команд. Потому что их проще реализовать в железе, меньше микросхем потребуется. Все остальное - это просто комбинация адреса регистра, сбрасывающего значения на шину, и адреса регистра, на который мультиплексором уйдет такт для записи.

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

Конечно же такую архитектуру я для себя избрал только по одной причине: я планирую доделать это в железе. Поэтому опирался исключительно на то, что будет красиво с моей точки зрения (однотипность операций) и легко реализуемо в железе. То есть я заранее соглашусь, что моя разрядность не оптимальна, архитектура для высоких частот не оптимальна. Ведь куда проще брать исходные данные за 1 такт широкой командой, а за следующий (или нисходящим фронтом) выкидывать результат. Но еще раз: у меня нет завода по производству чипов во владении. А вот с точки зрения обзорной модели "как работает процессор" или "ого, вот он процессор своими клешнями" - для этого такая архитектура в самый раз. Вы могли заметить, что в моем случае кусок АЛУ под свободные адреса запросто может сесть на шину, остается лишь компилятору об этом рассказать. То есть процессор сборный и кроме 0000 и 1111 (штатных команд в небольшом количестве и команды сборки константы) все остальное можно подключать и отключать. А как в железе упростить понимание адреса каждым модулем за исключением этих двух "особенных"? С дешифратора отправляем на шину не только биты, но и их инверсии. А на модулях просто собираем также, как сделано в любом мультиплексоре (от каждого бита либо его основу, либо инверсию). Короче, все у меня придумано конкретно для железа и конкретно для ручной сборки.

К этому и был мой первый вопрос. Ну.. процессоров виртуальных мы можем наделать кучу. Можем мечтать об этом, можем реально экспериментировать. Но как только дойдет до железа, то мы ловим сразу две причины сделать все совсем по-другому:
1) Высокие частоты (вы упомянули про провода, но там частоты были явно минимальные). И это главная причина.
2) Совместимость. При реорганизации слишком большие издержки, в нашем случае пришлось бы ПО переделывать на корню.

///
От себя еще добавлю, что лично на мой взгляд процессор должен быть законченным объектом. Это я говорю как программист. Потому что наборов функций АЛУ типовых может быть лишь несколько, дальнейшая оптимизация в этом месте не приведет к существенному приросту. Также не вижу перспектив в наращивании последовательных шин. В связи с тем, что все упирается в частоты, будущее наверное за архитектурой параллельного включения процессоров, возможно даже в одну широкую шину. Ну или как частный случай, в утолщении шины. Поэтому ни ваша идея, ни моя идея, кроме академического интереса позиций не имеют.

Добавлено after 2 hours 44 minutes 42 seconds:
Re: Микропроцессоры: Попытки разработки собственной архитектуры
И в довесок схема какого-то наипростейшего допотопного процессора, который еще динозаврам служил. А вы все шутите про ноги сумматора...

Re: Микропроцессоры: Попытки разработки собственной архитект

Сб янв 14, 2017 15:28:28

Paguo-86PK писал(а):Вaш процессор напоминает мой, который многие критикуют. Суть которого в том, что АЛУ в нём отсутствует, но он просто работает как маршрутизатор потоков данных между всеми внешними устройствами, как умный ПДП. Подключив к нему внешние FPU/ALU - получаем полноценное процессорное устройство.

Ну так на сколько я знаю, АЛУ - это не весь процессор, а всего лишь один из исполнителей. Имеет, грубо говоря, две входные шины, одну выходную, шину номера операции и линии вывода некоторых флагов. Например, zero флага и carrier флага (флага переноса) Отвечает он за такие операции, как сложение, вычитание, умножение, деление, сравнение и логические операции (И, ИЛИ, НЕ, И-НЕ, LSL, LSR и т.д.) От того у него и такое название "Арифметико-логическое устройство", ибо его основная задача в процессоре - быть всего лишь управляемым по команде калькулятором.
В моем примере АЛУ является всего лишь одним из узлов.

Микропроцессоры: Попытки разработки собственной архитектуры

Сб янв 14, 2017 18:18:59

DX168B писал(а):Ну так на сколько я знаю, АЛУ - это не весь процессор, а всего лишь один из исполнителей. Имеет, грубо говоря, две входные шины, одну выходную, шину номера операции и линии вывода некоторых флагов. Например, zero флага и carrier флага (флага переноса) Отвечает он за такие операции, как сложение, вычитание, умножение, деление, сравнение и логические операции (И, ИЛИ, НЕ, И-НЕ, LSL, LSR и т.д.) От того у него и такое название "Арифметико-логическое устройство", ибо его основная задача в процессоре - быть всего лишь управляемым по команде калькулятором.
В моем примере АЛУ является всего лишь одним из узлов.

Онo то понятно.
Но, если Вы внимательно читали стартовый пост, флажки АЛУ мною были замкнуты на дешифратор команд.
Код:
 SF|PF|CF|ZF
+--+--+--+--+
| 0| 1| ?| 1| Паритетный ноль:    (SKIP N) Исполнительный узел проигнорирует N инструкций дешифратора
| 1| 0| ?| 1| Отрицательный ноль: (LOOP N) Запрещает инкрементацию счётчика команд и одна инструкция выполняется N раз
| 1| 1| 1| 1| Отрицательный паритетный ноль: (WAIT N) То же самое, что LOOP, но с проверкой флага CF (здесь - Continue Flag)
+--+--+--+--+
Тем самым, достигаются уникальные возможности. Где N - остальные 4 бита, неиспользуемых ао флаговом регистре.
Так, в РАДИО-86РК первые 36 байтов "Монитора" - 12 команд JMP. И если туда "прыгнуть" с режимом SKIP, то выполнится именно N-ная подпрограмма API-Монитора.
И после возврата RET из подпрограммы в приложении могут быть пропущены N-инструкций, если что-то не так (например, никакая клавиша не нажата - в приложении 1 инструкция пропустится).

P.S.: Надеюсь, вы уже начали понимать, что мои "прихоти" необычной системы команд с её "красивостью" - не просто очередной проект из тысяч остальных в интернете. А просто незначительные доработки именно i8080 в том русле, которые открывают возможности RISC-процессоров или PIC'ов.

Микропроцессоры: Косметическое "причёсывание" систем команд

Сб янв 14, 2017 23:19:59

Paguo-86PK писал(а):.. мои "прихоти" .. системы команд с её "красивостью" - ... просто незначительные доработки именно i8080 ...
Ну вот это совершенно прямое и честное утверждение.
Но зачем тогда было писать слово "архитектура" в названии темы ?
Чтоб форумчане обратили внимание ?
Мож попросите модераторов поправить на что-нибудь вроде "Косметическое "причёсывание" систем команд" ?
Ну или что-нибудь в таком стиле.

В любом случае плохого в Вашем досуговом занятии ничего нет, так что удачно Вам продолжать сие. :tea:

И - что то я видимо недостаточно внимательно читал все Ваши сообщения - Вы уж выкинули из системы команд вызовы CALL по абсолютным адресам или пока ещё нет ?

"Если чё" - выкидывайте смело, разрешаю ! :)))

Re: Микропроцессоры: Попытки разработки собственной архитект

Вс янв 15, 2017 02:03:58

Кстати к своему посту добавлю по поводу архитектуры с переносом данных. АЛУ можно выполнять древовидную - это раз. Их можно делать несколько разных - это два. Вопрос утыкается лишь в количество свободных адресов для регистров. Как это работает? Допустим наше АЛУ решает выражение A * B + C * D. Мы можем затащить все 4 значения, а можем только первых два и взять с них результат промежуточный. А второе АЛУ решает выражение (A + B) * (C + D). Получается, что в рамках сложения и умножения у нас большие просторы для получения результата за такт. Но в данном подходе есть один минус - промежуточные значения мы можем только читать. Чтобы система была более гибкой, можно позволить флагами настраивать такое АЛУ. Тогда задача (A + B) * E легко решаема, если узел "C + D" установлен на запись и оттого значения C и D уже не будут играть роли. А теперь представим, что исследовали частые комбинации простых вычислительных комбинаций (частые выражения в среднестатистической программе под целевую ОС). Тогда не составит труда построить довольно увесистые АЛУ, покрывающие все вычислительные потребности с минимальной подстройкой. Также можно прибегнуть к хитрости, позволяющей за счет свободных адресов внутри АЛУ влиять на ее поведение, помещая исходные значения в свободные адреса вместо типовых. Например, есть A+ и A- в адресном пространстве регистров. Если мы хотим вычислить в АЛУ (A + B) * (C + D), то значение A помещаем на адрес A+. Если же хотим (A - B) * (C + D), то помещаем на A-. Это пример того, как наиболее часто повторяющиеся выражения вычислять за меньшее число тактов, используя остатки не занятых адресов регистров. И кстати тогда выводить адресацию АЛУ за пределы процессора вообще не требуется, т.к. уже внутри появляется серьезный инструмент для массовых вычислений. Что касается размерности этих древовидных АЛУ, то этажей 5 вполне хватит (наш пример - это 3 этажа: значения, суммы, произведение. Ну или последние 2 пункта наоборот, если берем другой из примеров). Операции могут быть и гораздо более сложные, типа умножения, деления, или даже более извращенные. Не проблема, если АЛУ не успевает отработать все 5 этажей за 1 такт - ведь мы всегда можем использовать лишь его часть, которая успевает отрабатывать, либо подождать дополнительный такт, либо вообще заняться заполнением другого АЛУ, пока это АЛУ генерирует результат.

И это кстати вовсе не новая какая-то идея. Сейчас не найти ПК, в котором это не используется для нашего родного D3D при аппаратной поддержке. Речь конечно же о перемножении матриц 4*4 "в 2 щелчка", их сложении, нахождении детерминанта, ну и так далее. А применении такого подхода вне графических процессоров мне неизвестно, но идея от этого хуже не становится. Жаль, что в любительском проекте такую вещь применить удастся лишь виртуально. Уж больно суровая получается схема даже одного такого комбинированного АЛУ. Ну и не стоит забывать, что мощность подобного АЛУ даже на холостом ходу будет существенна и для МИКРОпроцессоров пришлось бы понижать частоту для защиты от перегрева. Опять же смотрим на графические процессоры - их частота объективно ниже, хотя греются похлеще основного процессора. Короче, "все придумали до нас" =)

Микропроцессоры: Косметическое "причёсывание" систем команд

Вс янв 15, 2017 10:51:00

petrenko писал(а):Ну вот это совершенно прямое и честное утверждение.
Но зачем тогда было писать слово "архитектура" в названии темы ?
Чтоб форумчане обратили внимание ?
Мож попросите модераторов поправить на что-нибудь вроде "Косметическое "причёсывание" систем команд" ?
Ну или что-нибудь в таком стиле.

В любом случае плохого в Вашем досуговом занятии ничего нет, так что удачно Вам продолжать сие. :tea:

И - что то я видимо недостаточно внимательно читал все Ваши сообщения - Вы уж выкинули из системы команд вызовы CALL по абсолютным адресам или пока ещё нет ?

"Если чё" - выкидывайте смело, разрешаю ! :)))
Абсолютныe адреса CALL/JMP i8080 - два байта и выходят за рамки 8-битового процессора. Их я выбросил сразу и все команды работают только с байтами. Извращение i8080 - LXI SP,a16, так как стековый регистр загружается крайне-крайне редко. Этих инструкций у меня вообще нет с самого начала. Как и EI/DI/PCHL/IN/OUT, которые достигаются более длинными комбинациями нескольких команд.

Системa команд довольно простая для тех, кто занимался машинным кодом i8080/Z80:
Код:
.. 00 --:HLT ;MOV [BX],[BX]     - в i8080 mov m,m означает hlt
.. 06 --:MOV  CL,[BX]           - аналогично mov c,m
.. 70 --:MOV  [BX],DL           - аналогично mov m,d
.. 76 --:MOV  CL,DL             - аналогично mov c,d
66 ++ ??:PREFIX CL   ;MOV CL,CL - аналогично mov c,c - пустая трата тактов
77 ++ ??:PREFIX DL   ;MOV DL,DL - аналогично mov d,d - пустая трата тактов
.. 85 nn:PUSH 0500h+nn          - аналогично push data в i8086
.. AA nn:ADD  AL,nn             - аналогично adi nn
.. AF nn:CMP  AL,nn             - аналогично cpi nn
.. B8 nn:JMP  ±nn               - безусловный относительный переход ±128
.. B9 nn:CALL ±nn               - условный относительный вызов ±128
.. BC nn:JC   ±nn               - условный относительный переход ±128
.. CD --:INC  DX                - аналогично inx d
.. FE --:NOP                    - холостая операция
.. FF --:RET                    - безусловный возврат из подпрограммы

С префиксами те же операции приобретают бОльшую гибкость:
Код:
77 85 nn:PUSH 7500h+nn          - расширяется диапазон
66 AA nn:ADD  CL,nn             - префикс 66 - подменяет аккумулятор на CL
77 AA nn:ADD  DL,nn             - префикс 77 - подменяет аккумулятор на DL
11 B8 nn:JMP  ±nn               - префикс расширяет адрес до ±2048
66 CD --:ADD  DX,CX             - префикс расширяет inx d до аналогичной dad
66 FE --:NOP  6                 - префикс 66 для холостой операции - число тактов
77 FE --:NOP  7                 - префикс 77 для холостой операции - число тактов

Однако, нельзя, чтобы команды перехода замыкались на самих себя:
Код:
.. B8 FE:JMP  $      ;WAIT      - зацикливание на себя невозможно принципиально - префикс WAIT (SF=1,PF=1,ZF=1)
.. BC FF:JC   $+1    ;RC        - при переходе на байт назад - встречается FF-RET, достигается возврат по условию

Как вы подметили, "косметическое причёсывание", выполненное мною, однако, могу сказать, не простая прихоть.
У i8080/Z80 команды возврата RZ/RNZ/RC/RNC/RM/RP/RPE/RPO имеют свой код каждая. Экономя, я оставил лишь RET, но, при замкнутом переходе на операнд, процессор оказывается на байте FF. Немного подумав, я решил, что если FF - RET, то можно получить те самые RZ/RNZ/RC/RNC через те самые JZ/JNZ/JC/JNC на самих себя. Так RET получила позицию FF не с потолка, а из практики написания эмуляции.
Код:
   ┌─►RET         Example:
Bx FF:Jcond $+1─┐ 1.BE FF - RZ
┌──┘┌►Rcond     │ 2.BC FF - RC
└───┴───────────┘ 3.BD FF - RNC
И CALL $, которая замкнута на себя и заполнит весь стек, у меня не работает и означает ещё один трюк - специальный префикс.
Т.е. у меня всюду имеется "защита от дурака", превращённая в занятные "плюшки": Можно пропустить 255 операций (не байтов, а именно целых инструкций); можно повторять их до 255 раз (как в i8086 - REP MOVSB) и т.д. При этом в таблице явно этих префиксов нет. В начале темы есть анимированный скриншот таблицы команд и их модификации префиксами

P.S.: Если чуточку потрудиться и глубже ознакомиться с моими наработками, станет видно, что это - не только "косметическое причёсывание" i8080/Z80, а некое ответвление унаследованой архитектуры.
Например, у меня имеются стековые АЛУ-операции без операндов. Просто ADD (код 44 4A) выполняет операцию в регистровом файле (т.к. каждый регистр - стек на 8 уровней). Что выходит за рамки i8080/i8086 и приближается к MISC.
Есть и совсем экзотеческие операции, типа ADD CL,DL[3] для стекового сложения текущего CL с историей DL третьего уровня. В редких процессорах такое встречается. У меня - это незапланированная операция, недокументированная побочная плюшка-сюрприз.
P.P.S.: Можете теперь видеть, система команд позиционно у меня также имеет практические наработки.
Не раставлял я команды по таблице взглядом в потолок. Практически, вынашивая почти 20 лет, мною логически много обосновано.
Тем самым, совет о переименовании темы - хоть и уместен, но слишком поверхностен. Администрация форума сама пусть решает.
Последний раз редактировалось Paguo-86PK Вс янв 15, 2017 12:00:16, всего редактировалось 1 раз.

Микропроцессоры: Косметическое "причёсывание" систем команд

Вс янв 15, 2017 11:41:22

Прямо говоря, "по честноку" то бишь , так гораздо больше пользы было бы, ежели бы Вы занималсиь "причёсыванием" системы команд MicroVAX например - можно его советского аналога.
Тогда была бы вполне реальная возможность проверить микрокоды прямо "в железе".
( С единственным небольшим ньюансом - микрокоманда "их" и нашего процессора - разные по длине. Но это не так уж и страшно )

Re: Микропроцессоры: Попытки разработки собственной архитект

Вс янв 15, 2017 11:44:33

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

Все с точностью до наоборот. Именно проблемы с синхронной работой параллельной шины приводит к необходимости использовать последовательные. То есть 16 последовательных шин позволяют поднять частоту заметно выше, чем может иметь одна 16-разрядная параллельная.
Плюс к этому в современных архитектурах планируется широко использовать оптические способы передачи данных внутри кристалла. Патамушта в нынешних проектных нормах обеспечить внутрикристалльную коммуникацию становится предельно сложно.
И отсюда возникают внешне необъяснимые ограничения на синхронизирующие и информационные связи модулей МК (или процессора).
А вообще, тема отдает некоторой нафталиновостью. Архитектуры затачиваются под класс задач и технологии производства. Как уже говорилось ранее, кодировка операций занимает последнее место в приоритетах. Скорее она отражает построение дешифратора команд. Нынешней разрядной сетки командных слов за глаза и за уши хватает на любую архитектуру АЛУ и ЦП.

Re: Микропроцессоры: Попытки разработки собственной архитект

Вс янв 15, 2017 13:17:33

В поисках стабильности и защиты от сбоев, коду 00

Чем 00 отличается от АА, от 45 или, скажем, от E6. Да, прямо скажем, ничем. Другое дело, как уже было указано, - дешифровка КОП. Отсюда и надо было скакать в своё время. И помнить о дуализме. А эмуляторы писать - пусть пишут другие под ваш суперпроцессор.
В сторону: Intel напару с IBM нервно курят в сторонке.

Микропроцессоры: Попытки разработки собственной архитектуры

Вс янв 15, 2017 14:18:22

pyzhman писал(а):Чем 00 отличается от АА, от 45 или, скажем, от E6. Да, прямо скажем, ничем. Другое дело, как уже было указано, - дешифровка КОП. Отсюда и надо было скакать в своё время. И помнить о дуализме. А эмуляторы писать - пусть пишут другие под ваш …
"школьный процессор" - говорю же, что со школы начал делать наброски.
Тaк, в i8080/Z80 HLT затерялась к кучке MOV R,R1 и подменила MOV M,M. Пересортировав позицию команд, я просто сместил MOV так, чтобы у HLT код стал 00. И дальше пошло-поехало.
Включил ассоциативное воображение:
Команды с кодом Ax - АЛУ, с кодом Bx - Branch-ветвления, с кодом Cx/Dx - инкремент/декремент, Ex - экспериментальные, а Fx - функциональные (INT n, RET и т.д.).
Вина моя в том, что я подошёл к вопросу как эстет. :facepalm: Раз так уж…
Тем более, интернет кишит "школьными" и "студенческими" проектами процессоров.
Беда которых - полная практическая бесперспективность.

В моей концепции процессора - багаж программ и алгоритмов i8080/Z80/i8086… Да, без ретрансляции алгоритмы у меня не заработают. Но, алгоритмы деления, извлечения корня и черчение линий - портировал.
Причём, с ассемблера Z80 переносил в x86-ассемблер Си-отладчика, а оттуда, как есть - в ассемблер собственного процессора.
Занудство? Да! Но, как мальчишки, Вы можете понять, какой кайф, что это - работает!!! :beer:

А насчёт AA/45/E6 - код E6 используется магнитной лентой в Радио-86РК/Специалист/Орион.
Тогда как отладчик x86 заполняет стек и остальные "дыры" кодом CC - INT 3. По мне, по-дефолту память принято обнулять, а не за-Цэ-Цывать. И будь в x86 у кода 00 соответсвия на INTO/INT3/HLT, некоторые места смотрелись бы иначе: Стек был бы обнулёным, а не ЦыЦыкнутым.

P.S.: Почему именно i8080, а не Z80? У первого - система команд примитивная и близка к x86. Тогда как в Z80 множество собственных фишек, часто излишних.
И я выше уже писал, что у моей версии процессора нет команд EI-DI/STI-CLI и на аппаратные прерывания он не реагирует. Но, прелесть в том, что можно заставить его реагировать на прерывание, передав управление прикладному коду - вне системного кода прерывания работают…
Это - тоже побочный механизм, до которого додумался месяца 2 назад. Аппаратные прерывания - часть прикладного кода (ошибки, исключения, прерывания, останов HLT - всё часть прикладного кода. Системный код вместо HLT имеет спец-префикс).

Re: Микропроцессоры: Попытки разработки собственной архитект

Вс янв 15, 2017 17:18:08

Боюсь напомнить про исключения.

Микропроцессоры: Попытки разработки собственной архитектуры

Вс янв 15, 2017 20:14:53

pyzhman писал(а):Боюсь напомнить про исключения.
Зpя вы так… :tea:
Выше я уже писал про "Механизмы обработки прерываний":
Код:
    ORG     0xFEFB
BIOS:
.app:       ; Передача управления приложению
    MOV     [0],AL          ; Выбор контекста - операция занимает 5 байтов
            ; Стартовый адрес процессора 0FF00h
            ; После сброса процессора включается режим SKIP 7 - пропустить 7 JMP'ов
            ; Прерванное приложение возвращает управление с режимом SKIP 1-6:
    JMP     .overhead       ; No Skip:Запрос к стандартному API
    JMP     .acclaim        ; SKIP 1: Обращение к программным прерываниям INT 0-79
    JMP     .buffer         ; SKIP 2: Буферная зона - прослойка диспетчера памяти
    JMP     .context        ; SKIP 3: Диспетчер переключения контекста процессов
    JMP     .device         ; SKIP 4: Запрос ко внешнему устройству ввода/вывода
    JMP     .error          ; SKIP 5: Обработчик программных/аппаратных ошибок
    JMP     .force          ; SKIP 6: Внешние форсированные события/прерывания
.garret:    ; Здесь начало работы BIOS при старте
            ; Иницируется стек, регистровые файлы приложений,
    ...     ; настраивается периферия
    MOV     [6],CL          ; Системные регистры №6 и №7 - соответственно младший байт
    MOV     [7],CH          ; и старший счётчика тактов, обратный отсчёт которого ведётся
                            ; в контексте прикладной задачи. Его обнуление - генерирует
                            ; запрос к диспетчеру контекстов (см. SKIP 3 выше с JMP .context)
    JMP     BIOS.app        ; Передадим управление конкретной прикладной задаче
    ;;;;;;;;;
.acclaim:   ; Здесь расположен код обработки программного прерывания INT 0-79,
            ; предоставляющий доступ к базовому API
    ;;;;;;;;;
.buffer:    ; Здесь расположение кода менеджера памяти
    ;;;;;;;;;
.context:   ; Менеджер переключения контекста получает управление после истечения
            ; работы конкретной задачи или её пошаговой отладки
    ;;;;;;;;;
.device:    ; Симулятор внешних устройств получает управление когда конкретное
            ; устройство системы запрашивается приложением. Нечто похожее
            ; на HAL/HEL-прослойку Windows.
    ;;;;;;;;;
.error:     ; Здесь расположен код обработки аппаратных и программных ошибок,
            ; исключений и ситуаций, которые не были предусмотрены
    ;;;;;;;;;
.force:     ; Наконец, тут находится код для обработки разных внешних сигналов,
            ; форсирующих выполнение системных функций.
            ; Например, нажатие клавиши клавиатуры и нажатие кнопки сброса -
            ; - прежде всего форсирующее событие, а потом уже - прерывание.
            ; Таймер реального времени, сигнал нестабильности источника питания,
            ; подключение USB-устройства - тоже форсаж, а не прерывание.
            ; Короче, весь маловажный "хлам" - здесь
Видно, что MOV [0],AL здесь не принимается за "сохранение значения регистра по абсолютному адресу в памяти".
Абсолютные адреса у меня - анахронизм. У x86 имеются управляющие регистры CRn/DRn. Здесь [0] - и есть управляющий регистр №0, недоступный приложениям никак.
Записывая в него значения 0-127, менеджер переключается на конкретное приложение. Так как старший бит равен 0, прерывания и другие "внешние силы" разрешаюся.
Если приходит сигнал прерывания, он получает класс от 0 до 7, а в управляющем регистре №0 старший бит устанавливается в "1", что переключает управление на единственный системный контекст, где прерывания и всё остальное запрещается…

P.S.: Тем самым, все эти ваши "исключения" и "прерывания" имеются в составе 7 типов. В эмуляторе испытано лишь несколько…
P.P.S.: Следует заметить, что MOV [0],AL - комплексное трюковое сочетание трёх инструкций:
Код:
44 00:HLT AL
B8 FE:WAIT (JMP $)
00   :HLT
И так-как AL "захвачен" вначале HLT, он является не только "источником", но и "приёмником". Тем самым, HLT - не только приостановит системный процесс на время выполнения прикладной задачи с индексом из AL, но и вернёт в AL как индекс внешнего устройства, так и выставит флажки PF-ZF для режима "Skip".
Если вдуматься - всё изяшно и красиво (чем в x86 с его таблицей для INT 0-255 или i8080/Z80 с RST 00-38), так как имеется абсолютная предсказуемость: Что бы ни происходило (пришёл сигнал Reset/IRQ/Bus/Wait или произошёл внутренний сбой арифметики/памяти) - управление получит код по 0FF00h. А это - шаг к стабильности. :wink:

Микропроцессоры: Попытки разработки собственной архитектуры

Чт янв 26, 2017 22:43:53

Понимaю, что многим до лампочки на кустарные "фантомные" кастомные прожэкты :)))
Тут несколько мыслей покоя не даёт. И справиться не могу никак…

Многозадачность
Каждая из задач должна иметь как минимум 256 оперативных регистров. Из которых 64 - РОН, 32 - указатели, 160 - программируемые инструкции.
Естественно, даже в рамках современных ПЛИС - это очень дорогое удовольствие. Поэтому, считаю, что по-настоящему оперативно доступных регистров должно быть в разы меньше, тогда как остальные могут быть доступны посредством использования любого удобного современного скоростного сетевого протокола и подгружаться динамически.
Но, даже в эмуляции эти динамические регистровые файлы и окна работают очень медленно и никак не могу справиться с этим.


Режим ПДП
Задумывается всё так, чтобы процессор сам мог бы работать как ПДП.
Так как расчитывается, что всего может быть запущено до 128 процессов, то несколько могут работать в режиме ПДП, так как это гораздо удобнее любого готового контролера ПДП.
У меня же стартует всё процессом №0 с максимальными привелегиями, тогда как процессы 1-99 считаются прикладными. Процессы 100-127 расчитаны как сервисные под "демонов".
Например, по приходу запроса к ПДП процессор должен приостановить текущую задачу (как при IRQ) и выполнять команды ПДП-обработчика (не как IRQ) в особом режиме: Брать из внутренней статической памяти цепочку заготовленных команд, исполнение которых требует от 1 такта на операцию + задержки на чтение/запись памяти.
Зачем такое?
Чем программировать внешний ПДП, можно вполне обойтись внутренними микрокомандами, как регенератор памяти Z80. Давно хотел как-то подойти к этой проблеме, но не знал, с какого бока подойти.
Тем более, критические секции прикладного кода у меня имеют пачку NOP 1-7 для организации синхронизированной задержки. Тем самым, вместо NOP процессор мог бы вполне выполнять "прозрачную" для текущей задачи задержку. Только под видом "холостой операции" выполнять операции ПДП-потока. В этом случае, ПДП-задержки стали бы и вовсе незаметными…
А 28 "демонов" - достаточное количество, чтобы обеспечить нужное число потоков…


Арифметика
Операций умножения/деления как бы и нет. Есть лишь цикл LOOP/WAIT 1..255 + ADD/SUB-инструкция. Понятно, что умножать и делить циклом - крайне медленно. Однако, введена маленькая хитрость: Если подключен внешний сопроцессор (специальный) с поддержкой этих операций, то он просто перехватит из потока команд эти комбинации LOOP+ADD и вычислит всё сам за несколько тактов, отправив в регистровый файл верное значение. А сама программа так же имеет опциональный статус при наличии аппаратной поддержки.


Дешифратор
Шина дешифратора команд пока насчитывает порядка 18 пар (18 прямых и 18 инверсных) сигналов, к которым должны подключаться 60 инструкционных узлов через вентили логики "И".
Почему 18, так много? Здесь 8 - сам код инструкции, а 10 - её статус в программе: Является ли код префиксом; Является ли код замыканием префикса; Является ли код замыканием цепочки; Является ли инструкция частью линейного цикла; Является ли инструкция частью предзагруженной цепочки цикла; и т.д…
Чем городить в некоторых инструкциях блоки условной перепроверки подстатуса и удлинять цепь с задержками, решено было просто расширить шину дешифрации.
Этим и достигается, что три обыкновенных инструкции в нестандартном объединении образуют одну "трюковую" или "системную" инструкцию (например, <B8 FE 56> => WAIT + MOV BL,CL => OUT BL,CL).

P.S.: К сожалению, реализовать на макетках собственную задумку считаю нереально - вычислительная "мощность" процессора через чур большая для сборки на коленке ради забавы.

Re: Микропроцессоры: Попытки разработки собственной архитект

Сб янв 28, 2017 08:24:55

Я бы еще раз предложил Вам ознакомиться с современными архитектурами ядер.
Прямой доступ в память уже давно делается внутрицикловым, то есть для транзакций используются те такты цикла, где нет обращения к шине данных/адреса, и/или для DMA использована отдельная шина.
Многозадачность при единственном ядре (псевдомногозадачность) в состоянии разделять ресурсы программными методами, что и реализовано в любой ОСРВ. Аппаратное жесткое разделение - совершенно беспонтовая вещь, патамушта в реальных задачах ресурсы используют ОДНОВРЕМЕННО несколько задач (поскольку этого требует алгоритм) и передача ресурса/данных из одной задачи в другую станет дополнительной тратой времени и самих этих ресурсов.

Re: Микропроцессоры: Попытки разработки собственной архитект

Сб янв 28, 2017 10:30:06

Многозадачность на физическом уровне в разы лучше. Это обусловлено тем, что постоянно выгружать-загружать состояние регистров для смены задачи - тоже время и ресурс. Да, можно в рамках ОС частоту смены задач уменьшить, но тогда начинают страдать те задачи, которые по сути своей требуют реальное время и не особо комфортно живут в фоновом режиме на остатки производительности. Например, архиватору хорошо живется в остатках и ему важно суммарное время, когда графическому (и не только) движку реального времени куда комфортнее сидеть в ядре монопольно на постоянной основе. Частично вроде как это решают приоритеты в ОС, но это же заплатка и монополии все равно не даст, плюс сама ОС у любого условно монопольного процесса все равно кушает определенный ресурс.

Так что я склоняюсь к тому, что 16+ ядер - это наше всё. Если задача в ОС классифицирована как фоновая, то сидеть ей с собратьями на одном ядре под контролем ОС. Если задача серьезная, то ей отдельное ядро монопольно. Контролировать ее процесс или прервать его можно через инструмент аппаратный, но не ворующий такты у самого процесса на том ядре, где он сидит. Это выполнимо, поэтому возможность ОС прервать этот процесс или проследить за ним - остается. Если задача уже имеет код, оптимизированный под монопольное использование нескольких ядер (сама ее программа осуществляет взаимодействие между ядрами, что было реализовано компилятором и\или программистами на уровне кода), то можно ей предоставить их. Таким образом, в устройстве несколько тяжелых программ вообще не будут оказывать друг на друга влияние, а операционная система сможет спокойно расходовать и распределять ресурс без намеков на подвисание. Да и пусть эти ядра будут дохленькие по сравнению с топами - все равно это окупится стабильностью и отсутствием лишних переключений.

Re: Микропроцессоры: Попытки разработки собственной архитект

Сб янв 28, 2017 10:44:38

LastHopeMan писал(а):Многозадачность на физическом уровне в разы лучше.

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

Микропроцессоры: Попытки разработки собственной архитектуры

Сб янв 28, 2017 12:12:40

КРАМ писал(а):Я бы еще раз предложил Вам ознакомиться с современными архитектурами ядер.
Прямой доступ в память уже давно делается внутрицикловым, то есть для транзакций используются те такты цикла, где нет обращения к шине данных/адреса, и/или для DMA использована отдельная шина.
Многозадачность при единственном ядре (псевдомногозадачность) в состоянии разделять ресурсы программными методами, что и реализовано в любой ОСРВ. Аппаратное жесткое разделение - совершенно беспонтовая вещь, патамушта в реальных задачах ресурсы используют ОДНОВРЕМЕННО несколько задач (поскольку этого требует алгоритм) и передача ресурса/данных из одной задачи в другую станет дополнительной тратой времени и самих этих ресурсов.
Хoчу подчеркнуть, что собственную задумку двигаю в духе ещё прошлой эпохи. Будучи школьником, прочитал, что Z80 имеет двойной набор регистров для быстрого переключения во время прерывания. Тем самым, как бы псевдо-мультизадачность :)))
Потому и действую сейчас так же: Ядро - одно, переключение между задачами - за такт… Не для АЭС разрабатываю же концепцию, а баловства ради.
Но, не так, чтобы с коленки пнуть и заработало мигалками. А чтобы нечто помощнее бы и перспективнее. В смысле - домашнего исследования: Попытаться написать и операционку, и чтобы свои плюшки имелись уникальные.
Вот например, сочетание LOOP 5 + CALL Fn1 переключает процессор от пятикратного вызова функции к вызову той же функции, но с режимом пропуска 5 первых её инструкций. Что - очень интересно: Если подпрограмму начинать семью командами JMP, получим ON-GOTO переключатель. А это открывает, опять-таки, уникальные возможности. :roll:
(К слову: LOOP n + RET работает так же - возвращается из подпрограммы с режимом пропуска n-инструкций, что позволяет в вызвавшей программе так же организовать переключатель)
(И ещё: Непосредственные константы тоже несут расширенное понятие.
Так, MOV AL,[BX+97] отличается от MOV AL,[BX+127] тем, что число >99 означает расширенный десятичный индекс, где 27 -> 2*R7 -> MOV AL,[BX+2*DL];
Следовательно, MOV AL,[BX-117] -> MOV AL,[BX-1*DL], а вот MOV AL,[BX+107] - не бессмысленный MOV AL,[BX+0*DL], а MOV AL,[BX+INT 7], что ближе уже к RISC-плюшкам :dont_know: )

Понимаю, вот, вы хотите сказать, что в конечном итоге у меня должно скомпилироваться ядро Linux, запуститься оконный интерфейс с MP4-проигрывателем и декодером спутниковой трансляции. Чтобы это в школе ребяткам показать и удивить.
Зачем??? Нет, к этому я не стремлюсь. Думаю, цель в том, чтобы к очень бородатым дядям из НИИ подойти и сказать, мол, вот я - чудак, их архитектуру 60-х перелопатил и сделал 8-битное подобие Z80, полностью несовместимое ни с чем. Потратил 20 лет на это. Тупо! :facepalm:
Чтобы они, покрутив пальцем у виска, всё же, задались вопросом "А смысл?". Весь код - мой (6 тысяч строк), плюшки - свои. Кругом - ОпенСорс, бери и подтягивай. Но, зачем?
Просто, хочу исследовать, каким бы мог быть процессор i8080, если бы в 70-ых я бы с пелёнок сидел в самой Intel и царапал бы кристалл чупачупсом :solder:

P.S.: Иначе говоря - творческое исследование ради самого процесса разработки.
Не ждите от меня "Ура, я запустил Debian в собственном процессоре!". Скорее, можете ожидать "LOOP 3 + MOV AL,1 -> оказывается плюшка!"… :idea:
Кстати, вот набросок электрической шины дешифратора попробовал вообразить:
Последний раз редактировалось Paguo-86PK Сб янв 28, 2017 13:42:31, всего редактировалось 1 раз.

Re: Микропроцессоры: Попытки разработки собственной архитект

Сб янв 28, 2017 13:38:47

КРАМ писал(а):Во первых, смена контекста современными архитектурами так же поддерживается на аппаратном уровне, а получить что то более рациональное гораздо проще увеличением ядер. Тем более, что ядра не слишком увеличивают площадь кристалла. ОЗУ, флеш и шины занимают больше места.


Любопытно, как вы на ПК совместите осциллограф (допустим, программный, фейковый, по отслеживанию одной ячейки оперативной памяти с частотой 500 мегагерц) и одновременно работающий архиватор. Когда у вас это получится, быстродействие архиватора вас весьма удивит.

Re: Микропроцессоры: Попытки разработки собственной архитект

Сб янв 28, 2017 16:21:40

Причем тут ПК?
:dont_know:
Насколько я понял, автор рассматривает RISC-архитектуру....

Микропроцессоры: Попытки разработки собственной архитектуры

Сб янв 28, 2017 16:35:02

КРАМ писал(а):Причем тут ПК?
:dont_know:
Насколько я понял, автор рассматривает RISC-архитектуру....
Знaчит, к сожалению, ввёл всех в заблуждение я… :roll:
Когда 15 лет назад ознакомился поверхностно с RISC-архитектурой, но более глубже, понял, что только и делал, что расписывал шаблоны именно CISC'ов. Видно, опыт работы с РЛК, ZX и т.п. воспитал меня именно на CISC'ах, а RISC'и я до сих пор до конца не понимаю (хотя изучал 6502)… MISC понимаю и то больше. :dont_know:

P.S.: Может у меня получается гибридная архитектура?
Типа CISC, но с RISC-плюшками? :wink:
Озаглавил же прожэкт как Rebused Instructions Set Computer (компьютер ребусного набора команд :))) )…
Ответить