Цифровая видеокамера Опции

[Ynicky]

Долго думал и решил создать новую тему.
Полтора года назад мое начальство дало задание проработать проект цифровой видеокамеры,
но потом от него отказалось. А мне это до сих пор не дает покоя.
На тот момент у меня уже был опыт создания SOC (систем на кристалле) на своих процессорах.
Был даже проект векторного 64 разрядного сопроцессора (SIMD). Правда он так и не был реализован в ASIC-е.
С тех пор, занимаясь "плановой" работой, я нахожу немного времени для проекта цифровой видеокамеры.
Уже сделано почти все, кроме вывода изображения на ЖК экран. Но надежда на то, что камера когда-нибудь
будет востребована, с каждым днем "тает". Конечно я понимаю, что это коммерчески не выгодно.
Тягаться с известными зарубежными фирмами, выпускающими видеокамеры, бессмысленно.
Но для души такой проект - то что надо. Даже если он и не будет реализован. Наработанный опыт не
пройдет даром. Мысль о том что проект никому не нужен заставила меня обратиться на форум.
Выложить его, как есть, всем желающим я не могу по причине того, что это собственность предприятия.
Тем более что ассемблер к RISC процессору и векторному сопроцессору написан не мною.
Так вот, чтобы не нарушать коммерческую тайну и право собственности, я решил разработать новый RISC
процессор и векторный сопроцессор к нему в свободное от основной работы время (т.е. дома). Так как
опыт и наработки уже есть, это займет не очень много времени. Их то я (RISC и VCP) и мог бы выложить на форуме.
Проблема только в программном обеспечении. Чтобы быстро отладить процессор и сопроцессор, нужен как минимум
ассемблер с простейшей функцией разделения кода и данных, так как RISC ядро имеет гарвардскую архитектуру.
А как максимум, не мешало бы иметь gcc или binutils для разработки прикладного ПО.
В принципе, написать ассемблер мог бы и я, но тогда это займет много времени и не будет стимула
выкладывать все на форуме, да и заниматься этим. Может найдется среди вас энтузиаст,
который бы взялся хотя бы за ассемблер. Если таких нет, может кто знает к кому обратиться?
"С" компилятор на основе LCC мог бы написать и я в дальнейшем (если не будет gcc или binutils).
Чтобы иметь представление о RISC ядре, выкладываю пока не полное описание.

Николай.

Прикрепленные файлы

 torisc32.pdf ( 94.58 килобайт ) Кол-во скачиваний: 235

 

[Leka]

Вот что пришло в голову.

Длинное арифметическое выражение можно упростить до "ассемблерного" вида без использования низкоуровневых конструкций:

Код

// a = b+c*d+e;
int local;
local = c*d;
local += b;
a = local + e;

Длинный if-else упростить без явного использования условных "goto" в общем случае нельзя. Для примера можно взять:
if( (a==1 && b==2 || c==3 && d == 4 ) && ( e == 5 || f == 6) ) { ... } else { ... }

Но если запретить в "урезанном ЯВУ" изменение приоритета "||" и "&&" скобками, то появляется возможность упрощения до "ассемблерного" вида без явного использования условных "goto":

Код

// if( (a & b) == 1 &&  (c & d) == 2 || (e & f) == 3 ) { ... } else { ... }
int local;
if(
  ( local = a & b,
    local == 1 )
&&
  ( local = c & d,
    local == 2 )
||
  ( local = e & f,
    local == 3 )
){
  ...
} else {
  ...
}

Т.о. появляется возможность делать основную компиляцию в рамках ЯВУ:
Си/Паскаль/... --> "ассемблерный" Си/Паскаль/... --> "автокод" (улучшение читабельности) --> машинные коды. Как насчет открытой разработки такой цепочки?

"Автокод" - синтаксис наподобие:

Код

if
  local = a & b
  local == 1
and
  local = c & d
  local == 2
or
  local = e & f
  local == 3
then
  ...
else
  ...
end

Сообщение отредактировал Leka - May 17 2010, 17:52

[Leka]

Т.о. появляется возможность делать основную компиляцию в рамках ЯВУ:
Си/Паскаль/... --> "ассемблерный" Си/Паскаль/... --> "автокод" (улучшение читабельности) --> машинные коды.

