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

Из:

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

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

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

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

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

А нету временных переменных. Как после:
#define int static int
и тп.


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

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

Николай.

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

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

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


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

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

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

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

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

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

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

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

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

Вообще то лучше сделать служебные регистры в виде сопроцессора как в MIPS32,
и доступ к ним организовать через команды mtcp (move to coprocessor) и mfcp (move from coprocessor).
А что касается компиляторов, то я дело имел только с LCC.
И еще, меня никто не поправил насчет нового формата RI.
Тут я ошибся (сказывается опыт работы с 3-х операндными командами).
Для регистров есть только одно поле в команде, так что 2 регистра и смещение не могут быть
в одной команде 2-х операндных инструкций.
Описание нужно вернуть к версии 1.0.0.

Николай.



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

Николай.

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


В ветке, где приводил пример программы N-ферзей на автокоде, предлагал сравнить эффективность архитектур на разных софт-процессорах - никто не откликнулся.
Эффективность использования памяти программ гораздо сильнее зависит от качества кода, чем от разрядности команд. Пример - Tiny C Compiler, 100Кб кода против десятков Мб от других разработчиков.
Удачное разбиение кода на маленькие подпрограммы - самый эффективный способ сжать код, поэтому важны малые издержки на вызовы пп. Например, у меня команда call совмещена с пересылкой регистр-регистр, а ret - c любой операцией алу:
f(&a); - одна инструкция на вызов пп с передачей аргумента,
f(int *a){ return *a >>= 8; } - одна инструкция на всю пп.

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

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

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

Ну вот, выкладываю первую версию процессора.
Проект сделан в ACTIVE-HDL 8.2. На нем проще моделировать.
На конечном этапе сделаю в ISE для Xilinx и в QuartusII для альтеры.
Память программ и регистровый файл сделал пока поведенческими для быстроты моделирования.
Программу проверки пишу в кодах (файл prg.txt). Оказалось не очень нудно,
т.к. простые форматы команд. Отладил почти все условия ветвления в командах BRcc.
АЛУ полностью пока не проверял (только частично в тестах BRcc).
To Leka: В принципе, можно уже моделировать программу N-ферзей.
Хорошо бы компилятор мог на выходе записывать текстовый файл (как prg.txt).
Но это не обязательно. Я, наверно, смогу сам преобразовать из других форматов.
И еще: В директории doc находится новая версия описания RF32.

Николай.

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