[Mahagam 0]

а) Вы хотите за 1 такт что-то большее, чем R3=R1+R2? Это идеология всех современных ядер, начиная от микроблэйзов, ниосов, армов и заканчивая спарками.

б) Память в любой системе - слабое место. Дюже это сколько?

опять упомяну PDP11. например хочется чего-то подобного на add @R1+, @R2+

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

 

и, кстати, вы неправы относительно, например, АРМа, там в одну команду пихается тьма действий. другое дело, что браться за реализацию ядра арма я буду только под принуждением :)

[Leka 0]

В вариант с внутренней памятью программ/данных можно будет добавить поддержку внешней SPI флешки - для неторопливого выполнения длинного внешнего кода.

[des00 25]

опять упомяну PDP11. например хочется чего-то подобного на add @R1+, @R2+

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

 

Года 2-3 назад была подобная тема, помню высказывание SM, он говорил о том что при современном уровне развития электроники идет откат от RISC архитектур в пользу CISC. Т.к. они более гибкие у уже почти не проигрывают в производительности RISC.

 

PDP11 ИМХО очень красивая архитектура для фпга, вот выйду на пенсию займусь %)

 

и, кстати, вы неправы относительно, например, АРМа, там в одну команду пихается тьма действий. другое дело, что браться за реализацию ядра арма я буду только под принуждением :)

 

подход микроблейза по своей сути арм7 и есть %)

[Leka 0]

Что делаю:

- фон-неймановская архитектура, 32 разряда команда/данные

- внутренняя 2х-портовая память команд/данных

- трехоперандная система команд

- минимальный набор инструкций (алу: + - & | ^ div2, переходы: < <= == != > >=) - 2..4 такта в зависимости от типа адресации (a,*a,*a, proc, *proc).

Примеры:

a = b + c ... *a = *b ^ *c

a += *b[c] ... *a ^= *c

label(a < B ) ... label(*a >= *B )

proc(a) ... *proc(*a) - переход на подпрограмму с передачей аргумента.

Написано и проверено на синтезаторе 3/4 кода, вроде укладывается в ожидаемые <500лут, >75МГц для Спартана. Сначала хотел 16-разрядное АЛУ, но для фон-неймановской архитектуры появляются лишние мультиплексоры(и задержки), поэтому отказался пока от такого варианта.

Дописал, ~400лут ~100МГц для Спартан3, ~300лут ~200МГц для Virtex5. Так что "безрегистровая" архитектура - в самый раз для FPGA, имхо.

[vetal 0]

Тут рано судить. Надо собирать реальную систему(хотя бы простейшую timer+uart+пару кило внутрикристальной памяти) и смотреть. Для полноты надо еще прерывания, shifter и возможность работать с байтами/шортами.

Если не сложно - соберите ваш код под cyclone и огласите результат.

Ну а дальше - сравнение эффективности на памяти CL2-CL3 без кэша.

 

Так что "безрегистровая" архитектура - в самый раз для FPGA, имхо.

Я уже упоминал по моему - у вас не безрегистровая архитектура, а регистровая с вынесенным относительно ядра регистровым файлом :) Вопрос стоит как раз в эффективности вынесения.

[Leka 0]

Цифры для ядра с памятью 2К*32. Установлен только ISE, так что для циклона пока нет возможности синтезировать, но ожидаю сопоставимые цифры. Периферии пока нет, идеология обмена поменялась - все переделывать придется.

[Mahagam 0]

Цифры для ядра с памятью 2К*32. Установлен только ISE, так что для циклона пока нет возможности синтезировать, но ожидаю сопоставимые цифры. Периферии пока нет, идеология обмена поменялась - все переделывать придется.

что там с новой идеологией?

[Leka 0]

что там с новой идеологией?

Обмен с периферией только в виде выполнения внешней команды c=ext(f,a,b ), где f - номер внешней команды/устройства, любой тип адресации a,b,c. Чтобы можно было, например: умножение f=1 --> c=ext(1,a,b ) --> c=a*b, запись в видеобуфер f=2 c=ext(2,a,b ) --> c=vga[a], vga[a]=b, и тд и тп.

Изменено 27 октября, 2008 пользователем Leka

[des00 25]

