[=AK= 10]

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

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

[Leka 0]

Из:

queens( int N ){
int
    count,
    arow[20], 
...

автоматически создается:

int 
    queens_return;
    queens_N;
    queens_count,
    queens_arow[20], 
...
queens(){
...

с соответствующим переименованием всех переменных.

Все переменные стали глобальными, вызов "cnt=queens(8);" преобразуется в:

  queens_N=8;
  queens();
  cnt=queens_return;

И так для всех подпрограмм.

Если не хватит ~1К адресного пространства для всех таких переменных, тогда только и придется организовывать программное сохранение/восстановление контеста, и тп - для некритичного кода. И вовсе не обязательно сохранять/восстанвливать весь регистровый файл. Имхо, очень удобно для небольших систем без монстроидальных ОС.

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

[=AK= 10]

Все переменные стали глобальными,

...

И так для всех подпрограмм.

Я в одной подпрограмме вызову другую, а она пропишет свои временные переменные поверх задействованных. Вот и придется вам весь код раскатать в плоский "блин", без подпрограмм (функций). Или же строго следить за "уровнем": main может использовать одни переменные, подпрограммы первого уровня (их можно вызывать только из main) - другие, подпрограммы второго уровня - свой набор, и т.п. Маразм, короче. Архаическое программирование в стиле старых PIC-ов на ассемблере.

[Leka 0]

А нету временных переменных. Как после:

#define int static int

и тп.

 

 

Проверено на практике на "автокоде" - подпрограммы из подпрограмм вызываются без к-л ограничений, прерывания тоже работают.

[Ynicky 0]

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

Может я, конечно, чего не понимаю.

Я пока не задавал глупых вопросов про служебные регистры, потому что думал рано. Но их в систему команд все равно придется вводить. К ним я планировал добавить "frame pointer" или как его там назвать. Компилятор знает сколько регистров надо зарезервировать для подпрограммы. При вызове подпрограммы во "frame pointer" записывается это значение (или добавляется к его содержимому). А дальше адрес регистров вычисляется в аппаратуре прибавлением текущего адреса к "frame pointer".

При выходе из подпрограммы - вычитать это значение.

Но что делать, если "frame pointer" перешагнет через максимальное число регистров? Тут я могу завести это событие на NMI или вызвать TRAP. Поправьте, если что-то недопонял.

 

Николай.

Изменено 1 июня, 2010 пользователем Omen_13

[Leka 0]

Я пока не задавал глупых вопросов про служебные регистры,

потому что думал рано. Но их в систему команд все равно

придется вводить. К ним я планировал добавить "frame pointer"

или как его там назвать...

Тогда регистры придется делить на локальные и глобальные, и делать мультиплексор(или что другое) на входе адреса. И сразу делать 3х-операндную архитектуру, тк для 2х-операндной такое не имеет смысла, имхо.

 

Как обращаться к служебным регистрам из Си - еще не решил, важно обеспечить простоту отладки "ассемблерного" Си-кода на ПК со стандартным Си-компилятором (сам использую открытый Tiny C Compiler). Предлагайте варианты.

 

 

http://ru.wikipedia.org/wiki/Tiny_C_Compiler

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

[Leka 0]

Гораздо проще придумать свой язык и компилятор к нему, чем делать компилятор к Си.

Масса вопросов типа:

main(){ a() || b() && c(); }

В каком порядке будут вызываться функции a(), b(), c(), и почему? :smile3046:

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

[Leka 0]

Вся система команд с учетом архитектуры будет описываться в отдельном файле, в таком примерно формате:

dddddddddddd += ssssssssssss
    001 01000 dddddddddddd ssssssssssss

dddddddddddd += kkkkkkkkkkkk
    010 01000 kkkkkkkkkkkk dddddddddddd 

dddddddddddd += hhhhhhhhhhhhhhhhhhhhkkkkkkkkkkkk
    000 00101 xxxxhhhhhhhh hhhhhhhhhhhh
    010 01000 kkkkkkkkkkkk dddddddddddd 

* ssssssssssss = dddddddddddd
    011 xx110 dddddddddddd ssssssssssss

dddddddddddd = * ssssssssssss   
    011 xx010 dddddddddddd ssssssssssss

dddddddddddd < ssssssssssss
    001 00110 dddddddddddd ssssssssssss
    110 x0100 pppppppppppp pppppppppppp
...

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

[=AK= 10]

А нету временных переменных.

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

 

Я, кстати, свои первые программы писал для машины с 45-разрядными словами и 3-адресными командами. БЭСМ-4 называлась, чудо техники начала 60-х. Дежавю.

[Ynicky 0]

Тогда регистры придется делить на локальные и глобальные, и делать мультиплексор(или что другое) на входе адреса. И сразу делать 3х-операндную архитектуру, тк для 2х-операндной такое не имеет смысла, имхо.

Как обращаться к служебным регистрам из Си - еще не решил, важно обеспечить простоту отладки "ассемблерного" Си-кода на ПК со стандартным Си-компилятором (сам использую открытый Tiny C Compiler). Предлагайте варианты.

Вообще то лучше сделать служебные регистры в виде сопроцессора как в MIPS32,

и доступ к ним организовать через команды mtcp (move to coprocessor) и mfcp (move from coprocessor).

А что касается компиляторов, то я дело имел только с LCC.

И еще, меня никто не поправил насчет нового формата RI.

Тут я ошибся (сказывается опыт работы с 3-х операндными командами).

Для регистров есть только одно поле в команде, так что 2 регистра и смещение не могут быть

в одной команде 2-х операндных инструкций.

Описание нужно вернуть к версии 1.0.0.

 

Николай.

 

 

ваш процессор неэффективен по использованию памяти программ (поскольку RISC)

Вы, наверно, имеете в виду процессоры с фиксированной длиной команд, а не RISC.

Есть RISC-и с переменной длиной команд, где код используется эффективно.

Но это (фиксированная длина команд) окупается простотой реализации.

 

Николай.

[Leka 0]

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

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

 

То есть, мало того, что ваш процессор неэффективен по использованию памяти программ (поскольку RISC), он, оказывается, и память данных (регистры) транжирит. По-моему, от таких архитектур давным-давно отказались, как от неэффективных.

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

Эффективность использования памяти программ гораздо сильнее зависит от качества кода, чем от разрядности команд. Пример - Tiny C Compiler, 100Кб кода против десятков Мб от других разработчиков.

Удачное разбиение кода на маленькие подпрограммы - самый эффективный способ сжать код, поэтому важны малые издержки на вызовы пп. Например, у меня команда call совмещена с пересылкой регистр-регистр, а ret - c любой операцией алу:

f(&a); - одна инструкция на вызов пп с передачей аргумента,

f(int *a){ return *a >>= 8; } - одна инструкция на всю пп.

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

[=AK= 10]

сравнить эффективность архитектур

Есть специальная контора, которая сравнивает - http://www.eembc.org/ Бенчмарки, приведенные в презентациях PTSC, меня лично вполне убедили, что с большим отрывом лидирует стековая архитектура

 

[Leka 0]

Презентации - неинтересно.

Первая попавшаяся нерекламная ссылка по IGNITE: http://java.epicentertech.com/Archive_Embe...sor%20-%20Java/

[Ynicky 0]

Ну вот, выкладываю первую версию процессора.

Проект сделан в ACTIVE-HDL 8.2. На нем проще моделировать.

На конечном этапе сделаю в ISE для Xilinx и в QuartusII для альтеры.

Память программ и регистровый файл сделал пока поведенческими для быстроты моделирования.

Программу проверки пишу в кодах (файл prg.txt). Оказалось не очень нудно,

т.к. простые форматы команд. Отладил почти все условия ветвления в командах BRcc.

АЛУ полностью пока не проверял (только частично в тестах BRcc).

To Leka: В принципе, можно уже моделировать программу N-ферзей.

Хорошо бы компилятор мог на выходе записывать текстовый файл (как prg.txt).

Но это не обязательно. Я, наверно, смогу сам преобразовать из других форматов.

И еще: В директории doc находится новая версия описания RF32.

 

Николай.

rf32.rar

[des00 25]

Ну вот, выкладываю первую версию процессора.

Спасибо конечно, но вот те кто не пользуются альедеком должны вытаскивать структуру из скомпилированного bdf файла? Это я к тому что структурная и функциональная схема не помешали бы, также как и описание портов ввода/вывода процессора %)