Непонятно. Наоборот, в рисках меньше вариантов дешифрации, проще правила.
Вид для печати
Напримeр, данный машинный код в 80-х любой школьник мог бы усвоить на раз-два:Код:x80: .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
0000 A1 76 A5 D0 A4 4E CB D4 BF FC 00
Если лень думать…
Код:Z80: .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
0000 26 76 2E D0 3E 4E 23 3D 20 FC 76
[свернуть]
(Всё равно, что на Z80 в цикле M1 код команды пропускать через ПЗУ с таблицей перекодировки - x80 так и планировался на первых парах…)Пояснение…
Код:0000 A1 76:ARG R1,0x76
0002 A5 D0:ARG R5,0xD0
0004 A4 4E:ARG R4,0x4E
0006 CB :INC BX
0007 D4 :DEC R4
0008 BF FC:BRF 0x0006
000A 00 :NUL/HLT
[свернуть]
То есть, я как любитель дампов потратил десятилетия на проработку системы команд по принципу паззла: Смысл и логику не менял, но переставлял по ячейкам таблицы команд.
Просто, если человек не хочет ради прикола программировать дампом - это личный интерес каждого…
P.S.: Я всего лишь сделал то, как было бы в древние времена, когда микроскоп украшался узорами (пруф) и радиоприёмники были украшением (пруф).
Я подошёл к принципу реорганизации таблицы команд i8080 как эстет. Не более!
За это критикуете?
(Кто-то любит систему команд по-Пикассо, а я собрал систему команд по-Вангогу!)
Проходит ли данная архитектура по "лезвию Оккама"? Для чего создается? В чём её преимущества перед другими?
Набор команд - это не архитектура - ни компа ни процессора. Как максимум - часть архитектуры
Для набора команд бритва Оккама - это вопрос - под какой язык создаётся система команд (с прицелом на лёгкость написания программ на этом языке).
Пока тут лёгкостью и не пахнет
- - - Добавлено - - -
В общем - классический случай - автор придумал что то под себя (причём придумывал явно не один день), у него за это время всё это хорошо отложилось в голове и памяти - и вдруг - облом - другим это таким же лёгким не кажется. А вот убедить других - уделите этому - три месяца - и вам тоже покажется лёгким и понятным - особенно современно поколение, привыкшее тратить на освоение нового (язык С за 24 часа) минимум времени, а если не получается - нахнах - ну вот никак - все такие упёртые и не хотят увидеть Брульянт.
В целом, как я уже сказал и судя по комментам - впечатлить пока не удалось.
Кaк выше я и сказал: x80 - архитектура i8080, но с красивой таблицей команд.
Тем самым, преимущество, в первую очередь, именно в красоте.
А так как я никаким боком не инженер, то просто реинженерю i8080. Сначала я переделал известный эмулятор и переписывался с его автором. В его эмуляторе я просто добавил «case 0x40: case 0x49: case 0x52: …», то есть все холостые MOV-пересылки: mov b,b; mov c,c; mov d,d и т.д…
И эти холостые MOV я превратил в префиксы, чтобы код «40 86» работал как «add b,m» без участия аккумулятора.
Кто-то сказал, что идея - не плохая, так как куролесица с аккумуляторным АЛУ жутко напрягала. Но, на кристалле это выполнить в 70-е невозможно. Слишком дорого бы обошлось перехватывать коды холостых MOV. Потому обошлись инженеры лишь тем, что «mov m,m» превратили в «hlt».Чисто из интереса!
Сначала я пробовал накидать схему перехвата MOV-префиксов, чтобы проверить, правда ли сложно?
Потом решил причесать таблицу команд и вскоре понял, что переделывать эмулятор перебивкой сотен case каждый раз - очень тяжело.
Написал свой эмулятор с генератором команд по шаблону.
Так и «mov m,m» (hlt) переместился в позицию 00 и я начал активно прорабатывать идею уже как отдельную архитектуру.
Я выбросил все команды с адресом: «ld sp,addr», «ld hl,addr», «ld bc,addr», «ld de,addr», «ld a,addr», «ld a,(addr)», «ld hl,(addr)», «ld (addr),a», «ld (addr),hl» и «jp addr».
Если в мою таблицу вглядеться внимательнее, то по-своему - это совершенный i8080, каким он мог быть в 70-е с самого начала…
Система команд более ортогональна, чем у z80, так как префиксами там достигается вся гибкость почти уровня i8086.С трудом догадываюсь, в чём вопрос.
Если не обращать внимания на префиксы, то x80 - тот же i8080, но, как выше сказал, без команд с кодами 01, 11, 21, 22, 2A, 31, 32, 3A, C2, C3, C4, CA, CC, D2, D4, DA, D4, E2, E4, EA, EC, F2, F4, FA, FC.
А так же и без кодов C0, C8, D0, D8, E0, E8, F0, F8 и D3, DB, F3, FB, 09, 19, 29, 39.
То есть, слишком редуцированный i8080, так как все те команды доступны уже через префикс.
Не проверял, проходит ли тест по Тьюрингу мой процессор в этом случае, так как схематически получается гораздо проще i8080 в реализации собачником.
По теме
Тему можно было назвать «i8080/8086 - перезагрузка!», так как я именно занимаюсь перезагрузкой этих архитектур, как Вы уже поняли.
Это как из i8086 вытрясти все 16-битные команды и сделать ремейк i8080, который может выполнять программы i8086.
То есть, из 16-битного i8086 сделать 8-битник (не i8088).
(А не гибрид типа NEC V20…)
Регистровый файл
Все регистры у аппаратного x80 должны быть во внешнем регистровом файле в виде статического ОЗУ.
Тем самым, даже команда «NOP» будет занимать десятки тактов из-за активного доступа к внешней статике.
То есть, сначала прочитать младший байт регистра адреса команды IP, затем - старший байт. Уже 4 такта.
Затем, выдать IP на шину адреса, прочитать код команды - ещё 8 тактов.
Потом выполнить инкремент IP и записать его в статику - ещё 12 тактов.
Как видите, прототип x80 в FPGA или ТТЛ будет очень медленным.
Здесь в пору заметить: Если Вы ждёте от прототипа x80 супер скорости, можете выходить из темы…
Резюме
Цель: Перезагрузить саму систему команд i8080, чтобы она могла в последствии стать 32-битной или 64-битной.
Причём, совместимость в обе стороны: 64-битные x80-программы можно запускать и на 8-битном x80, но производительность упадёт в сто раз!!!
Это сделано с той целью, что, используя современные технологии с супер-кешом, по-идее в перспективе можно будет добиться доступа к регистровому файла за 1 такт. А введя конвейер, ускорить исполнение команд в несколько раз. То есть, это уже уровень мастерства.
Сейчас главное (для меня) - просто добиться функциональной полноты системы команд, чтобы хотя бы в эмуляторе работало гладко.
Самое прикольное, что и система команд 8080 тоже хорошо ложится на восьмеричные коды. Формат опкода побитно: ggRRRrrr, где gg - группа команд, RRR - регистр назначения, rrr - регистр источника, а в командах где в группе нет регистра источника или назначения, эта восьмиричная цифра означает код операции. Но Интел почему-то решил, что 16-ричная система лучше и всё пошло наперекосяк.
Вполне возможно, я уже давно не касался 8080 (хотя в загашнике лежат Радио-86 и Микроща), так что просто не помню свои разборки в то давнее время, когда Микроша стала моим первым домашним компам. Но и провозился я с ней относительно не долго - в продаже появился БК-0010.01 - и против PDP-11 совместимого я, ессссенно (первая любоф) - не устоял. После чего Микроша.. просто лежала :) А потом появился УК-НЦ (с флопами) - и стало лежать два компа :) А потом мне предложили их продать - и я не устоял :) Малолетний идиот :) Ну а теперь - лежат как ностальгия - может и повожусь :)
Микроша, кстати, была продана уже с моей доработкой - расширил ОЗУ до 48 кб и некоторые программы (точно - редактор и ассемблер) - перенес в верхние 16 кб, что дало мне аж почти 32 кб свободной памяти :) Но вот ПЗУ тогда прошивать не было на чём, поэтому монитор не умел использовать верхний блок :)
Я так и не научился её воспринимать нормально :) В восьмеричной и складываю и вычитаю и слово делю на байты в уме, а hex - только слово на байты могу - остальное - калькулятор из Win :)
O чём я и говорю. Когда в справочниках отца по микропроцессорам изучал комплекты серий типа 1801 и т.д…, то путался всегда в этих их восьмеричных адресах и вообще не понимал ничего.
(Вроде бы операции умножения проглядываются, но выглядело (после дампов РК) всё как-то несерьёзно: Спорное заявление, но это - дело вкуса…)
А с РАДИО-86РК и ASCII-таблицу вызубрил быстро, и в адресации стал разбираться.
Это наверное дело вкуса. Но, как я уже сказал, здесь x80 имеет редуцированную систему команд i8080, которая из восьмеричного порядка комплектации команд в таблице была приведена к шестнадцатеричному виду.
Не забывайте, что……представлялась именно шестнадцатеричной таблицей. Да и дамп в Hex-представлении куда удобнее и компактнее на экране с 52 символами на строку.Таблица команд публикаций
И адрес F803 выглядит красивее и запоминается легче, чем 174003.
Человек, прежде всего, мыслит словами и звуками: F803 - Функция #8-03.
Наверное, здесь ещё играет роль особенности памяти индивидуума: Кто-то номера телефонов запоминает легко цифрами, а кто-то - буквами:
Например, у моего знакомого номер сотового я помню только потому, что он представляется как «-BABNIK» - «-222645». А своей племяннице сим-карту покупал на «-DOLLY-» - «-36559-».Скрытый текст
(На владельцев блатных номеров, типа 111-11-11, я смотрю как на безграмотных гопников из 90-х…)
Даже в системе команд x86 меня напрягает поле «md-reg-r/m» как восьмеричное.
Пытался делать эмулятор i8086 с шестнадцатеричным полем операндов как «h-reg-l-r/m», чтобы голым дампом не нужно было в уме индекс регистра из восьмеричной системы переводить в нормальный Hex-вид…
P.S.: Потому, как ответвление от i8080, этот x80 именно шестнадцатеричный.
Вчерa накидал пример всех способов адресации и расстроился.
Вот смотрите:Если Вы не обращаете внимания на издержки технологий с уродством команд x86, то ничего не заметите и не поймёте…Код:07 :MOV DL,[BX] ; Косвенно-регистровая адресация
67 :MOV DL,CL ; Регистровая адресация
A7 89:MOV DL,0x89 ; Непосредственная адресация
55 A7 89:MOV DL,[BX-119] ; Относительная адресация
E4 55 A7 89:MOV DL,[BX+AL-119] ; Индексная адресация
B8 FE 55 A7 89:MOVX DL,[BX+XX-119] ; Чтение в режиме X по индексу XX - ломается эстетика
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
0A :ADD AL,[BX] ; Косвенно-регистровая адресация
6A :ADD AL,CL ; Регистровая адресация
AA 89:ADD AL,0x89 ; Непосредственная адресация
55 AA 89:ADD BL,0x89 ; Непосредственная адресация
E4 55 AA 89:ADD4 BL,0x89 ; Сложение в режиме #4
B8 FE 55 AA 89:ADDX BL,0x89 ; Сложение в цикле режима X - ломается эстетика
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
81 23:PUSH 0x0123 ; Помещение константы в стек
91 23:PUSH 0xF123 ; Помещение константы в стек
55 81 23:PUSH 0x5123 ; Помещение константы в стек
55 91 23:PUSH 0xA123 ; Помещение константы в стек
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
55 A0 23:PUSH [BX+35] ; Относительная адресация
55 B0 23:POP [BX+35] ; Относительная адресация
E4 55 A0 23:PUSH [BX+AL+35] ; Индексная адресация
E4 55 B0 23:POP [BX+AL+35] ; Индексная адресация
B8 FE 55 A0 23:PUSHX[BX+XX+35] ; Индексная адресация X по XX - ломается эстетика
B8 FE 55 B0 23:POPX [BX+XX+35] ; Индексная адресация X по XX - ломается эстетика
А я - попал в тупик. Так как «MOV DL,[BX+AL-119]» кодируется последовательно (следите за лесенкой: Система префиксов проста), а вот закодировать «MOVW DL,[BX+AL-119]» я уже не смог - ломается эстетика!
Да, именно эстетика для ручного восприятия и набития байт-кода!
Что такое здесь за «MOVX», «PUSHX» и «POPX»?
В регистровом файле регистр BL имеет адрес 0x00B0, регистр BH - адрес 0x00B8, где BX - соответственно 0x00B8:0x00B0.
Промежутки 0x00B1…0x00B7 и 0x00B9…0x00BF не используются, но подразумеваются.
То есть:То есть, в отличии от x86 с именами «BX», «EBX» и «RBX», здесь у меня «BX» - всегда «BX».
- В 8-битном x80 регистр BL - ячейка 0x00B0
- В 16-битном x80 регистр BL - ячейки 0x00B0 и 0x00B1
- В 24-битном x80 регистр BL - ячейки 0x00B0, 0x00B1 и 0x00B2
- В 32-битном x80 регистр BL - ячейки 0x00B0, 0x00B1, 0x00B2 и 0x00B3
- В 64-битном x80 регистр BL - ячейки 0x00B0, 0x00B1, 0x00B2, 0x00B3, 0x00B4, 0x00B5, 0x00B6 и 0x00B7
А вот «ADD», «PUSH» или «MOV» может меняться на «ADD8», «ADD16», «ADD32» или «ADD64».
То есть 8-битный x80 будет исполнять 32-битное x80-приложение очень медленно, последовательно читая и перезаписывая аккумулятор AL по ячейкам 0x00A0, 0x00A1, 0x00A2 и 0x00A3 с затратой кучи тактов (эффект бутылочного горлышка).
Тогда как 32-битный x80 сразу прочтёт целое слово 0x00A0…0x00A3 за такт, выполнит АЛУ-операцию и за такт перезапишет слово.
То есть, формально в эмуляторе я уже могу написать и запустить 64-битный код, но не хочу.
На счёт остального…
Читаем VLIW:Ясно, что ничего общего у моего x80 не имеется ни с RISC, ни с VLIW.Цитата:
Преимущества и недостатки
Архитектура VLIW выглядит довольно экзотической и непривычной для программиста. Из-за сложных внутренних зависимостей кода программирование вручную, на уровне машинных кодов для VLIW-архитектур, является достаточно сложным. Приходится полагаться на оптимизацию компилятора.
Но, из «Из-за сложных внутренних зависимостей кода программирование вручную, на уровне машинных кодов для VLIW-архитектур, является достаточно сложным. Приходится полагаться на оптимизацию компилятора» видно, что программиста всё-таки нельзя оставлять в изоляции от машинного кода с барьером в лице компилятора!
Тем самым, так как изначально мною курс был взят за «Даёшь байт-код народу», то любое отклонение от него - крах всего концептульного плана.
P.S.: Не смотря на возмущения и критику многих, в данной теме нужно просто принять за де-факто то, что здесь обсуждаются проблемы разработки процессора с прозрачным байт-кодом так, как видит его автор. То есть - я…
Вам выбирать, подключаться ли к проекту или игнорировать - архитектура моего процессора от этого не изменится. Вы и сами это понимаете, так как форум для того и существует.
Как «художник-технарь», я вижу идеальный процессор именно так!
Если видите иначе - откройте другую ветку.