Форум РадиоКот

Вы шутите?

Как видите, не шучу. Запутанность записи в порт привела к тому, что я, глядя мимоходом, не понял, что там вообще делается, но на автомате предположил, что регистр надо сохранить.

Я вынужден требовать амнистии и презумции невиновности.

1. Это мой Первый практически реализованный процессор с работающиим эмулятором, сносным ассемблером и демо-программ (до этого все варианты процов проваливались ещё в теории)
2. Это мой Первый практически шаг, хотя в процессорах я понимаю не больше прикладного ламера
3. Этот проект не расчитан как коммерческий ход. И не думаю, что протянет дольше, чем мне наскучит. Тем самым, продавать собственные партии FPGA-процессоров я не планирую

Извиняйте. Вы подумаете, что Ваши аргументы - как о стенку горох.
Нет, какрас таки я задумался ввести переключатель режимов доступа к служебным регистрам и к портам. Как в x86: Ring#3 - пользовательский уровень через трюки со стеком. Ring#0 - проекция портов в параграф страницы памяти.

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

О-о-о... Зачеееем...

Просто сделать одно линейное адресное пространство для всего, а разграничение прав делать через MMU.

Ммм... У самого есть желание сделать собственный процессор. только не на ПЛИС, и не программную эмуляцию. Хочу именно платы с логическими микрами. На тех же К155... Пока что нашёл более-мелее реалистичный вариант. MC14500B. От моторолла. даташит легко гуглится... Я думаю, с этого можно начать. Даже есть наработки по схемам... Если у кого есть такое же глупое но странное желание, с радостью поделюсь. Ну и если есть чем поделиться -- с интересом выслушаю...

YS писал(а):О-о-о... Зачеееем...

Просто сделать одно линейное адресное пространство для всего, а разграничение прав делать через MMU.

Линейное? Уместить всё в 64кб??? Нереально. Каждый байт на счету (наверно, клоузтрофобия из-за распределения УВВ в РК-86 действует - аллергия на порты, пожирающие адресное пространство).

просто КОТ писал(а):Ммм... У самого есть желание сделать собственный процессор. только не на ПЛИС, и не программную эмуляцию. Хочу именно платы с логическими микрами. На тех же К155... Пока что нашёл более-мелее реалистичный вариант. MC14500B. От моторолла. даташит легко гуглится... Я думаю, с этого можно начать. Даже есть наработки по схемам... Если у кого есть такое же глупое но странное желание, с радостью поделюсь. Ну и если есть чем поделиться -- с интересом выслушаю...

Имел бы возможность держать паяльник в руках - давно бы практическое собрал.

Я наоборот за построение внутри ПЛИС. На хрена тебе эта плата с кучей корпусов? От проца в ПЛИС еще будет хоть какой-то толк.. Возможно где-то в своей разработке и применишь, цены на ПЛИС уже не так огорчают

Да не в цене дело. Просто...Ммм.... как бы это сказать... Кайфа не получу? Я программист такой себе... Начинающий. Для меня всё оно одинаково. Корпус на много ног и что-то программное внутри... А ПЛИС там или оригинальный проц... как я узнаю?

А так... тут какая-то разработка, и совсем другой вид. Особенно если КМ155, в керамике...

Линейное? Уместить всё в 64кб?

А зачем делать его равным 64 кБ? Почему не больше?

YS писал(а):А зачем делать его равным 64 кБ? Почему не больше?

Вопрос, конечно, интересный. Но, есть некоторая концепция.

Например, процедура вывода символа на экран - PutChar(accumulator). Как её вызвать?
Ясное дело, классическим CALL PutChar. Но это на уровне системы. А т.к. проекции памяти BIOS (ROM/RAM) в пространство приложения не предусмотрено, выполняется это таким образом: *(char *)PutChar = ascii. Таким образом, весь API переходит в слой портов виртуальных УВВ.

