[Ynicky 0]

Ясно, значит я все правильно понимаю и проблемы вполне реальные .

 

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

 

В ASIC-е на 0,18 - 250 МГц.

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

 

Николай.

[flipflop 0]

В ASIC-е на 0,18 - 250 МГц.

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

 

Николай.

Ого, а где вы их производите?

[Ynicky 0]

Ого, а где вы их производите?

Ну не в России же.

 

Николай.

[Ynicky 0]

Перешел в тему "Свои процессоры" из "Цифровой видеокамеры".

Предлагается всем поучаствовать в обсуждении открытого RISC процессора

с большим регистровым файлом. Выкладываю краткое описание процессора.

Пока не охвачена тема доступа к специализированным регистрам, т.е

формат команд для доступа к ним. Какие еще нужны (frame pointer, variable pointer)?

По мере устаканивания архитектуры и системы команд, буду

выкладывать проект на VHDL.

 

Николай.

torf32.pdf

[Leka 0]

Я бы упростил систему команд, все-таки большинству ASIC недоступен, и упор лучше делать на достижение приемлемых характеристик в FPGA.

 

В "своих процессорах" до сих пор самой сложной задачей являлся софт, так что конкретно обсудить архитектуру лучше после первых версий компилятора с "ассемблерного Си" (начал делать).

 

Мой ник лучше убрать из титульного листа, тк не автор данной архитектуры, и VHDL не знаю. У меня архитектура другая - нет типов, нет флагов АЛУ, и тд.

[Ynicky 0]

Я как раз и собираюсь "пощупать" процессор в FPGA.

Хотя это будет Virtex5 (на работе отдаю новую схему пп для разводки). Туда много чего влезет.

Планирую одну такую платку взять домой на время.

Но можно и попроще.

А как можно сделать if...else без флагов?

Можно, конечно, сделать команды "branch" (BR) без CMP так:

BR if RD = 0, RD /= 0, RD < 0, RD >= 0 и т.д.

Хотя это теже флаги без сохранения в регистре.

Но при этом смещение будет в 12 разрядов или в 32 разряда с предварительной командой IMM.

 

Николай.

[=AK= 10]

Предлагается всем поучаствовать в обсуждении RISC процессора с большим регистровым файлом.

1. RISC неэффективно расходует память программ

2. Большой регистровый файл - значит, контекст сохранять долго. Значит, на прерывания медленно будет реагировать.

 

А кто компилятор будет делать под такую архитектуру? Или предполагается его на ассемблере мутузить?

[Leka 0]

А как можно сделать if...else без флагов?

Пример бесфлагового процессора - NIOS II, даже переноса нет.

 

 

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

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

 

А кто компилятор будет делать под такую архитектуру? Или предполагается его на ассемблере мутузить?

Для начала - "ассемблерное" подмножество Си (см пример "N-ферзей" в предыдущей ветке), потом расширяем компилируемое подмножество.

[Ynicky 0]

Пример бесфлагового процессора - NIOS II, даже переноса нет.

Мой опыт в проектировании процессоров говорит, что надо начинать проверку с условных команд

ветвления (BR) и конвейера обработки данных. Так что желательно сейчас сосредоточиться

на этих командах. Если бы места в коде команд хватило бы на 2 регистра и смещение, то я бы

сделал команды условных ветвлений как в NIOSII и MIPS32.

 

Николай.

[Ynicky 0]

Начал делать АЛУ и сразу возникла мысль: в операциях формата RI

поменять местами RD и RS. Тогда получим:

RR: RD = RD opalu RS (пример на ассемблере: add rd,rs)

RI: RD = RS opalu IMM (пример на ассемблере: addi rd,rs,imm)

При этом в формате RI регистр-источник и регистр-приемник могут быть разными.

 

To Leka: это не усложнит компилятор?

 

Николай.

[Leka 0]

это не усложнит компилятор?

Не усложнит.

[Ynicky 0]

Подкорректировал описание.

torf32.pdf

Изменено 25 мая, 2010 пользователем Ynicky

[Leka 0]

Проблема вот в чем.

 

На уровне "ассемблерного" Си нет оптимизации, поэтому для 2х- и 3х- операндных архитектур запись одного и того-же алгоритма д/б различной для достижения оптимума по объему кода и быстродействию.

 

На примере кода N-ферзей.

Если для 3х-операндной архитектуры оптимально использование индексных массивов "arow[pos]", "arow[pos1]", и тд, то для 2х-операндной архитектуры оптимальнее будет использование модифицируемых указателей "*arow", "*arow1", и тд. Тк одной 3х-операндной инструкции:

arow[pos1] = temp;

непосредственно соответствуют три 2х-операндные инструкции:

tmp = arow;

tmp += pos1;

*tmp = temp;

Ветвления:

"if( pos != N )..." - одна бесфлаговая 3х-операндная инструкция, или

"if( pos - N != 0 )..." - две флаговые 2х-операндные инструкции (сравнение + ветвление), или

"if( tmp=pos, tmp -= N, tmp != 0 )..." - три бесфлаговые 2х-операндные инструкции.

 

Пришел к выводу, что используемое "ассемблерное" подмножество Си д/б жестко привязано к целевой архитектуре, те все преобразования выражений вынести из уровня компиляции:

"ассемблерное" подмножество Си --> машинные коды,

на уровень компиляции:

к-л подмножество Си --> "ассемблерное" подмножество Си.

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

Изменено 25 мая, 2010 пользователем Leka

[=AK= 10]

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

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

 

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

 

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

см пример "N-ферзей" в предыдущей ветке

Ссылочку приведите

[Leka 0]

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

Прерывания в процессоре с 1К регистров у меня реализованы, пишутся на "автокоде"( http://electronix.ru/forum/index.php?showt...mp;#entry605442 ), никаких потерь на входе/выходе.

 

"Ассемблерный" Си для 3х-операндной архитектуры: http://electronix.ru/forum/index.php?showt...st&p=760789