самодельный многозадачный процессор

[pfgx]

Q0 = in0
Q1 = 0
Q2 = in1 and ~in0
Q3 = (in1 xor in2) and in0
Уже меньше

Или же in = 256*H+L
in^2 = 65536*H^2 + L^2 + 512*H*L
8-битные умножения, сдвиги и сложение.

А схема, умножающая "в столбик" за 32/16/8... тактов, не быстрее будет работать?

[Mixa64]

Длинный заход какой-то… Не проще ли сразу (x+y)^2-(x-y)^2=4xy ?

[Mixa64]

Тема пошла в направлении "Сделай сам ЦПС"

[petrenko]

Длинный заход какой-то… Не проще ли сразу (x+y)^2-(x-y)^2=4xy ?

Так собственно я это и разъяснял ... подробно
А на блок-схеме "мои" X и Y и А и Б будут широкими стрелочками от "слоя" к "слою".
Первый слой - регистры, куда защёлкиваются X и Y (~13нс )
Второй - сумматор и вычитатель. (~24нс )
Третий - "квадраторы". (~60нс )
Четвёртый - вычитатель. (~24нс )
Пятый - регистры результата. (~13нс )

Конечно, продолжайте, с этого места. А то Вы вечно норовите сказать "А" и не договорить "Б".
"Зогатки во тьме..."? (с)

Действительно, прям таки ёжик в тумане..
Ладно.
Собственно в реале были всё ж таки со знаком числа ( и знаки обрабатывались отдельно ), а стало быть длина была чуть чуть меньше - всего 15 бит.
И теперь открываю самую тайну древности : для 15 бит декомпозиция возможна !
( полуавтоматически - приходилось "помогать" программке )
И "квадраторы" вм³щуються в 556рт1 !
( Но сие я обнаружил позже, а вначале мне пришлось ограничиться 12-ю битами, впихивая "квадраторы" в несколько 556рт7 - весьма непросто было "достать", что их, что потом рт1 )

[Lavr]

Понятно... в общем - Вы добились аппаратной компактности, но достигнуто это было увеличением
времени выполнения умножения, что и следовало ожидать...

А то я уж напрягся, ожидал рассказа про функции регулярные, гладкие, сколько-раз-надо
дифференцируемые по Коши-Даламберу, разложимые в конечную сумму степенных функций
в форме обрезанного ряда Тейлора.

Но Вы не стали меня этим пугать... (выдохнул с облегчением)...

[petrenko]

Ну дык... Я ж добрый.
Что ж я буду людей пугать обрезанным Тейлором.

А делаю и делал всегда изходя из наличия деталюшек.
Привычка такая..

Вот если бы во времена те можно было б "достать" например Am9511 , то стал бы я городулю городить ?(риторический)
Кстати у нас этот Am9511 обсуждали.

А разложение в ряды, помнится, было в некоторых калькуляторах для вычисления некоторых функций..

[petrenko]

Ну-сс.. Як там успехи у T.S. ?

Я вот между делом подумал : хоть и не страна советов, но можливо ж посоветовать.. Советую :