Все-таки есть польза от форума - обратил внимание, что текущий "автокод" очень похож на урезанный Си, в котором:
- отсутствуют типы, все переменные/массивы объявляются, как "static" (большой регистровый файл в памяти),
- только индексная адресация, массивы объявляются через "[ ]",
- упрощенная запись выражений - как в Паскале,
- нет структур, switch (взамен есть if-elsif-...-else).
Так что, пожалуй, выкину "автокод", а компиляцию сделаю с "ассемблерного" подмножества Си. Тогда будет цепочка: подмножество Си --> "ассемблерное" подмножество Си --> машинные коды.

Образец "ассемблерного" Си(кроме "printf") - на примере N-ферзей:

CODE

queens( static N ){
static
count,
arow[20],
aleft[20],
aright[20],
aposs[20],
poss,
place,
val,
pos,
pos1,
N1,
temp,
temp1;

count = 0;
N1= N & 1;
temp = 1 << N;
val = temp - 1;
temp = N >> 1;
poss = val >> temp;
arow[1] = 0;
aleft[1] = 0;
aright[1] = 0;
aposs[1] = poss;
pos = 1;
do{
if( poss != 0 ){
temp = -poss;
place = poss & temp;
temp = ~place;
poss = poss & temp;
if( pos == N1 && poss == 0 ){
count = count << 1;
}
if( pos != N ){
pos1 = pos + 1;
aposs[pos] = poss;
temp = arow[pos];
temp = temp | place;
arow[pos1] = temp;
temp = aleft[pos];
temp = temp | place;
temp = temp << 1;
aleft[pos1] = temp;
temp = aright[pos];
temp = temp | place;
temp = temp >> 1;
aright[pos1] = temp;
temp = arow[pos1];
temp1 = aleft[pos1];
temp = temp | temp1;
temp1 = aright[pos1];
temp = temp | temp1;
temp = ~temp;
temp = temp & val;
poss = temp;
pos = pos1;
}else{
count = count + 1;
}
}else{
pos = pos - 1;
poss = aposs[pos];
}
}while( pos != 0 );
if( N1 == 0 ){
count = count << 1;
}
return count;
}

main(){
static N;
for(N = 1; N < 15; N = N + 1){
printf("queens(%d)=%d \n", N, queens(N));
}
}

В "ассемблерном" подмножестве нет длинных выражений --> непосредственно транслируются в 3x-операндные машинные коды.

Предлагаю открытый проект софт-процессора с большим регистровым файлом в памяти(c Гарвардской архитектурой - Циклоны/Спартаны дадут ~100MIPS). Мне он не нужен(есть свой), но интересует развитие идеи компиляции в рамках ЯВУ(когда промежуточным языком является подмножество ЯВУ), и под этот проект готов взять на себя открытый компилятор с "ассемблерного" Си.

Сообщение отредактировал Omen_13 - Jun 1 2010, 19:26

Причина редактирования: Оформление кода

[Ynicky]

Предлагаю открытый проект софт-процессора с большим регистровым файлом в памяти(c Гарвардской архитектурой - Циклоны/Спартаны дадут ~100MIPS). Мне он не нужен(есть свой), но интересует развитие идеи компиляции в рамках ЯВУ(когда промежуточным языком является подмножество ЯВУ), и под этот проект готов взять на себя открытый компилятор с "ассемблерного" Си.

Замечательно!
Какого объема нужен регистровый файл?
PS. Может перейти в тему "Свои процессоры".

Николай.

[Leka]

Какого объема нужен регистровый файл?
PS. Может перейти в тему "Свои процессоры".

При большом регистровом файле константы удобно брать из регистров, а не из команды. Массивы - в отдельной памяти. Поэтому желаемое число регистров = число статических переменных + число констант.
Для Фон-Неймановской архитектуры логично все локальные переменные нерекурсивных(нереентрабельных) функций делать статическими - код все-равно занимает в разы больше места. Чем больше окно регистрового файла, тем лучше. У меня 1К при 36-разрядном коде: 6 бит - код операции, 30 бит - 3 операнда. Неиспользуемые регистры м/б заняты командами/данными(массивами). Для Гарвардской архитектуры лишние регистры никак не используются, но все-равно лучше взять по-максимуму (урезать проще, чем нарастить).

Можно продолжить в "Свои процессоры".

У меня отлаженная Фон-Неймановская архитектура(2 такта на инструкцию при ~100МГц), и незаконченная переределка на Гарвардскую(1 такт на инструкцию, кроме переходов) - задача отошла на задний план. Активное участие обещаю только в разработке компилятора (устрою перерывчик себе в "синтезе программ", а то "тихо шифером шурша, ...").