Ещё пример: Указатель стека обнулён и следом идёт операция CALL. Есть идеи вариантов рефлексов процессора?
A) SP "провернётся" в 0FFFEh;
B) Исключительность ситуации крэшнит всю программу.

Ответ таков:
C) Исключение без креша. Как и трюки с портами, здесь: нулевой стек + вызов подпрограммы = вызов системной подпрограммы. Обращение к API.

Бред? Жуть?
Какрас-таки корни идут из моей OS для i386: У Windows верхние 2Гб служат под систему и API. В моей концепции приложение имеет в распоряжении полные 4Гб памяти. А обращение к API идёт при обнулённом указателе стека. Скажете, из-за генерации исключений приложение через такой API будет крайне тормознутое.
При классическом программировании - да.
Случай из жизни: Когда нужно "пробить" что-то важное, обычно человек бегает в городе по инстанциям и собирает кучу бумаг со штампами в бюрократическом лабиринте. На простую операцию уходят дни, недели, месяцы.
Однако, когда человек 100% знаком с конституцией, юриспруденцией и знаком с механизмами бюрократии, ему достаточно самостоятельно расписать несколько бумаг (в стиле "придраться не к чему"), посетить нескольких чиновников, получить подписи и штампы. Всё займёт от суток до пары дней (утрирую).
К чему это?
Мы привыкли в классической интерпретации API делать сотни тысяч пустяковых вызовов процедур. Тогда как можно было бы обойтись сценарием с чётким планом действий, который можно передать сервисному процессу - демону.
Т.е. вместо кучи PutChar вызвать не то, чтобы Print. А расписать все данные в файл и потом передать файл системе на распечатку - типа RenderHTML.
Вместо того, чтобы строить картинку по одной линии, расписать svg-файл (или метафайл Windows) и попросить систему отрендерить его...

Поняли, в чём суть?
Мою OS многие критиковали. Однако, единицы поняли, т.к. сами думали об этом.
К чему приложению копаться в портах, если можно попросить систему сделать это?
Из-за этого в моём процессоре я сделал всё, чтобы приложение обходилось без классического API уже с самого нижнего уровня.
Я, как бы это сказать, сделал "перезагрузку" самой концепции построения процессорных систем.

В Windows DirectX позволяет выбрать аппаратную реализацию плана или программную эмуляцию.
В своём процессоре я выполнил абстракцию этого.
Т.е. вместо того, чтобы приложение выбирало между Print (печать на экран) и LPrint (печать на ПУ), оно просто отправляет данные в порт.
Если архитектура ЭВМ на базе этого процессора содержит в себе "умное" интерфейсное устройство, способное аппаратно произвести печать, то без вмешательства OS приложение произведёт печать. Если же "умного" устройства нет, операционная среда запустит соответствующий драйвер.
Важно лишь, чтобы вместо кучи тупых GetChar, PutChar, SetColor, SetPixel, DrawLine и т. п. всё было организовано через язык сценариев (не Java или Perl), передаваемый "демону" через срыв стека...

Хм... Однако меня обогнали... http://www.6502.org/users/dieter/m14500/m14500.htm Теперь чтоб их обогнать остаётся только немного сократить схематехнику и собрать на транзисторах... К слову, там любители уже посчитали..
Что-то порядка 672 штук выходит, на сегодняшний день...

Мы привыкли в классической интерпретации API делать сотни тысяч пустяковых вызовов процедур. Тогда как можно было бы обойтись сценарием с чётким планом действий, который можно передать сервисному процессу - демону.

Чем-то сама идея до крайности напоминает WPF...

Не знаю, может быть Ваш набор команд и дофига оптимален, но мозг он ломает знатно. Поведение системы получается до крайности неочевидным. Да хотя бы с тем же нулевым стеком... И я все так же считаю, что такая методика - прямой путь к трудноуловимым глюкам. Ну хорошо, exception не возникнет, будет вызвана какая-то случайная системная функция со случайными аргументами. И что? В результате получится неопределенное поведение, которое даже не отловить. Не лучше ли передать управление обработчику исключений, чтобы он корректно разобрался, что куда?

