Некоторые эксперименты ставились вот на этой плате:

Надеюсь, я правильно понял вопрос.

Правильно. Фотки реальных железяк, какие бы они ни были, штука полезная , познавательная, а сейчас ещё и доступная. Телепаты лора одобряют:)

автор велосипеда список своих хотелок более-менее описал, при чем здесь троичная логика? нюансы поведения как раз в hdl и описываются, fpga тут вообще ни причем - это либо тестирование в железе на предмет выявления узких мест и основных характеристик перед запуском asic, либо вообще конечное изделие, если серия мелкая.

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

процессор стал популярным

Да, это сложно. Рабочие образцы нужны, инструментарий нужен, софт нужен, девайсы нужны.

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

Верно, полностью согласен!

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

Зачем нужно ограничение на простые инструкции? Нужен конвейер с dispatch каждый цикл.

Немного подробностей

здесь частично опубликована система команд - http://primula.l4os.ru/core/

Отладочный модуль - http://primula.l4os.ru/hardware_tracer/

А на чем под него конпелять планируется, чтобы аппаратные плюшки задействовать? Когда ждать порт убунты?

А на чем под него конпелять планируется, чтобы аппаратные плюшки задействовать?

Будут две версии средств разработки - для Windows и для Linux. При необходимости, Линукс версию можно собрять для BSD и Mac OS X.

Когда ждать порт убунты?

Это вряд-ли :) Хотя в перспективе можно поднять пользовательское окружение из Убунты. Но это в далёкой перспективе. С уверенностью можно сказать одно - не ранее 2018 года.

2. Хитрая работа со стеком - архитектура не поддерживает регистр Stack Pointer, вместо этого его заменяет обычный регистр, используемый по соглашению.

такое тоже уже было аж в PDP-11

Эта идея там и подсмотрена. Кстати, такой тип адресации я ещё не реализовал. Сейчас команды push и pop реализованы макросами.

Поражаюсь стойкости людей, которые продолжают отслеживать тему. :)

Есть неплохие новости - http://primula.l4os.ru/step_by_step_debug/

Поражаюсь стойкости людей, которые продолжают отслеживать тему. :)

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

Пили.

Новости - http://everest.l4os.ru/test_of_strlen/

Вкратце - у процессора появился свой сайт, а по ссылке статья с примером пошаговой отладки подпрограммы strlen.

Осторожно, страница тяжелая и содержит дампы.

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

Ещё из популярной древности на 68K также было. Ну и у сегодняшних RISC'ов стеки можно на любых регистрах делать, в том же ARM :)

Процессор ориентирован на позиционно независимый код

Таких тоже было много. И даже (sic!) 8086 :D (правда, с гранулярностью в 16 байт)

Зачем разная длинна команд? Это только усложняет железку

На каком-то Форт-процессоре (модель не помню) команда была в 5 бит. И в стандартное 16-битное слово влезало 3 команды, выполняющихся одним разом за один такт :)

А, вообще, да. Сегодня (и давно уже, на самом деле, если на x86 не зависать) в моде фиксированная длина команды.

Однако, разрядность Z80 по нынешним временам маловата.

Z800, Z8000, Z80000 :)

Bolgen ОС

Operating Cystem?

Есть идея, что лучше больше команд одной длины, чем меньше, но разной.

VLIW пока не взлетел.

Зато взлетели RISC'и. Где любая команда равна разрядности процессора, ни байтом больше, ни байтом меньше.

В остальном - наш диалог может вылиться в спор о RISC vs CISC

Этот спор же давно уже был решён :) И концептуальщиками, и разработчиками, и рынком...

Этот спор же давно уже был решён :) И концептуальщиками, и разработчиками, и рынком...

Некоторые фанаты архитектуры x86 c Вами не согласятся. :)

Аргумент, якобы современные Intel Core внутри имеют RISC архитектуру, не принимаю - Вы же не знаете, как внутри организован процессор, который я тут усиленно пиарю.

Таких тоже было много. И даже (sic!) 8086 :D (правда, с гранулярностью в 16 байт)

