если вам без разницы ядро почему бы не взять xsoc16 http://www.fpgacpu.org/ проект давно вылизан, есть си компилятор. При этом проц затачивался под фпга

Это вот чтоли? :
If you accept the license terms, you may download xsoc-beta-093.zip. (3.3 MB)
Последняя новость на сайте датирована 2003 годом. Сделан в Xilinx 1.5. Есть Verilog - версия.
В нете запрос на тему xsoc16 практически ничего не дал.
В общем создаётся впечатление умершего проекта. Почему его нет на опенкорках?
Вы пробовали работать с ним? Как впечатления? Какие достоинства и недостатки (архитектуру не нашел ещё, как компилятор? ANSI - c со структурами ?)
А так интересный проект. попробую поковыряться на днях

Вставлю свои пару строк.
С этого процессора начинал обучаться разработке своих процессоров.
Очень оказался полезен в плане изучения архитектуры и системы команд.
Из всех изученных мною 16ти разрядных процессоров - этот оказался самым лучшим.
У него очень простая и в то же время объемная система команд.
И даже остался резерв (можно дополнить своими командами).
С компилятор - LCC. Легко настраивается на нужную архитектуру и систему команд посредством .md(machine description) файла. Добавить новые команды не составляет большого труда.
Ассемблер правда простенький, без компоновщика, но для большинства приложений этого достаточно.
Есть исходники. Добавить свои команды тоже не трудно.
Единственный, на мой взгляд, недостаток - это нет средств внутрисхемной отладки.
Но это можно сделать самому.

Николай.

Ynicky уже сказал плюсы этого проекта, немного добавлю



если проц отлажен, оптимален (по критерию ресурса фпга), самодостаточен и доведен до логического конца зачем его развивать? Лежит себе рабочая вешь, есть не просит. На опенкоресы не выкладывают потому как не нужно %)

я его реверсил в исследовательских целях, уж больно у него алу красиво уложено %)

Да, реально больше, несмотря на 8-битность. У 51 декодер инструкций такой, что ужос. Плюс умножитель, который практически во всех реализациях параллельный. Плюс всякие там da a, xchd которые создают лишние мультиплексоры и функциональные узлы. В отличие от MSP, который голимый RISC вплоть аж до того, что счетчик команд и указатель стека в РОНах, вследствие чего декодера инструкций, можно сказать, почти нет, все сигналы идут проводами прямо на исполнительные блоки, да и самих команд (классов команд по формату опкода) раз, два и обчелся.


Автору - а чем LatticeMico8 не устраивает? И под фпга заточен, и компилер есть, и исходники...

Я конечно извиняюсь, но какой же мсп430 риск? Он вообще без регистров работать может (ну кроме пц, сп, константных), держа все переменные в памяти. И в пределах 1 команды делать 2 раза чтения и 1 раз запись в память модифицированного значения. Что-то как-то других рисков ТАКИХ я не видел

Я конечно, извиняюсь, но каким образом выражение "Reduced Instruction Set" относится к количеству регистров и/или методов адресации? Это показатель количества инструкций, которых у MSP430 всего лишь 27 штук. Для сравнения - даже у Microchip PIC12 их 33, что больше, чем у MSP (кстати он, pic, тоже "вообще без регистров" работать может, только W и счетчик команд). Не говоря про пресловутый ARM. Но собственно, основной показатель "risc-овости" - сложность декодера инструкций - у MSP "risc-ее", чем у многих-многих других risc-ов.

ЗЫ. А вообще - это дежавю. Уже обобсуждались в оффтопике на эту тему.

Пусть выполнение инструкций: a = b * c, a = b << c, a = b >> c, ...(и тд и тп) организовано через обращение к внешнему устройству N(задается в поле команды): a = port_N(b, c). Сколько инструкций? 1 ? 3+ ?

Ну можно конечно посчитать кол-во команд, и сказать что риск (ага, меньше чем у пика).
А можно подумать вот как:
каждлая команда в 430 имеет длину от 1 до 3 слов. При этом она может инициировать от 0 до 3 аксессов в память, выполняя вычисления с выбранными и записываемыми данными.
А теперь сравним с настоящими рисками: mips, sparc, power, arm: длина команды фиксированная, операции или внутри регистров, или запись-чтение регистров из памяти без операций над данными.

Сообщение отредактировал LordVader - Nov 17 2009, 20:02

Еще раз вопрос. Где в аббревиатуре "Reduced Instruction Set" говорится о количестве доступов в память, о том, сколько действий выполняет инструкция, и т.п. параметрах системы команд? Исключительно о количестве инструкций. Reduced по отношению к CISC. И ничего более. Решит производитель, что вот это у него CISC, а это - RISC. И так и будет. И не путайте LOAD-STORE архитектуру и RISC - это две не пересекающиеся вещи. RISC не обязан быть LOAD-STORE, и наоборот, LOAD-STORE не обязан быть RISC.

Что касается переменной длины инструкций у MSP - это кажущаяся с первого поверхностного взгляда вещь. Обман зрения. На самом деле длина инструкции у него всегда 16 бит, а все эти якобы удлинения - это автоинкрементная адресация с регистром R7 - просто выборка операнда из памяти.

PS. Я продолжать этот бессмысленный спор не буду. Что же касается реальных архитектурных решений и примененных технологий - тут прав лишь разработчик/производитель. Только он один знает, что и зачем применил, и как построил декодер инструкций, как у RISC, из кучи проводов, или как у CISC, из кучи логики и дешифраторов. И только он вправе корректно определять архитектуру своего детища, если ее не открывает в виде схем и/или исходных текстов.

всего не углядиш... у кажной штуки свои прибамбасы.
http://electronix.ru/forum/lofiversion/index.php/t38902.html

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

И, заметьте, сейчас версия 3.0, а не 2.4, о которой речь была в той ветке. По крайней мере глюк с переносом точно устранен:



Думаю, что и с прерываниями все ОК, так как они там тоже много переделали.

Я вправе иметь своё мнение. И моё мнение таково, что RISC я не понимаю как дословную аббревиатуру. И знакомство с некоторым кол-вом процессоров заставляет думать, что риск - это не кол-во команд, а прежде всего их простота. и в том числе load-store. И почему-то так считают некоторые умные люди, которые пишут книги.


Автоинкрементация она, когда проц не конвееризированный, как 430ый в оригинале или как топиковый. Посмотрите, как извращаются в современных x86-процах на этапе "fetch opcode".


Да ради бога. А я вправе определять архитектуру его детища, как мне удобно

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

например РРС - общепризнано, что RISC - но инструкций там побольше чем у х86

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

чего-то примера хорошего не придумал - но например, в доке на ОМАР-L138 всюду упоминается, что это супер-лоу-павер девайс, а цифирька то - пол ватта