Название темы какое ? Верно, "многозадачный ..".
А что важно для этого ?
Быстрое переключение.
Как достичь ? Несложно догадаться - регистров как можно меньше и "pushall" как можно быстрее.
К тому же почему то очень хочется "push SP".. Но как ? Самое подходящее ( IMHO ) это два SP - а именно SPобычный и SP"пультовой" - то есть "стек стеков" и ,разумеется, разполагается в защищённой зоне памяти.
Набор регистров - каково наменьшее достаточное количество ?
История показывает, что кроме PC(или IP -как ни обзови суть та же ) треба SP( обычный ) и IX == индексный/адресный
Также не обойтись без регистров временного хранения - но их запоминать при переключениях, понятно, не треба.
При 16-битном АЛУ советую PC , IX , SPобычный и SP"пультовой" сделать 32-х-битными - аппаратно не так уж и много - всего по 4 ИМС на регистр, а преимущества очевидны - снимаются многие ограничения и убираются многие "узкие места".
Регистры временного хранения по ширине соответствуют хранимому - то есть в основном 16-битные.
И ,наконец, самый заковыристый вопрос. Регистр флагов.
Если изходить из идеи, что для УстройстваУправления АЛУ является таким же внешним микроадресуемым субъектом, как и регистры и др. узлы процессора, то FR надо бы считать программно-доступной частью регистра временного хранения выходного операнда и для изключения лишних "push" при переключениях, сохранять заодно с операндом в памяти ( подразумеваем, что начальная область в рабочем сегменте памяти у нас изпользуется в качестве РОН ). Собственно в случае с целыми числами со знаком в большинстве случаев с флагом "знак" именно так и произходит. Флаги "чётность" и "нуль" можно вообще не сохранять в случае, если добавить чуток аппаратного в АЛУ . А вот "переполнение" желательно весьма и весьма. Таким образом значащая часть у нас ещё уменьшается и становится 14 бит. Что тоже не новость, такие форматы были в некоторых машинках.

Вот как то так.. А там уж T.S. решать, пригодятся ли ему советы..

[Lavr]

Быстрое переключение.
Как достичь ? Несложно догадаться - регистров как можно меньше и "pushall" как можно быстрее.

Регистров - как можно больше и менять их файлами, как у z80, у которого файлов всего 2.
При этом никаких проблем с SP.
И догадываться даже не надо. Хорошо описано в книге:
Панфилов Д.И. Преснухин Д.Л. Нестеров П.В. Шаньгин В.Ф. Горбунов В.Л. Костин А.Е.
“Микропроцессоры. 1. Архитектура и проектирование микроЭВМ. Организация
вычислительных процессов” 320 стр.

Надо только внимательно почитать, и не ломиться в открытую дверь...

Я сам, было, ломился, да приостыл...

[petrenko]

.. Регистров - как можно больше и менять их файлами ..

А я даже не буду спорить. "Прикольно", правда ?

Читал я книги, читал ..

Вот, знаете, в "послайсенных" на n-битные секции процессорных комплектах РОН "кусочками" были в секциях, а в порезанных на функциональные узлы процессорных комплектах РОН в виде отдельных ИМС были ,да и иногда вообще не из комплекта, а просто из другой серии брали ОЗУ.
Представим, что Ваша идея реализуется и решено сделать .. ну ... например 128 РОН ..
И переключать их "файлами" (- ежели Вам такой термин приглянулся).
Или "страницами" ( -кому то другому, возможно, так удобнее называть .. )
Ну а если вдруг реализация что "Вашей", что "моей" идеи окажется одинаковой ?
Что тогда ? Зря окажется спорили и ни о чём при том.
Понимаете теперь, почему я даже не спорю ?
P.S. Вообще то довести два противоположных направления решения задачи и объединить их в одно - это и есть изобретение прям таки по Альтшуллеру.
{ РОН сделать как можно больше и РОН сделать как можно меньше } -> { РОН любого размера и одновременно РОН вовсе отсутствует }
Классика ТРИЗ однако... Патент на двоих нам дадут ?

[Lavr]

Представим, что Ваша идея реализуется и решено сделать .. ну ... например 128 РОН ..