Сегментные регистры?

Subj не имеет ни одной команды перехода по абсолютному адресу. Единственный способ перейти на определённый адрес - выполнить две инструкции:

load R15, address_32
return

Ну, это не считая «фишек» микроядра, которые ещё не реализованы.

Сейчас все переходы используют относительное смещение 8, 16 или 24 бит.

Сегментные регистры?

Да. Они вводились в первую очередь не чтобы малой кровью обеспечить более высокую разрядность (на том же 68K сделали «честную» адресацию без проблем), а чтобы именно обеспечить возможность загрузки сразу множества программ по [относительно] произвольным местам памяти. Т.е. чтобы обеспечить работу перемещаемых программ, как к тому времени уже вовсю практиковалось на PDP, но в рамках команд, совместимых с 8080.

Впрочем, на 8086 итак были команды переходов с относительно адресацией (те же самые «короткие» переходы), так что это проблемой не было. Хуже было с адресацией данных, вот тут относительных команд не было, требовались хитрости. Хотя я и писал под DOS перемещаемые программные компоненты :)

помимо обычных инструкций ... есть перфиксы и модификаторы

больше CISC для бога CISC

Хотя я и писал под DOS перемещаемые программные компоненты :)

Хорошее было время.

Кстати, этой ночью процессор научился писать в последовательный порт - http://everest.l4os.ru/hello_world/

Это было чертовски сложно.

http://everest.l4os.ru/second_demo/ - добавилось чтение из порта и возможность переключаться в режим пошаговой отладки и обратно.

http://habrahabr.ru/post/222335/ - самое странное, что никто не попросил версию ассемблера для Linux.

Никто не уйдёт обиженным

версия ассемблера для Linux:

http://everest.l4os.ru/everest-assembler-for-linux/

А почему «Эверест»? А «Хамелеон»?

Интересно.

Кста, помощники нужны будут, в какой-то перспективе? Ну, там, системные разрабы etc?

А почему «Эверест»? А «Хамелеон»?

«Эверестом» мы назвали систему команд, чтобы слегка «потроллить» ЗАО «МЦСТ» с их «Эльбрусом». Различным процессорам (точнее, прошивкам для FPGA) мы решили давать собственные имена, которые хоть как-то, косвенно, отражают их функциональность или внутреннее устройство. Т.е. планируется семейство процессоров с системой команд «Эверест».

«Хамелеон» это операционная система (и название всего проекта). Хочется верить что наступит время, когда наша система заработает на наших процессорах.

Сейчас самой большой проблемой видится компилятор С++ или хотя бы Си. Пока его нет, мы рассчитываем на интерес разработчиков, кто не боится ассемблера.

Кста, помощники нужны будут, в какой-то перспективе? Ну, там, системные разрабы etc?

Разумеется помощники нужны. У нас слишком маленькая команда, чтобы осилить всё самим. Одно плохо - вот непосредственно сейчас мы не можем финансово заинтересовать сторонних разработчиков.

Если есть какие-то конкретные предложения, или идеи, или желание каким-то образом оказать влияние на результат работы - я и мой компаньон открыты для общения.

я и мой компаньон открыты для общения

Хорошо, я понял. Могу, в общем, помочь бесплатно. Не прямо сейчас, конечно. Ассемблера не боюсь, бываю иногда системным программистом. Тема в принципе интересна.

«Эверестом» мы назвали систему команд, чтобы слегка «потроллить» ЗАО «МЦСТ» с их «Эльбрусом».

Я где-то догадывался, но первая ассоциация возникла по другому поводу. Были такие ПК фирмы «Эверест».

Карта системы команд процессора - http://everest.l4os.ru/cpu_commands_map_v1_1/

Тоже думал на скотинку. А почему китаец?

Однако, разрядность Z80 по нынешним временам маловата.

Синклер еще выпускал Z180 и Z280 :) .

Потихоньку повышаю порог вхождения. Восстанавливаю ноут, под это дело. Поучаствую.

