Войти
ФлеймФорумЖелезо

8-битный "компьютер мечты" (22 стр)

Страницы: 117 18 19 20 21 22
#315
22:00, 14 дек. 2019

=A=L=X=
> Мы всё-таки отделяем команду от её аргументов, хотя иногда разница может быть зыбкой, но выбор обычно нетруден.
Выбор абсолютно произволен, что я тебе и продемонстрировал.
Именно потому "что между ними нету четкой границы".


#316
23:42, 14 дек. 2019

}:+()___ [Smile]
> А по факту это a + ((0 - imm) ^ b) + imm — одна команда с однобитным immediate

Имхо, ты просто описал вариант ортогонализации/RISC-изации команд.
Скажем, если делать на накопительном сумматоре/аккумуляторе, то мы можем добавить бит инверсии слагаемого и переноса в младший разряд, бит блокировки переносов, бит блокировки исходного содержимого, бит изменения поведения основного выхода сумматора (OR вместо XOR) - и получить почти стандартный набор аккумуляторных команд с командой его загрузки. Это же не значит, что все это надо считать одной командой с immediate - это однозначно набор команд.

#317
1:39, 15 дек. 2019

}:+()___ [Smile]
> Это же не значит, что все это надо считать одной командой с immediate - это однозначно набор команд.
Это значит, что, в принципе, можно считать это одной инструкцией.
И все эти "компьютеры с одной инструкцией" что-то вроде этого и делают.

#318
5:39, 15 дек. 2019

}:+()___ [Smile]
> И все эти "компьютеры с одной инструкцией" что-то вроде этого и делают.

Нет, настоящий эзотерический компьютер с одной инструкцией действительно содержит только одну инструкцию данные которой есть как правило ссылки на ячейки памяти.
Такая команда имеет достаточно сложный ход выполнения, но она реально одна.
В общем виде выглядит так (я вообще то это уже писал выше): из ячейки А вычесть ячейку Б, записать результат в В и если результат меньше нуля, то перейти на Г, иначе перейти на Д.
Это одна команда и у неё нет immedate-данных, только адреса ячеек с которыми работаем. Никаких расширений, никаких сложений или битов переноса - просто вычитание и по условный переход по результату.
В таком развёрнутом виде аж с пятью аргументами она слишком многословна, поэтому на "практике" сокращают наподобие такого:
- из ячейки А вычесть ячейку Б, результат записать обратно в А и если он меньше нуля, то перейти на В, иначе продолжить выполнение со следующей инструкции
В таком виде чаще всего и встречается.
Тут реально одна инструкция, только одна арифметико-логическая операция и но пасаран. Одна инструкция. Как и куда ни смотри, под любым углом.
Например MOV в такой системе неуклюже, но делается так:
- если в целевой ячейке не ноль заранее, то вычитаем её саму из себя - т.е. обнуляем
- обнуляем так же промежуточную ячейку - temp
- вычитаем переносимое данное из temp (адрес перехода делаем так что инструкция эквивалентна безусловной - т.е. на следующую инструкцию)
- вычитаем temp из целевой ячейки - опять таки имитируя безусловщину (а может и нет, если это последняя инструкция перед переходом)
Выглядит монструозно, но легко доказывается что это всё полно по тьюрингу. Забавно, что из-за того, что единственная операция - вычитание, то зачастую более актуальна как раз короткая форма переноса, которая меняет знак, т.е. никакой temp где не нужен - ведь потом перенесённое данное один фиг можно будет только вычитать и если нужно было сложение, то inverse move наоборот то что нужно.
В общем тут реально не одноформатная, но одноинструкторная машина.

У чувака с прошлой страницы инструкция одна - это mov, но это mov по сути между блоками АЛУ и вся работа совершается на адресах переброски.
Т.е. формально тут одна инструкция, но процессор от этого проще не становится - наоборот он даже становится сложнее, потому что упорядочивать тот же сумматор в стековую машину - то еще удовольствие. Сложность микросхемы получается что выгоняется из системы команд за порты ввода-вывода к АЛУ которыми становятся регистры. Что в принципе формальным признакам отвечать может, но по сравнению с реальной однокомандной машиной как выше - ну прям не айс.

#319
6:42, 15 дек. 2019

Псс, ребята, хотите немного тьюринг-полноты на одной инструкции... которая x86 mov?

#320
(Правка: 7:07) 7:06, 15 дек. 2019

Delfigamer

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

Идём, например в Overview: https://github.com/xoreaxeaxeax/movfuscator/tree/master/overview

И там превосходные картинки, например flow graph:

Изображение

или во что превратились классические инструкции вычисления простых чисел:

Изображение

Лолшто?
Overview такой overview...
Пока у меня подозрение, что оно работает в точности как процессор выше - ставится перехват "интересных" адресов на прерывания и на самом деле при попытке оттуда что-то читать/писать под капотом обработчика прерывания и происходит вся настоящая работа.

#321
(Правка: 7:37) 7:26, 15 дек. 2019

А, раз уж начал сейчас копать еще раз, то таки докопался до PDF-ки: https://github.com/xoreaxeaxeax/movfuscator/blob/master/slides/do… vfuscator.pdf
Идея на самом деле не то что я думал и довольно забавная.
Крутится вокруг косвенной адресации памяти.
Возьмём такой кусок кода:

mov [x], 0
mov [y], 1
mov R, [x]
т.е. пишем в ячейки памяти с номерами x и y последовательно два разных значения, а потом считываем значение из ячейки x в целевой регистр.
И вот тут и возникает наш side-effect - если x и y равны, то в R окажется 1, а если нет - 0.
Возникает эффект похожий на movcc и ужасное и непредсказуемое загрязнение памяти попросту недопустимое.
И вот тут они снижают это загрязнение сводя всё к работе с байтами - ограничивают этот "массив для сравнения" 256 байтами и сводят операции к побайтовым последовательностям, лол.
Довольно забавно.

#322
11:27, 16 дек. 2019

Самодельный ноутбук ZedRipper на 16-и Z80 (FPGA)
https://habr.com/ru/post/480290/

Страницы: 117 18 19 20 21 22
ФлеймФорумЖелезо