А мне вот по душе следующая архитектура. Имеется общая внутрипроцессорная шина. Имеются регистры, которые могут быть на чтение, запись, или и то и другое. Команд как таковых не имеется. Входное слово (команда) делится на 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
Друг Кота
Карма: 25
Рейтинг сообщений: 99
Зарегистрирован: Вс янв 24, 2010 19:19:52 Сообщений: 4470 Откуда: Главный Улей России (Moscow)
Рейтинг сообщения:0
Paguo-86PK писал(а):
Вaш процессор напоминает мой, который многие критикуют. Суть которого в том, что АЛУ в нём отсутствует, но он просто работает как маршрутизатор потоков данных между всеми внешними устройствами, как умный ПДП. Подключив к нему внешние FPU/ALU - получаем полноценное процессорное устройство.
Ну так на сколько я знаю, АЛУ - это не весь процессор, а всего лишь один из исполнителей. Имеет, грубо говоря, две входные шины, одну выходную, шину номера операции и линии вывода некоторых флагов. Например, zero флага и carrier флага (флага переноса) Отвечает он за такие операции, как сложение, вычитание, умножение, деление, сравнение и логические операции (И, ИЛИ, НЕ, И-НЕ, LSL, LSR и т.д.) От того у него и такое название "Арифметико-логическое устройство", ибо его основная задача в процессоре - быть всего лишь управляемым по команде калькулятором. В моем примере АЛУ является всего лишь одним из узлов.
_________________ I am DX168B and this is my favourite forum on internet!
Ну так на сколько я знаю, АЛУ - это не весь процессор, а всего лишь один из исполнителей. Имеет, грубо говоря, две входные шины, одну выходную, шину номера операции и линии вывода некоторых флагов. Например, 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'ов.
.. мои "прихоти" .. системы команд с её "красивостью" - ... просто незначительные доработки именно i8080 ...
Ну вот это совершенно прямое и честное утверждение. Но зачем тогда было писать слово "архитектура" в названии темы ? Чтоб форумчане обратили внимание ? Мож попросите модераторов поправить на что-нибудь вроде "Косметическое "причёсывание" систем команд" ? Ну или что-нибудь в таком стиле.
В любом случае плохого в Вашем досуговом занятии ничего нет, так что удачно Вам продолжать сие.
И - что то я видимо недостаточно внимательно читал все Ваши сообщения - Вы уж выкинули из системы команд вызовы CALL по абсолютным адресам или пока ещё нет ?
"Если чё" - выкидывайте смело, разрешаю !
_________________ < виртуальная "кнопочка" >--( WWW ) <- Убедительная просьба интересующимся старыми компьютерами типа РК86 - не пишите в теме в барахолке, пишите Ваши вопросы в ( лс ) пожалуйста
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Кстати к своему посту добавлю по поводу архитектуры с переносом данных. АЛУ можно выполнять древовидную - это раз. Их можно делать несколько разных - это два. Вопрос утыкается лишь в количество свободных адресов для регистров. Как это работает? Допустим наше АЛУ решает выражение 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 щелчка", их сложении, нахождении детерминанта, ну и так далее. А применении такого подхода вне графических процессоров мне неизвестно, но идея от этого хуже не становится. Жаль, что в любительском проекте такую вещь применить удастся лишь виртуально. Уж больно суровая получается схема даже одного такого комбинированного АЛУ. Ну и не стоит забывать, что мощность подобного АЛУ даже на холостом ходу будет существенна и для МИКРОпроцессоров пришлось бы понижать частоту для защиты от перегрева. Опять же смотрим на графические процессоры - их частота объективно ниже, хотя греются похлеще основного процессора. Короче, "все придумали до нас" =)
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Ну вот это совершенно прямое и честное утверждение. Но зачем тогда было писать слово "архитектура" в названии темы ? Чтоб форумчане обратили внимание ? Мож попросите модераторов поправить на что-нибудь вроде "Косметическое "причёсывание" систем команд" ? Ну или что-нибудь в таком стиле.
В любом случае плохого в Вашем досуговом занятии ничего нет, так что удачно Вам продолжать сие.
И - что то я видимо недостаточно внимательно читал все Ваши сообщения - Вы уж выкинули из системы команд вызовы 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 не с потолка, а из практики написания эмуляции.
И 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 лет, мною логически много обосновано. Тем самым, совет о переименовании темы - хоть и уместен, но слишком поверхностен. Администрация форума сама пусть решает.
Прямо говоря, "по честноку" то бишь , так гораздо больше пользы было бы, ежели бы Вы занималсиь "причёсыванием" системы команд MicroVAX например - можно его советского аналога. Тогда была бы вполне реальная возможность проверить микрокоды прямо "в железе". ( С единственным небольшим ньюансом - микрокоманда "их" и нашего процессора - разные по длине. Но это не так уж и страшно )
_________________ < виртуальная "кнопочка" >--( WWW ) <- Убедительная просьба интересующимся старыми компьютерами типа РК86 - не пишите в теме в барахолке, пишите Ваши вопросы в ( лс ) пожалуйста
Также не вижу перспектив в наращивании последовательных шин. В связи с тем, что все упирается в частоты, будущее наверное за архитектурой параллельного включения процессоров, возможно даже в одну широкую шину.
Все с точностью до наоборот. Именно проблемы с синхронной работой параллельной шины приводит к необходимости использовать последовательные. То есть 16 последовательных шин позволяют поднять частоту заметно выше, чем может иметь одна 16-разрядная параллельная. Плюс к этому в современных архитектурах планируется широко использовать оптические способы передачи данных внутри кристалла. Патамушта в нынешних проектных нормах обеспечить внутрикристалльную коммуникацию становится предельно сложно. И отсюда возникают внешне необъяснимые ограничения на синхронизирующие и информационные связи модулей МК (или процессора). А вообще, тема отдает некоторой нафталиновостью. Архитектуры затачиваются под класс задач и технологии производства. Как уже говорилось ранее, кодировка операций занимает последнее место в приоритетах. Скорее она отражает построение дешифратора команд. Нынешней разрядной сетки командных слов за глаза и за уши хватает на любую архитектуру АЛУ и ЦП.
Чем 00 отличается от АА, от 45 или, скажем, от E6. Да, прямо скажем, ничем. Другое дело, как уже было указано, - дешифровка КОП. Отсюда и надо было скакать в своё время. И помнить о дуализме. А эмуляторы писать - пусть пишут другие под ваш суперпроцессор. В сторону: Intel напару с IBM нервно курят в сторонке.
Чем 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 и т.д.). Вина моя в том, что я подошёл к вопросу как эстет. Раз так уж… Тем более, интернет кишит "школьными" и "студенческими" проектами процессоров. Беда которых - полная практическая бесперспективность.
В моей концепции процессора - багаж программ и алгоритмов i8080/Z80/i8086… Да, без ретрансляции алгоритмы у меня не заработают. Но, алгоритмы деления, извлечения корня и черчение линий - портировал. Причём, с ассемблера Z80 переносил в x86-ассемблер Си-отладчика, а оттуда, как есть - в ассемблер собственного процессора. Занудство? Да! Но, как мальчишки, Вы можете понять, какой кайф, что это - работает!!!
А насчёт 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 имеет спец-префикс).
Представляемая концепция процессорного устройства базируется на переработанной системе команд процессора i8080 с полной утратой совместимости уровня машинных команд и с частично достигнутой совместимостью с ассемблером процессора i8086. ---------- Таблица системы команд процессора была расчитана под интуитивное восприятие на принципе ассоциативных предпосылок субъективного уровня с учитыванием реальной возможной частоты использования различных инструкций в построениях алгоритмов. Некоторые из инструкций, в силу морального устаревания и потерей актуальности, были изначально исключены или получили более комплексный код редкой комбинации обычных команд, чтобы не засорять таблицу и сохранять перспективу наращивания. Регистр статуса процессора был переорганизован и флажки АЛУ получили частичную связь на дешифратор команд с возможностью управлять периодом выполнения команд для явного объявления условно реактивных и ленивых участков программного кода. ---------- Инструкции: Система команд процессора =================== Дешифратор команд имеет 18 разрядов, имеющий условно разделённо-группированных восемь проименованных шин и каждая из них имеет своё назначение для дешифрации всех поддерживаемых архитектурой инструкций с перспективой явного наращивания. Всего набор команд представляется таблицей команд с восемью слоями и имеющих в своей структуре до восьми подслоёв, половина из которых доступна лишь основной программе высшего уровня привелегий, выполняющей роль ядра операционной среды. В состав процессора входит сверхоперативный контекстный файл с ёмкостью до 128 страниц, каждая из которых вмещает по 256 слов и обеспечивает сохранность всех значений регистров общего назначения независимо для каждой страницы контекста. Страница контекста имеет до 160 слов хранения операций реактивного исполнений, вызываемых трюковым способом из любого места программы и требующих как минимум от 1 такта на своё выполнение, позволяющих организовывать комплексные команды. ---------- Флаги: Регистр состояния процессора/АЛУ ===================== Регистр состояния FX является старшим AH в AX, разделён на два ниббла FH и FL. Старшим нибблом хранится индекс опционального регистра/указателя или итерации. Младшим нибблом отражается комбинация режима дешифратора инструкций с флажками результата действий команд АЛУ. Правилами постулатов исполнения вычислительных операций исключаются вариации нуля нечётного паритета или отрицательного нуля. Ноль нечётного паритета запрещает регистрирование результата выполнения потока дешифрируемых инструкций на период с декрементацией опционального регистра или итерации в старшем ниббле, позволяя опционально пропускать цепочку инструкций. Отрицательный ноль приостанавливает считывание следующих инструкций, организуя цикл на период с полной или условной декрементацией опционального регистра или итерации в старшем ниббле, позволяя опционально ставить цикл и режим ожидания. Через режим условного ожидания организуется возможность доступа к интерфейсным устройствам ввода/вывода или внешней шине состояния сигналов событий ресурсов, чтобы описывать алгоритмы своевременной обработки всех допускаемых прерываний. ---------- Обработка программных и аппаратных прерываний ========= Архитектурой процессора не предусматривается возможность оперативной реакции в режиме реального времени на любые внешние сигналы от периферии с генерацией по их запросам определённых прерываний на обращение к соответствующим процедурам. После включения ядра процессора и аппаратного сброса, управление передаётся на нулевой контекст программы по вектору 0xFF00 с возможностью прямого доступа ко всем ресурсам среды системы, всем контекстным файлам и к регистрам управления. В обязанности кода основного процесса входит необходимость настройки периферии и соответствующего реагирования на любые внешние сигналы с её стороны, а также организации поддержки интерфейса с другим прикладным программным обеспечением. Процесс ядра системы не имеет возможность непосредственного опроса внешних шин и считывания их состояния без организации исполнения кода прикладного уровня с поддержанием его нормального исполнения и надлежащего предоставления ресурсов. ---------- Доступ к внешним устройствам и регистрам контекстного файла ======================= Системой команд не предусматриваются непосредственные команды доступа к портам ввода/вывода для взаимодействия с устройствами периферии или доступа к ячейкам контекстного файла и управляющим регистрам представления контекстной проекции. Подобные операции находятся за пределами области задач прикладного уровня и не засоряют таблицу команд как специализированные инструкции, используемые крайне редко в зонах временной необходимости сервисных процедур операционной системы. Процессором имеется достаточное количество префиксов для организации трюкового достижения необходимых системных ресурсов в рамках кода операционной системы и ограниченного контролируемого прикладного трюкового доступа к нужным ресурсам. В момент попытки доступа приложения к порту ввода/вывода, исполнение программы временно приостанавливается и управление передаётся ядру системы с загрузкой в историю регистра-приёмника индекса порта, байта данных и режимом доступа в CF. ---------- Регистр селектора контекста (CS - Context Switch Register) ====================== Для непосредственного доступа к контексту любой имеющейся прикладной задачи на уровне системного процесса доступен регистр CS, служащего переключателем задач в системной среде и управляющего привелегиями для текущего активного процесса. Базовая реализация процессора поддерживает от трёх независимых контекстов, под которыми может выполняться непосредственно код системного ядра, код диспетчера системных ресурсов с аппаратным интерфейсом и другой код прикладной программы. Контекст ядра всегда имеет индекс с базой 0, диспетчерам ресурсов определяются контексты с индексами от 127 до 100 в сторону уменьшения номера, тогда как все приложения индексируются контекстами от 1 до 99 в сторону возрастания номеров. _____ 00000000 0 :База(0) - Системный код с высоким уровнем привелегий. 0XXXXXXX 1-99 :База(1) - Прикладной код с низким уровнем привелегий. 011XXXXX 100-127:База(127)-Средний уровень диспетчера системных ресурсов. 1XXXXXXX 128-255:Зеркала контекста №0 под высоким системным уровнем привелегий ---------- Счётчик выдержки исполнения прикладного кода (TX - Ticks Counter: TL & TH) ===================== Старший бит регистра CS управляет блокировкой прохождения тактов к регистру TX и на уровне приложений ведётся обратный отсчёт, окончание которого установит в CS бит блокировки счёта с переключением контекста в высокий системный уровень. Если при переключении с ядра к приложению счётчик TX был обнулён, ни один байт прикладного кода не будет выполнен и управление получит вновь ядро с возвратом кода состояния внешней периферийной шины через аккумклятор и флаг переноса CF. Если в момент переключения на контекст приложения счётчик TX готов отсчитать 1 такт, будет выполнена одна единственная операция приложения и управление снова получит ядро, что позволяет организовывать пошаговый режим отладчика программ.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Примерная трюковая цепочка ;;; Макрос псевдонима мнемоники с описанием ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; MOV [0],DL ;;; Запись индекса проекции контекста HLT DL ; Указываем регистр источника индекса WAIT ; Приступаем к ожиданию системной операции HLT ; Инструкция работает лишь в проекции системы ;;;;;;; MOV DL,[0] ;;; Чтение индекса проекции контекста HLT ; Выбираем индекс считываемого регистра WAIT ; Приступаем к ожиданию системной операции HLT DL ; Считываем в регистр индекс проекции ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; MOV DL,[DL] ;;; Читаем байт файла контекста HLT DL ; Указываем принимающий регистр WAIT ; Готовимся читать данные HLT DL ; В регистр DL ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; MOV [DL],AL ;;; Пишем байт в файл контекста HLT DL ; Указываем регистр выбора ячейки WAIT ; Готовимся писать данные HLT AL ; в ячейку DL из регистра AL ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; MOV DL,[1] ;;; Читаем байт регистра контроля HLT 1 ; Указываем индекс считываемого регистра WAIT ; Готовимся читать данные HLT DL ; Указываем принимающий регистр ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; MOV [1],DL ;;; Пишем байт в регистр контроля HLT DL ; в ячейку из регистра DL WAIT ; Готовимся писать данные HLT 1 ; Указываем регистр контроля ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; IN DH ;;; Читаем данные с порта HLT 1 ; Вибираем индекс регистра BH с индексом порта WAIT ; Готовимся читать данные HLT 1 ; В регистр BH ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; OUT [DH],CH ;;; Пишем данные в порт HLT 1 ; Выбираем регистр BH с записуемым байтом WAIT ; Готовимся писать данные HLT 2 ; в порт CH из регистра BH ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Примерный набросок кода запуска управляющего ядра операционной системы ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ORG 0xFEFB ; Следующий макрос занимает 5 байтов KERNEL: ;;;;;;;;;;;;;;;;;;;;;;;;; Переключатель контекста на прикладной код .yield: MOV [0],AL ; Макрос переключения контекста регистром CR0 ;HLT AL ; Регистр AL указывает контекст/принимает код ;WAIT ; JMP $ - Переход в условный цикл ;HLT 0 ; HLT - Привелегированная операция для CR[0] ;;;;;;;;;;;;;;;;;;;;;;;;; ; Здесь располагается селектор с пропуском до 7 инструкций и передачей ; управления соответствующей ситуации процедуре .body: ;;;;;;;;;;;;;;;;;;;;;;;;; Тело обработчика прерываний - адрес : FF00h JMP .overhead ; Запрос к стандартному API JMP .acclaim ; Обращение к программным прерываниям INT 0-79 JMP .buffer ; Буферная зона - прослойка диспетчера памяти JMP .context ; Диспетчер переключения контекстов процессов JMP .device ; Запрос ко внешнему устройству ввода/вывода JMP .error ; Обработчик программных/аппаратных ошибок JMP .force ; Внешние форсированные события/прерывания JMP .garret ; Загрузочная область поверхностного уровня .context: ;;;;;;;;;;;;;;;;; Тело диспетчера контекста XOR AL,AL ; Подготавливаем регистр к чтению регистра CR HLT AL ; Определяем его как приёмник WAIT ; Переход в условный цикл HLT 7 ; Считываем содержимое CR[7] в AL ;;; ;;; ;;; ; Оперативные действия с контекстом MOV AL,0x01 ; Выставляем индекс выбираемого контекста CMP AL,AL ; Сброс флага переноса CF CMC ; Устанавливаем флаг, если требуется протокол JMP .yield ; .device: ;;;;;;;;;;;;;;;;; Тело диспетчера периферии
Выше я уже писал про "Механизмы обработки прерываний":
Код:
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. А это - шаг к стабильности.
Понимaю, что многим до лампочки на кустарные "фантомные" кастомные прожэкты Тут несколько мыслей покоя не даёт. И справиться не могу никак…
Многозадачность Каждая из задач должна иметь как минимум 256 оперативных регистров. Из которых 64 - РОН, 32 - указатели, 160 - программируемые инструкции. Естественно, даже в рамках современных ПЛИС - это очень дорогое удовольствие. Поэтому, считаю, что по-настоящему оперативно доступных регистров должно быть в разы меньше, тогда как остальные могут быть доступны посредством использования любого удобного современного скоростного сетевого протокола и подгружаться динамически. Но, даже в эмуляции эти динамические регистровые файлы и окна работают очень медленно и никак не могу справиться с этим.Спойлер
Код:
Регистры Общего Назначения (РОН) ============== Каждой исполняемой задаче доступен собственный независимый набор регистров, из которых можно выделить несколько особенных, имеющих механизмы контроля ошибок, автоматического инкремента/декремента и организации ленивых вычислений/циклов. Так, регистры BH:BL / CH:CL / DH:DL составляют набор регистровых пар BX/CX/DX, позволяющих организовывать косвенную и индексную адресацию для доступа к любой из всех ячеек предоставляемой операционной средой памяти в оперативном режиме. Несколько иначе организован регистр аккумулятора AL, имеющий условную половину AH(FX) косвенно-условной доступности, позволяющего обеспечивать условные петли и безусловные циклы, а также и опциональные линейные селекторы или вычисления. +----------+ +----------+ +----------+ +----------+ | AX | | BX | | CX | | DX | +---------+------+ +--------+--------+ +--------+--------+ +--------+--------+ | AH(FX) | AL | | BH | BL | | CH | CL | | DH | DL | +----+----+------+ +--------+--------+ +--------+--------+ +--------+--------+ | FH | FL | | == | == \__________ |0:--|0000: ------- \_____ |1:BH|0001:-- -- ZF # Zeroed result | |2:CH|0010:-- CF -- # Carry Flag | |3:DH|0011:-- CF ZF # Zero with Carry | |4:AL|0100:PF -- -- # Odd Parity Flag | |5:BL|0101:{SKIP FH}# Skip mode (register counter / x1..x7 times) | |6:CL|0110:PF CF -- # Odd Parity with Carry | |7:DL|0111:{SKIP FH}# Skip mode (register counter / x1..x7 times) | |8:--|1000:SF -- -- # Signed result | |9:x1|1001:{LOOP FH}# Loop mode (register counter / x1..x7 times) | |A:x2|1010:SF CF -- # Signed result with Carry | |B:x3|1011:{LOOP FH}# Loop mode (register counter / x1..x7 times) | |C:..|1100:SF PF -- # Signed result with odd Parity | |D:BX|1101:{ ----- }# | |E:CX|1110:SF PF CF # Signed result with odd Parity and Carry | |F:DX|1111:{WAIT FH}# Wait mode (register counter / x1..x7 times) | +----+----------
_____ Регистровые указатели === Указатель инструкций IP имеет опциональный указатель JP, у стековых указателей SP и BP младший бит имеет опциональное назначение для отслеживания критических ситуаций или управления автоматическим инкрементом/декрементом значений SI/DI. +----------+ +----------+-+ +----------+-+ +----------+ |______ IP ______| | SP /EF| | BP /FF| |_____ SI/DI _____| | \__/ | | +-----+ / | | +-----+ / | | \++|--/ | | JP | | /Error-Flag| | /Fault-Flag| |Auto-Inc|Auto-Dec| +----------+ | / /increment| +-----+----------+ +----------+ +----+----------+
Режим ПДП Задумывается всё так, чтобы процессор сам мог бы работать как ПДП. Так как расчитывается, что всего может быть запущено до 128 процессов, то несколько могут работать в режиме ПДП, так как это гораздо удобнее любого готового контролера ПДП. У меня же стартует всё процессом №0 с максимальными привелегиями, тогда как процессы 1-99 считаются прикладными. Процессы 100-127 расчитаны как сервисные под "демонов". Например, по приходу запроса к ПДП процессор должен приостановить текущую задачу (как при IRQ) и выполнять команды ПДП-обработчика (не как IRQ) в особом режиме: Брать из внутренней статической памяти цепочку заготовленных команд, исполнение которых требует от 1 такта на операцию + задержки на чтение/запись памяти. Зачем такое? Чем программировать внешний ПДП, можно вполне обойтись внутренними микрокомандами, как регенератор памяти Z80. Давно хотел как-то подойти к этой проблеме, но не знал, с какого бока подойти. Тем более, критические секции прикладного кода у меня имеют пачку NOP 1-7 для организации синхронизированной задержки. Тем самым, вместо NOP процессор мог бы вполне выполнять "прозрачную" для текущей задачи задержку. Только под видом "холостой операции" выполнять операции ПДП-потока. В этом случае, ПДП-задержки стали бы и вовсе незаметными… А 28 "демонов" - достаточное количество, чтобы обеспечить нужное число потоков…Спойлер
Код:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Примеры инструкций с расширением их возможностей опциональными битами ;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; MOV AL,[DI+1] ; Считывает данные с базовым смещением, ; работает во всех стандартных режимах (EF==0) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; MOV AL,[DI+1] ; Считывает данные без смещения, но производит ; пост-инкремент указателя, лишь когда (EF==1)
Арифметика Операций умножения/деления как бы и нет. Есть лишь цикл LOOP/WAIT 1..255 + ADD/SUB-инструкция. Понятно, что умножать и делить циклом - крайне медленно. Однако, введена маленькая хитрость: Если подключен внешний сопроцессор (специальный) с поддержкой этих операций, то он просто перехватит из потока команд эти комбинации LOOP+ADD и вычислит всё сам за несколько тактов, отправив в регистровый файл верное значение. А сама программа так же имеет опциональный статус при наличии аппаратной поддержки.Спойлер
Код:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Примеры трюковых цепочек для выполнения вычислений с проверкой ускорения ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; MUL AL,CH,CL ; Умножение с суммированием: AL+=CH*CL HLT CL ; Указываем регистр множителя CL WAIT ; Готовимся к вычислению ADD AL,CH ; Приближаемся к результату через множимое CH AND CL,CL ; Проверка участия регистра множителя в цикле JZ .software ; Если он обнулён - аппаратной поддержки нет ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;; DIV AL,CH,CL ; Деление: CL=255 :: CL-=AL/CH HLT CL ; Указываем регистр дополненного частного CL WAIT ; Готовимся к вычислению SUB AL,CH ; Приближаемся к результату через делитель CH JC .software ; Если признак CF - аппаратной поддержки нет
Дешифратор Шина дешифратора команд пока насчитывает порядка 18 пар (18 прямых и 18 инверсных) сигналов, к которым должны подключаться 60 инструкционных узлов через вентили логики "И". Почему 18, так много? Здесь 8 - сам код инструкции, а 10 - её статус в программе: Является ли код префиксом; Является ли код замыканием префикса; Является ли код замыканием цепочки; Является ли инструкция частью линейного цикла; Является ли инструкция частью предзагруженной цепочки цикла; и т.д… Чем городить в некоторых инструкциях блоки условной перепроверки подстатуса и удлинять цепь с задержками, решено было просто расширить шину дешифрации. Этим и достигается, что три обыкновенных инструкции в нестандартном объединении образуют одну "трюковую" или "системную" инструкцию (например, <B8 FE 56> => WAIT + MOV BL,CL => OUT BL,CL).
P.S.: К сожалению, реализовать на макетках собственную задумку считаю нереально - вычислительная "мощность" процессора через чур большая для сборки на коленке ради забавы.
Я бы еще раз предложил Вам ознакомиться с современными архитектурами ядер. Прямой доступ в память уже давно делается внутрицикловым, то есть для транзакций используются те такты цикла, где нет обращения к шине данных/адреса, и/или для DMA использована отдельная шина. Многозадачность при единственном ядре (псевдомногозадачность) в состоянии разделять ресурсы программными методами, что и реализовано в любой ОСРВ. Аппаратное жесткое разделение - совершенно беспонтовая вещь, патамушта в реальных задачах ресурсы используют ОДНОВРЕМЕННО несколько задач (поскольку этого требует алгоритм) и передача ресурса/данных из одной задачи в другую станет дополнительной тратой времени и самих этих ресурсов.
Многозадачность на физическом уровне в разы лучше. Это обусловлено тем, что постоянно выгружать-загружать состояние регистров для смены задачи - тоже время и ресурс. Да, можно в рамках ОС частоту смены задач уменьшить, но тогда начинают страдать те задачи, которые по сути своей требуют реальное время и не особо комфортно живут в фоновом режиме на остатки производительности. Например, архиватору хорошо живется в остатках и ему важно суммарное время, когда графическому (и не только) движку реального времени куда комфортнее сидеть в ядре монопольно на постоянной основе. Частично вроде как это решают приоритеты в ОС, но это же заплатка и монополии все равно не даст, плюс сама ОС у любого условно монопольного процесса все равно кушает определенный ресурс.
Так что я склоняюсь к тому, что 16+ ядер - это наше всё. Если задача в ОС классифицирована как фоновая, то сидеть ей с собратьями на одном ядре под контролем ОС. Если задача серьезная, то ей отдельное ядро монопольно. Контролировать ее процесс или прервать его можно через инструмент аппаратный, но не ворующий такты у самого процесса на том ядре, где он сидит. Это выполнимо, поэтому возможность ОС прервать этот процесс или проследить за ним - остается. Если задача уже имеет код, оптимизированный под монопольное использование нескольких ядер (сама ее программа осуществляет взаимодействие между ядрами, что было реализовано компилятором и\или программистами на уровне кода), то можно ей предоставить их. Таким образом, в устройстве несколько тяжелых программ вообще не будут оказывать друг на друга влияние, а операционная система сможет спокойно расходовать и распределять ресурс без намеков на подвисание. Да и пусть эти ядра будут дохленькие по сравнению с топами - все равно это окупится стабильностью и отсутствием лишних переключений.
Многозадачность на физическом уровне в разы лучше.
В разы? При одном ядре на смену контекста требуется десяток другой машциклов. У Вас процесс занимает соизмеримое время? Во первых, смена контекста современными архитектурами так же поддерживается на аппаратном уровне, а получить что то более рациональное гораздо проще увеличением ядер. Тем более, что ядра не слишком увеличивают площадь кристалла. ОЗУ, флеш и шины занимают больше места.
Я бы еще раз предложил Вам ознакомиться с современными архитектурами ядер. Прямой доступ в память уже давно делается внутрицикловым, то есть для транзакций используются те такты цикла, где нет обращения к шине данных/адреса, и/или для DMA использована отдельная шина. Многозадачность при единственном ядре (псевдомногозадачность) в состоянии разделять ресурсы программными методами, что и реализовано в любой ОСРВ. Аппаратное жесткое разделение - совершенно беспонтовая вещь, патамушта в реальных задачах ресурсы используют ОДНОВРЕМЕННО несколько задач (поскольку этого требует алгоритм) и передача ресурса/данных из одной задачи в другую станет дополнительной тратой времени и самих этих ресурсов.
Хoчу подчеркнуть, что собственную задумку двигаю в духе ещё прошлой эпохи. Будучи школьником, прочитал, что Z80 имеет двойной набор регистров для быстрого переключения во время прерывания. Тем самым, как бы псевдо-мультизадачность Потому и действую сейчас так же: Ядро - одно, переключение между задачами - за такт… Не для АЭС разрабатываю же концепцию, а баловства ради. Но, не так, чтобы с коленки пнуть и заработало мигалками. А чтобы нечто помощнее бы и перспективнее. В смысле - домашнего исследования: Попытаться написать и операционку, и чтобы свои плюшки имелись уникальные. Вот например, сочетание LOOP 5 + CALL Fn1 переключает процессор от пятикратного вызова функции к вызову той же функции, но с режимом пропуска 5 первых её инструкций. Что - очень интересно: Если подпрограмму начинать семью командами JMP, получим ON-GOTO переключатель. А это открывает, опять-таки, уникальные возможности. (К слову: 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-плюшкам )
Понимаю, вот, вы хотите сказать, что в конечном итоге у меня должно скомпилироваться ядро Linux, запуститься оконный интерфейс с MP4-проигрывателем и декодером спутниковой трансляции. Чтобы это в школе ребяткам показать и удивить. Зачем??? Нет, к этому я не стремлюсь. Думаю, цель в том, чтобы к очень бородатым дядям из НИИ подойти и сказать, мол, вот я - чудак, их архитектуру 60-х перелопатил и сделал 8-битное подобие Z80, полностью несовместимое ни с чем. Потратил 20 лет на это. Тупо! Чтобы они, покрутив пальцем у виска, всё же, задались вопросом "А смысл?". Весь код - мой (6 тысяч строк), плюшки - свои. Кругом - ОпенСорс, бери и подтягивай. Но, зачем? Просто, хочу исследовать, каким бы мог быть процессор i8080, если бы в 70-ых я бы с пелёнок сидел в самой Intel и царапал бы кристалл чупачупсом
P.S.: Иначе говоря - творческое исследование ради самого процесса разработки. Не ждите от меня "Ура, я запустил Debian в собственном процессоре!". Скорее, можете ожидать "LOOP 3 + MOV AL,1 -> оказывается плюшка!"… Кстати, вот набросок электрической шины дешифратора попробовал вообразить:Спойлер
Можно расширить шину инверсией, чтобы упростить вентиля (К155ЛА2 - 8 входов, но есть же и ЛА19 на 12 входов), число которых равно числу всех команд - около 60: │││││││││││││││││││ │││││││││││││││││││ ┌───┐ │││││▐┼┼┼┼┼┼┼┼┼┼┼┼┼─┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼────┤ & │ ││││││▐┼┼┼┼┼┼┼┼┼┼┼┼─┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼────┤ │ │││││││▐┼┼┼┼┼┼┼┼┼┼┼─┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼────┤ │ │││││││││││││││││││ │││││││││││▐┼┼┼┼┼┼┼────┤ │ ││││││││││││▐┼┼┼┼┼┼─┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼────┤ │ │││││││││││││││││││ │││││││││││││▐┼┼┼┼┼────┤ O────> XXXX000XXX10111XXX|JCND$X $+$UIB:CND$X?IP(IP()+$A):0//Branching if CND$X! │││││││││││││││││││ ││││││││││││││▐┼┼┼┼────┤ │ │││││││││││││││││││ │││││││││││││││▐┼┼┼────┤ │ │││││││││││││││││││ │││││││││││││││││││ └───┘
Во первых, смена контекста современными архитектурами так же поддерживается на аппаратном уровне, а получить что то более рациональное гораздо проще увеличением ядер. Тем более, что ядра не слишком увеличивают площадь кристалла. ОЗУ, флеш и шины занимают больше места.
Любопытно, как вы на ПК совместите осциллограф (допустим, программный, фейковый, по отслеживанию одной ячейки оперативной памяти с частотой 500 мегагерц) и одновременно работающий архиватор. Когда у вас это получится, быстродействие архиватора вас весьма удивит.
Причем тут ПК? Насколько я понял, автор рассматривает RISC-архитектуру....
Знaчит, к сожалению, ввёл всех в заблуждение я… Когда 15 лет назад ознакомился поверхностно с RISC-архитектурой, но более глубже, понял, что только и делал, что расписывал шаблоны именно CISC'ов. Видно, опыт работы с РЛК, ZX и т.п. воспитал меня именно на CISC'ах, а RISC'и я до сих пор до конца не понимаю (хотя изучал 6502)… MISC понимаю и то больше.
P.S.: Может у меня получается гибридная архитектура? Типа CISC, но с RISC-плюшками? Озаглавил же прожэкт как Rebused Instructions Set Computer (компьютер ребусного набора команд )…
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 28
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Раз так уж…
)