Могу подкинуть идею - опенсорсный транслятор из x86 в систему команд «Эверест». Я бы тоже поучаствовал и помог чем смог.

Судя по тому, как подобные штуки сделаны на работе, это далеко не тривиальная задача(

Нетривиальная, конечно же. Но 100% поддержки системы команд и не нужно. Достаточно транслировать ассемблерный текст из одной системы команд в другую. Например, взять ассемблерный код, который сгенерировал gcc -s для i80386 (с заранее заданными ключами копмиляции) и перегнать его в другую систему команд. Если забить на оптимизацию, то задача вполне решаема. А оптимизация для такой конверсии и не нужна. По сути — работа с преобразованием текста. Если что-то где-то удастся оптимизировать, то это лишь дополнительное, но не необходимое, преимущество.

Например, взять ассемблерный код, который сгенерировал gcc -s для i80386 (с заранее заданными ключами копмиляции) и перегнать его в другую систему команд.

Предлагаете дизасмить х86 бинари и полученный дизасм кормить конвертеру?

По сути — работа с преобразованием текста

Я не особо вникал в тонкости х86 и вашего процессора, но, преобразованием текста не отделаться. Как мне кажется, придется брать во внимание архитектурную разницу процессоров: условно говоря, в х86 есть регистр флагов и возможность исполнять инструкции в зависимости от значения того или иного флага(я сейчас утрирую, опять же, например какой-нибудь ADD.Z), а в вашем процессоре такой возможности нет, то есть придется сперва сравнить регистр флагов, а потом делать сложение. И это только вершина айсберга.
Вполне возможно мы по-разному понимаем х86 транслятор в целевую архитектуру)

Нет нет. Я не предлагаю дизассемблировать бинарный код x86.

$ cat tst.c

int main() {
  puts("Hello world");
  return 0;
}

$ gcc -S tst.c

	.file	"tst.c"
	.section	.rodata
.LC0:
	.string	"Hello world"
	.text
.globl main
	.type	main, @function
main:
	leal	4(%esp), %ecx
	andl	$-16, %esp
	pushl	-4(%ecx)
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%ecx
	subl	$4, %esp
	movl	$.LC0, (%esp)
	call	puts
	movl	$0, %eax
	addl	$4, %esp
	popl	%ecx
	popl	%ebp
	leal	-4(%ecx), %esp
	ret
	.size	main, .-main
	.ident	"GCC: (Debian 4.3.2-1.1) 4.3.2"
	.section	.note.GNU-stack,"",@progbits

Вот этот текст можно перегнать в текст для макроассемблера «Эверест». По крайней мере теоретически такая возможность есть. Кстати, флаги совпадают почти полностью.

Мне кажется, куда разумнее будет сделать ц-компилятор(если его еще нет), нежели изголяться с конвертом одного асма в другой. Я слышал, что clang довольно удобно устроен для написания кастомных бекендов.

Эээээх, если бы я не пробовал сделать компилятор, то бы не говорил. По сложности это такая задача, которой можно всю жизнь заниматься. Особенно если речь идёт об оптимизации (или следования новым стандартам C++). Хороший компилятор это человеко-годы. А вот трансляцию из x86 в другой ассемблер можно за несколько недель реализовать и отладить. Нативный компилятор, разумеется, лучше, но я знаю только одного человека, который сам смог написать компилятор. И ещё одного, который написал кодогенератор для lcc для своего процессора.

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

Всё же clang весьма большая и громоздкая штука. Будет как из пушки по воробьям. Некоторые люди используют https://sites.google.com/site/lccretargetablecompiler/ для своих устройств.

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

Расширение системы команд версии 1.2

Вот тут статья о тот, зачем и почему понадобилось расширять систему команд - http://everest.l4os.ru/0xd0_second_edition/

Вот здесь пример использования расширения на примере вывода времени с момента старта устройства - http://everest.l4os.ru/uptime/

Доступна новая версия прошивки для платы Марсоход2 и новая версия ассемблера с поддержкой расширения системы команд (исполняемые файлы для Windows и Linux - никто не уйдёт обиженным).