Обмен с периферией только в виде выполнения внешней команды c=ext(f,a,b ), где f - номер внешней команды/устройства, любой тип адресации a,b,c. Чтобы можно было, например: умножение f=1 --> c=ext(1,a,b ) --> c=a*b, запись в видеобуфер f=2 c=ext(2,a,b ) --> c=vga[a], vga[a]=b, и тд и тп.

 

решил пройтись по opencores

 

а вот это не безрегистровый ли процессор ? :))

 

http://opencores.org/projects.cgi/web/tiny8/overview

 

The registers resides in RAM addressed via a base pointer in the WP register (like the TMS9900).

[Leka 0]

Описание(архитектура, система команд, ...) - интересно взглянуть, но логина нет пока(запрос послал). Свой опробовал на простом примере(вывод фонта в цикле на VGA), и отложил в сторону, сейчас главное - прикрутить ЯВУ. Требования к ЯВУ:

1) из распространенных, с исходниками,

2) легко настраиваемый компилятор - самокомпилирующийся, и с минимумом

машинно-зависимого кода(<1К строк),

3) генерация компактного(<2Кслов) кода.

[des00 25]

Описание(архитектура, система команд, ...) - интересно взглянуть, но логина нет пока(запрос послал).

 

Если еще не пришло

tiny8.tar.tar

[Leka 0]

Посмотрел, самый информативный файл - opcodes.txt, имхо. Что заметил:

1) load/store архитектура - косвенная адресация только для команды MOV(не считая JMP),

2) отсутствие команды перехода на подпрограмму,

3) основные команды - 3х-байтные,

4) отсутствие IN/OUT команд.

 

По поводу ЯВУ - пересмотрел кучу проектов в инете - так и не выбрал

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

[Leka 0]

Пишу компилятор автокода "безрегистрового"(с регистровым файлом на памяти) софт-ядра:

- более низкий уровень - только в машинных кодах

- построчная запись операторов

- оптимизация только в пределах строки

- одна строка на автокоде может транслироваться в несколько машинных команд

- отсутствие типов - всегда подразумевается "integer"

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

Цель введенных ограничений - переносимость программ между разными версиями ядер.

Пример программы "N ферзей" (из ветки "Паскаль для АВР") на автокоде:

procedure queens(N, count)
var 
    arow[N], aleft[N], aright[N], aposs[N]
    poss, place, val, pos
begin    
    count = 0
    val = shl(1, N) - 1
    pos = 1
    arow[1] = 0
    aleft[1] = 0
    aright[1] = 0
    aposs[1] = shr(1, N / 2)
    poss = aposs[1]
    while pos <> 0 
          if poss <> 0 
              place = poss & - poss
              poss &= ~ place 
              if  pos = 1 and poss = 0 and (N & 1) <> 0 
                  count *= 2
              end    
              if pos <> N 
                  aposs[pos] = poss               
                  arow[pos + 1] = arow[pos] | place 
                  aleft[pos + 1] = (aleft[pos] | place) * 2
                  aright[pos + 1] = (aright[pos] | place) / 2 
                  poss = ~ (arow[pos + 1] | aleft[pos + 1] | aright[pos + 1]) & val
                  pos += 1
              else 
                  count += 1
              end
        else
            pos -= 1
            poss = aposs[pos]
        end
    end
    if (N & 1) = 0
        count *= 2
    end 
end

[Leka 0]

Перерыв был большой в этом проекте...

 

Посмотрел для Cyclone3 - ~600 ЛУТ, ~80 МГц, 10 блоков M9K.

На LatticeXP2 лучше переносится - ~500 ЛУТ, ~115 МГц, 4 блока памяти (по 18К).

 

Компилятор в тетрады почти готов (queens компилируется в ~60 команд), дальше тривиально - перевод в машинные коды. Сейчас ~700 строк на Паскале, думаю уложиться в ~1000 строк - рефакторинг проще будет делать. В планах - набить 64 ядра с 0.5Кслов памяти каждое в Spartan3A-DSP, и запустить queens впараллель - сравню с ПК.

[SM 0]

Вы для Lattice PAR делали? Или оценка по какому-нить Precision? Если PAR не делали, то эту оценку надо выкинуть на свалку.