Опрос - новые инструкции.

Ну если процессорный хакер не может найти в инете онлайн-декодер или виртуальную клавиатуру -- что интересного он может написать?

---------------------------------------------------------------------------------------
Хорошо, что тема ушла от прикладной банальщины типа эмулятора (тем более, что их уже куча, в том числе универсальные -- только набор инструкций задавай). Надо вообще выносить в медиапространство чаяния низкоуровневых программистов, "чтобы знали". А то лепят не пойми что, а нужных вещей десятилетиями не реализуют.

Мне вот кажется порочной практика перекладывания всего процесса на компилятор. Во-первых, он не обязан знать, как устроен конкретный камень внутри и что ему будет лучше. Во-вторых, из-за этого разбухают и усложняются даже тривиальные программы: любую ерунду туда транслируют в виде тысячи инструкций. А ведь есть куча стандартных задач, которые требуется постоянно решать и которые в процессоре могут быть прошиты: даже при одинаковых алгоритмах такой макрос получится быстрее за счёт экономии на "обслуживающих" процедурах типа pusha (которых чуть ли не больше, чем "рабочих").

---------------------------------------------------------------------------------------

Вот мой дилетантский wishlist (не знаю даже, что уже реализовано и где):

* Прямые операции с памятью (копировать блок данных из адреса1 в адрес2, элементарные преобразования типа mul/xor).

* Инструкции произвольной длины (скажем, первый байт инструкции задаёт общую длину: 00=halt (ибо нефиг в код попадать пустому блоку данных), 01=1 байт (NOP), 02=2 байта, 03=3 байта и т.д.)

* Прямая адресация памяти или DMA-устройств с адресацией произвольной длины (например, первый байт адреса -- номер устройства (00=cpu, 01=ram, ..), второй -- длина адреса в байтах, далее сам адрес).

* Регистры, которые хранят всю эту лабуду, могут использовать кеш для длинных значений (прозрачно для программы), либо просто достаточно большие (типа 128-256 байт).

* Часто используемые алгоритмы должны быть зашиты в микрокод. Не уверен насчёт quicksort, но команды типа "пройтись по массиву A и выполнить процедуру P(A, i) для каждого элемента A" вполне уместны.

* Работа всех узлов процессора должна быть независимой, асинхронной и не завязанной на скорости других узлов. Т.е. считало ядро с шины значение "очередь готова к приёму данных", закатало туда порцию, выставило "готово" и жди себе, пока придёт ответ (или работай дальше). А шина может хоть по RS-232 последовательно гнать значение на другой процессор.

* Ну и на сладкое: для упрощения кода и экономии данных такой процессор нужно сделать троичным

---------------------------------------------------------------------------------------

Пока всё; сделают это -- придумаю ещё. Мне ж не жалко ради прогресса..

 

chAlx в обще то, как я понял из предыдущих топиков _basmp_ не удачно прошил BIOS, и теперь пишет с телефона...

И вот еще imul можно использовать к примеру так imul eax, dword_value, 13h, а почему idiv так нельзя?

 

//В первом приближении заработало.

Перевод поста #59:

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

 

_basmp_
спасибо, так попонятней.

какое же это будет АЛУ без логических команд x)

протокольные блоки это типа журналирование?

 

t00x

Это по посту #52 от Black_mirror там писалось о том, что не стоит вводить команду D = S1 && S2 в добавок к D = S1 & S2. Не знаю. Мне кажется, что явная сравнительная логика (забыл как это называется) - это удобно. А реализуется она очень просто и в рамках одной команды. Используется такая логика часто, а уменьшение количества затрачиваемых команд должно увеличить быстродействие. Имхо.

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

Немного о внутреннем устройстве проца:
Процессором тут я называю не один камень с кучей ядер, а ряд камней нескольких типов взаимодействующих по процессорной шине.

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

Щас думаю разделить планировщик и выделить из алу блок управления. Каждое алу предполагается 8-ми битным, для работы с операндами большей разрядности алушки собираются в группы. Взаимодействие при этом происходит по процессорной шине. Из этого видно, что блок управления алу в пределах такой группы будет дублироваться, а это как минимум 32 макроячейки (при 32х битной команде) + под память состояний. Одним словом если вынести будет дешевле, но протокол шины сильно усложнится.. Или ввести еще одну шину и раздельные планировщики для алушек (№2) и их автоматов (№1)? Автомат выделяется планировщиком №1 и получает команду, затем подает сигнал планировщику №2 о выделении нужного количества алушек..? Да.. Что-то я замечтался..

Так вот, для взаимодействия по процессорной шине(-нам) нужен протокол. Его придется реализовать в железе. Вот этот момент я и назвал протокольными блоками.

Black_mirror

Не совсем понял. А как без них? Особенно без zf?

Возможно я неудачно назвал, подслова == битовые поля. Для работы с ними нужны отдельные механизмы и вводить их только для одной команды - имхо расточительно. Кроме того команда выйдет нестандартная - 4х адресная, что может сильно усложнить управляющий блок и, возможно, не только в алу.

команд '==', '!=' и нету. Вместо нее используется 'D = S1 - S2'. zf будет установлен нормально, а как логическое значение в D принимается 0 и не 0 (команды '&&', '||', '^^' сперва делают or по всем разрядам и получают bool). В случае '<' так просто не получается. Поэтому введена эта команда реализующая выделеное в одной команде, а не в 2-х и, возможно, не меняющая cf.

Принято. Если указано изменение флагов, выдвигаемые биты будут кроме D писаться в предварительно зануленный cf. Таким образом в случае ror

D = D >> S2 ; в верхние биты cf запишутся выдвинутые нижние биты D, кроме того, они-же запишутся в освободившиеся верхние биты D.

Возможно, в сдвигах в случае если S1 != D и указано изменение флагов стоит освободившиеся биты задвигать из cf?

 

_basmp_

ИМХО конечно не стоит, разделять их на программном уровне удобней.

ширина шины между алушками тоже 8 бит?

 

t00x

if ( ! ( a && b < c )) {op1; op2} else {op3; op4;}

при наличии будет:

6 команд

при отсутствии будет:
?? ээм не соображу.. Возможно и не намного хуже.. Напишите вы.

ширина шины намного больше 8 бит. Кроме служебных сигналов по ней идет код протокольной операции, номер вызываемого камня (в зависимости от операции - по номеру потока или по номеру потока:номеру в группе), полное слово данных (алушки выбирают/добавляют свои данные в зависимости от номера в группе: 0-0..7, 1-8..15, итд. В случае сильно больших слов надо предусмотреть еще и передачу по кускам) и полный адрес (формируется также как и данные). Те значительно больше 8.

 

Чето подумал.. Ширина шины и что на ней более-менее определится когда лабуда эта запашет. Сперва самый простой, но рабочий вариант. Потом определятся ошибки, глюки, тормоза и вообще тонкие места. Когда это будет устраняться шина и протокол могут измениться очень сильно. Впрочем это и понятно. То есть в начале нет смысла загадывать о разрядности шины. Пока что лично меня больше интересует минимально рабочий протокол и, отчасти, более-менее оптимальная система команд (те небольшая, но в основном достаточная, достаточно емкая, стандартно записываемая и ненакладная в железной реализации. Свой вариант я вынес на обсуждение в посте #51 + некоторые дополнения и коррективы от Black_mirror).