Поскольку разговор совсем не предметный. И вряд ли топикстартер реализует свою идею в железе,
то "Вы помечтали, и я конкретно пофантазировал" ("Вы пошутили и я посмеялся" (с).
В рамках этой парадигмы "моё кунфу сильнее"...
Поскольку переключение регистровых файлов гораздо шустрее любого "pushall" - даже предмета
для спора нет!

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

И если для Вас так заманчиво слово "патент", то проведите хотя бы один серьёзный патентный поиск
на чистоту технического решения. Вас многое удивит, а многое, возможно, и огорчит...


P.S. А термин "файл" не мне приглянулся, а почему-то стал широко использоваться в литературе:"регистровый файл", "стековый файл". С учетом, что "файл" - это папка, то почему бы и нет? Хотя, если быть честным, мне-то как раз и не приглянулся.

[petrenko]

Эх, жаль, шуткуем, классная развлекуха у нас тут, а "в железе" ни у кого руки не доходят.. Очень жаль..

А за патент я тож пошутил.
Известное дело, есть ужо такой.
В одной из глав Шевкопляс как раз описывал нечто.

В общем предлагаю выбрать число РОН равным 119 ( плюс место для полей, которые сохраняются при переключении ) ,а общее количество таких "файлов"/"страниц" 4096 .
Выйдет как раз "ящичек с файлами" на мегабайт общего объёма.
( что сопоставимо с кэш многих уже "старых" на сегодня процессоров. )
Полагаю вполне возможно соорудить ОЗУ с организацией 524288*16 ?
Единственное вынужденное добавление - регистр номера текущего "файла"/"страницы".

Отличие такого решения по сути лишь в том, что "адресное пространство" этого "ящичка с файлами" отдельное от общего адресного пространства и переключение действительно быстрее ровнёхонько на время заталкивания в стек трёх ~ четырёх регистров.

P.S. А можно ли Ваше "кунг-фу" применить с пользой - для т3-29 ?
Я Вам даже лс с просьбой писал..
( У нас ну никак не чинится пр2 - все 40 ИМС наш главный товарищ перепаял.. и никак .. )

[Lavr]

А можно ли Ваше "кунг-фу" применить с пользой - для т3-29 ?
Я Вам даже лс с просьбой писал..

Ну, поскольку Вы ответы на свои просьбы месяцами не забираете из лс,
то я их далее воспринимаю как мимолётные и несерьёзные.
Хотя ответа до сих пор и не удалил.

[petrenko]

Ой, не заметил..

Ну ежели хоть что подскажете - заранее спасибо.


Да, вот только что сообразил какой недостаток есть у "файла регистров"- негибкость - всегда один размер, а если разполагать в общем адресном пространстве, то можно менять в зависимости от потребностей. Но чуток медленнее переключение.

[Lavr]

Чисто в плане "помечтать". Ваш "pushall" и смена файла регистров по размеру - одинаковые операции.
Но pushall - обращение к памяти, а смена файла регистров - мгновенная операция на кристалле.
Я чисто из таких соображений рассматриваю эти вещи.

А со схемотехникой Т3-29 я так и не знаком. Ничего сказать конкретного не могу, а сочинять не буду.

Озвученная же мной идея в книге выпуска 1986 года иллюстрировалась вот так:



Мне тогда и 8 файлов казались слишком бредовым решением...
Но сейчас-то уровень технологий несравнимо иной!

[petrenko]

Чисто в плане "помечтать". Ваш "pushall" и смена файла регистров по размеру - одинаковые операции.
Но pushall - обращение к памяти, а смена файла регистров - мгновенная операция на кристалле.

Ну мгновенного ничего не бывает, это явная литературная гипербола.
А ежели и обращение к памяти для "заталкивания" SPобычного ( с декрементом SP"пультового" одновременно в том же цикле ) и изменение {bank¹reg} одинаково за один цикл делаются, то вся разница будет изключительно в 6-и (из 8-и) циклах команды pushall
( в 1-ом приём оп.кода switchcontext ,во 2&3 , 4&5 , 6&7 выполнение микрокоманд push IX , push PC , privelegedpushSP , в 8-ом privelegedload PC )
В общем выбор за разработчиком - или быстрее на 6 циклов или большая гибкость.

Мне тогда и 8 файлов казались слишком бредовым решением...
Но сейчас-то уровень технологий несравнимо иной!

Вот вот.
И 4096-уровневая выглядит не таким уж бредовым..

А вообще - да, чисто помечтать, ибо неизвестно, будет ли кто сие делать.