И все так же остается вопрос, как ко всей этой радости со стеком получать доступ из ЯВУ? Не все же драйвера писать на ассемблере.

YS писал(а):Чем-то сама идея до крайности напоминает WPF...

Не знаю, может быть Ваш набор команд и дофига оптимален, но мозг он ломает знатно. Поведение системы получается до крайности неочевидным. Да хотя бы с тем же нулевым стеком... И я все так же считаю, что такая методика - прямой путь к трудноуловимым глюкам. Ну хорошо, exception не возникнет, будет вызвана какая-то случайная системная функция со случайными аргументами. И что? В результате получится неопределенное поведение, которое даже не отловить. Не лучше ли передать управление обработчику исключений, чтобы он корректно разобрался, что куда?

И все так же остается вопрос, как ко всей этой радости со стеком получать доступ из ЯВУ? Не все же драйвера писать на ассемблере.

Ну, проект же в статусе Альфа. Многое не решено...

Сейчас вот доработал ассемблер, дизассемблер и эмулятор. Из дешифратора команд выбросил 1 бит. Теперь на входе их 14 и всего насчитывается 2048 комбинаций из 47 команд:

• Биты 7..0 : Собственно, код команды
• Биты 10..8 : Обычная команда (0) или с префиксом (1-7)
• Биты 13..11: Ограничения для двойного префикса

Писать драйверы на ЯВУ - не извращение?

Чем-то мне напомнился старинный советский мультик про слона художника, который стремился всем угодить. Написал картину, а звери, посмотрев, заключили: Ералаш!

По мне, так драйверы писать надо на ассемблере. На ЯВУ - пошлость...
Поэтому, я буду просто допиливать текущую версию...
Нужно написать более-менее сносный "Монитор".

Paguo-86PK писал(а):По мне, так драйверы писать надо на ассемблере. На ЯВУ - пошлость...

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

Paguo-86PK писал(а): Чем-то мне напомнился старинный советский мультик про слона художника, который стремился всем угодить. Написал картину, а звери, посмотрев, заключили: Ералаш!

Вообще то это не мультик, а БАСНЯ. Михалкова. Называется "Слон-живописец".
Но она к данной теме не имеет отношения.
Есть такая архитектура IA64, которая забила на х86 большой и толстый.
Но на практике в широком ПК-строении не прижилась.
Потому что помимо технической целесообразности очень важна преемственность ПО.
И таких историй НЕСТЬ ЧИСЛА. Стандарты цветного ТВ и видеозаписи, стереовещание и многое, многое другое.
И вообще, "не ищи дурее себя"... (с)

Писать драйверы на ЯВУ - не извращение?

Это зависит от того, что Вы понимаете под ЯВУ. Если язык Си, например, Вы ЯВУ не считаете, то все нормально. Если считаете, то я никак не могу согласиться. Си, собственно, для того и разрабатывался, чтобы писать относительно переносимый системный код.

Сплошь и рядом встречается ситуация, когда один и тот же модуль периферии (например, SD-карта) используется в совершенно разных системах. Написание драйвера на Си позволяет просто перекомпилировать один и тот же код, максимум заменив HAL, и не заниматься бессмысленным переписыванием всего драйвера.

Именно потому я и напираю на линейное адресное пространство - оно позволяет чудно писать очень переносимый системный код на Си. А так Ваша система команд получается совершенно не оптимизированной под ЯВУ, что принудит вводить встроенные функции компилятора и сильно отклоняться от ANSI C, например.

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

Но, поймите и Вы меня: Я не ожидал, что начнёте предлагать строить адекватную архитектуру, на которой можно будет запустить QNX или Linux. Встроить процессор в бортовой компьютер велосипеда...
Я изначально поставил себе несколько простых целей:

1. Расставить команды в таблице по интуитивно-понятным позициям (BC xx - Branch if Carry, AA xx - ALU Add, DB - Decrement BX, F7 - Function 7 (Int 7))
2. Устранить неиспользуемые варианты инструкций (BC FF - Break if Carry (RC (Ret if Carry))
3. Выбросить вон редкие команды из поля зрения (DAA, STC, CLC, IRET, CLI, STI, IN, OUT)

Примитивно? Думаю, да. Можно сказать, я просто зациклился на том, чтобы тупо сделать гламурную таблицу команд.
Я это сам стал понимать, т.к. на практике в ассемблере я столкнулся с некоторыми сложностями (в частности, Jcnd $+80h..FFh не могу вписать. Т.е. прыжок к инструкциям в районе 128-255 байтов невозможен - глухая зона) (да-да, у меня до портов "руки не доходят" из-за "глухой зоны": думаю, как обойти этот косяк).

В Вашей критике мне не нравится лишь одно: Вы направляете меня на практический вектор. Чтобы эту архитектуру можно было как бы где-то применить...
С другой стороны, да. Правы, проблема 2000 возникла из-за того, что программисты не расчитывали, что их продукты станут де-факто и войдут в стандарт.
Ваша правда.
Я всё прекрасно понимаю, что мужик должен строить на века...
Но я не расчитываю, что моя архитектура будет покупаться NASA и Японцы построят на её базе новый Game Boy...
Тогда как Вы шуточно уже записываетесь в заказчики...

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

Моя позиция в другом. Пройдя закалку РК-86 и даже ZX-Spectrum (ROM-Basic 8kb + ROM-Chars 8kb - можно было обойтись без 8кб знакогенератор и добиться 56кб ОЗУ), у меня комплекс "клоузтрофобии": Не хочу отдавать ни байта ОЗУ! (мне 16Гб иногда мало из-за кучи VMware-сессий)
(в системе команд так же: нету команд дублёров. одну операцию можно выполнить одним способом)

Таблица команд: Кликая по PREFIX-ячейкам (00,11,22,33,44,55,66,77) можно увидеть все возможные команды.

Paguo-86PK писал(а): в системе команд так же: нету команд дублёров. одну операцию можно выполнить одним способом

Идея фейковая, потому что пересечения неизбежны. Запись константы в РОН неизбежно пересекается со сбросом РОНа. А сброс РОНа является частным случаем сброса любой ячейки ОЗУ всеми видами адресаций. Если минимизировать подобные пересечения, то код операции станет абракадаброй. В команде невозможно будет выделить код операции на фоне типа адресации и собственно адреса. Будет галиматься и на программном и на железном уровне. Дешифраторы команд станут непотребно сложными и, как следствие, медленными..

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

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

С другой стороны, я уже имею некоторый опыт. Если начну с нуля строить новый эмулятор, уже будет легче сразу обходить все кривые места.
А так же, у меня же РИСК (Ребусного Инструкционного Состава Компьютер) и не забывайте, пожалуйста, товарищи, что я изначально обозвал так свою технологию. Ну не вписывается она в нормальные CISC и RISC. Потому и кажется через чур кривой.
Я пытаюсь себя убедить(!), что она - не кривая, если не смотреть на неё под классическим углом.
Т.е. система команд не запутанная вовсе, а ребусная.
Честно, я сам путаюсь в ней... Однако, повторяюсь, кто, кроме меня, возмётся всеръёз развивать изначально тупиковую ветку?
Это уже "романтика" (дон Кихотство с мельницами) и тут есть свои прелести, если не бояться отрываться от земли и лететь никуда просто ради свободы полёта.

На данный момент я сделал глупость, запостив свою идею не в той ветке и вообще в чужой серъёзной теме...
Писали же программы и посеръёзнее по пути в один конец.
Все глупости на земле делаются именно с серъёзным выражением лица

P.S.:

Спойлер

Если меня считаете упрямцем, которому мало чётких и обоснованных аргументов, я выскажусь, примерно, так...

На сколько я понимаю (не вдаваясь в исторические факты), понятие "процессор" относительно молодое. Лет 60 тому назад в ЭВМ не было вообще Устройства, именуемого Центральным Процессорным. В самих направлениях технологий сейчас это замечается: ?ISC - Computer.
Тем самым, т.н. Табуляторы строились без чёткой стандартизации, в плане, переносимости. ASCII - тоже молодой стандарт... Ширина слова варьировалась, были и 12-разрядные машинные слова. В общем, всё это история...

Одна из проблем конвейерной дешифрации команд x86 - неопределённая длина команды, зависимая от поля операндов.
Кстати, в Z80 команды с префиксами IX/IY тоже удлиняются на 1 индексный байт.

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

Один раз задумался, а почему символы расположили не интуитивно понятно?
Скажем, 24 = $ - 34 = 4 или 26 = & - 36 = 6. И решил я подправить таблицу...

Код: Выделить всё

   0 1 2 3 4 5 6 7 8 9 A B C D E F
┌─┬───────────────────────────────┐
│0│                               │
│1│                      § ↵ ↵ ∙ →│
│2│  ! ? # ^ $ ( % & ) < > | ~ = \│
│3│0 1 2 3 4 5 6 7 8 9 , . + - * /│
│4│_ A B C D E F G H I J K L M N O│
│5│P Q R S T U V W X Y Z ; [ ] " @│
│6│` a b c d e f g h i j k l m n o│
│7│p q r s t u v w x y z : { } '  │
└─┴───────────────────────────────┘

Поясню её так:

• цифра 2 очень похожа на знак вопроса, а цифра 5 - на доллар;
• цифра 8 похожа на амперсанд больше, чем 6;
• цифры 6 и 9 - противоположности, как и скобки ();
• цифра 4 схожа с буквой A, как и степень ^;
• символ Пробела и Табуляция - одно и тоже. Соседи;
• Подчёркивание используется как пробел в именах. Должно быть в ряду с символами;
• управляющие символы CR, LF, Esc - популярные и должны быть ближе к печатуемым;
• буква O и @-Эт похожи, а пробел и подчёркивание - одно и тоже;
• на строке с цифрами больше подходящее место к математическим знакам;

Так что, можно сказать, я решил заняться перекраиванием всех технологий в масштабах одного файла - эмулятора x80. И не каприза ради, а ради упрощение программирования парсеров и трансляторов. Локально, я в нескольких разработках так и поступил, перекодируя входной текстовый поток, ради упрощения парсера.

Вы не против, если создам отдельную тему? Или - фейковая тема. Пора закруглять?

Гуглил, наткнулся:
http://comp-science.narod.ru/E97/e97-1.htm
http://educomp.runnet.ru/mmix/mmixart.html (00 - STOP / HALT / HLT)
http://itc.ua/news/c-h-p-mikrokompyuter ... u-vsego-9/
Перечитав статьи, понял, что нужно жёстко придерживаться выбранного курса. Тем самым, официальные порты через стек - остались.
Эмулятор переписываю с нуля. Изменений - никаких. Только устраняю излишки дешифратора и пользовательского интерфейса.

Вчера умывался и ... наконец-то вспомнил, что хотел реализовать.

Befunge - алгоритм строится лабиринтом.
Суть крайне проста: Взять первый знакомый процессор (i8080 например) и выбросить из него все инструкции ветвления.
Т.е. если трассировать код программы и строить древо алгоритма, циклы будут образовывать петли командами ветвления.
А если их выбросить и оформить всё как реальные ветви, циклы не будут выглядить петлями.
Иными словами, традиционные команды ветвления образуют путанные графы. Тогда как для построения нормально древа, вместо операций условного перехода нужно использовать операции условного вызова ветки. Иными словами, в i8080/z80 всё для этого имеется. А в x86 - нет.
Правда, код программ будет выглядить несколько необычно и к такому стилю ещё придётся привыкнуть...