[Mahagam 0]

"У людей не хватает времени что-либо узнавать/ Они покупают вещи готовыми в магазинах"/ где ///

Так сказал Лис/// "Антуан/ёёёёё////

За ссылку на тесты спасибо/ Однако нельзя ли ближе к 8-разрядным МК? без флоат и транспортирования матриц/

Дайте честные тесты характерные для 8-разрядных МК/ без оптимизации как в ТИ//

Три или 5 тестов с исходниками на Си и оценками затрат программного кода для известных 8-разрядных МК (без Сахары)/

Буду благодарен///

За абракадабру извините/ Не придумал еще символики понятной для /// и интуитивной для умных/

 

 

 

Я даже очень оцениваю////Но нельзя ставить телегу впереди лошади как Вы предлагаете//

Нет системы команд/// нет прочего ////Включитесь в предыдущий этап - поучаствуйте в создании систему команд

для 8-разрядного МК (стекового)/ Предложите//// Однако Спасибо

повторяю просьбу: пишите на русском языке. придерживайтесь хотя бы минимальных правил пунктуации. иначе создаётся ощущение переписки с пациентом больницы имени Кащенко.

 

нет отдельно тестов для 8-разрядных МК и отдельно для 16-разрядных. как нет тетрадей для 5-го класса. и зачем вам три или пять тестов? возьмите один. но всеобъемлющий. для начала сойдёт и Dhrystone. он опять же есть в доке от TI. тест этот придуман не TI, и используется уже много лет для абсолютно разных архитектур. тест далеко не совершенен, но это самое доступное из того, что можно придумать. тем более что уже есть куча результатов этого теста.

 

поучаствовать? а смысл? представим что это ядро уже есть в виде исходников. и пока нет реализации в кремнии - используем их в качестве soft-ядра в FPGA. и что мы видим? компилятора под этот кошмар ждать лет 10-15. писать на ассемблере? опять нет смысла. ибо сэкономленное на размере памяти отыграется в размере самого ядра. я уже вижу, что ядро обойдёт по размеру MicroBlaze, при том, что частота работы будет много ниже. так зачем тратить силы на заведомо провальный проект?

[GetSmart 0]

Тема очень забавная :) Не хотелось бы чтобы её закрыли. В качестве наказания лучше банить автора на день. Тогда он быстрее найдёт все знаки препинания на своей убунте.

 

А настойчивость автора похвальна :)

[vitja 0]

Тема очень забавная Не хотелось бы чтобы её закрыли. В качестве наказания лучше банить автора на день. Тогда он быстрее найдёт все знаки препинания на своей убунте.

А настойчивость автора похвальна :)

Спасибо. (Нашел знаки препинания на чужой убунте).

Но нету темы!!!. Есть только знаки препинания от некоторых...За них меня банить....

Предлагаю ........

 

******Преабула
Единственная задача МК – обработка данных. Данные бывают входными, выходными, константами,  переменными состояния системы и промежуточными. Кроме этого данные бывают локальными, глобальными и структурированными и прочими….
******Коллизия
Как быть в стековом процессоре для обеспечения эффективного доступа к данным? 
За неимением места ниже об этом написано очень кратко.
****** Фабула
Имеется модель памяти стекового 8-разрядного МК, содержащая:
– ОЗУ, 
- ПЗУ
- стек вычислений
- стек возвратов
- данные в ОЗУ.
******Кульминация
Для выше указанной модели в системе команд 8-разрядного стекового процессора М8 предлагаются следующие  способы адресации данных (указаны мнемоники адресации):
___На стеке данных:
«пусто» - верхушка стека данных
К – катый элемент стека данных
@ - косвенно ОЗУ через верхушку стека данных
К @ - косвенно ОЗУ через катый элемент стека данных
___На стеке возвратов:
R - верхушка стека возвратов
К – катый элемент стека возвратов
@R+ - косвенно из ПЗУ через верхушку стека возвратов с постинкрементом
К @R+ - косвенно из ПЗУ через катый элемент стека возвратов с постинкрементом
___В ОЗУ:
Pi – итый элемент страницы ОЗУ 8 байт
К Pi – итый элемент страницы ОЗУ 128 байт
К К Pi – итый элемент страницы ОЗУ 2 Кбайт
(К К) @Pi - косвенно через итый элемент страницы ОЗУ
Прим. Можно реализовать более общий механизм адресации локальных данных – через регистр указатель фрейма (базы) и смещения относительно него (для 8-разрядного МК достаточно прямой страничной адресации – примеры ПИК. 1876ВЕ1 и др.)
____@# - абсолютная адресация???
____# - непосредственная адресация.
____Прим. Все указанные способы адресации являются полями байтовых команд загрузки выгрузки стека или байтовых префиксов адреса операнда источника-приемника в байтовых команд обработки данных. Длина данных задается в байт-коде команды от 1 до 4 байт.
Префикс адреса задает адрес операнда приемника для следующей стековой  байтовой команды обработки данных
****** Развязка
Примеры машинных команд М8 обработки данных…и их длина в байтах:
2 swapd – обмен 4-мя байтами между верхушкой и третьим элементом стека – 2 байта
P1 swap – обмен байтами между верхушкой стека и ОЗУ (Р1 - префикс адреса элемента в текущей странице ОЗУ) – 2 байта
@ldw     - косвенная загрузка в стек 2 байт по адресу на верхушке стека – 1 байт
3 @ld     - косвенная загрузка байта в стек по адресу третьего элемента стека – 2 байта
R 3 @ldw  - косвенная загрузка слова в стек возвратов по адресу из третьего элемента стека
(K) R (K) addw  ; RK+SK > RK      - от 2 байт
Ldw# input P4ldw add @ stP3  ; P3=input(P4) – 7 байт (для пересылки 32-разрядного данного команда stP3 меняется на stdP3)
@R+ К stwP3 – загрузка слова из ПЗУ в ячейку ОЗУ РК3.
Прим. К… и R… Pi… @ через пробел – это префиксы адреса (байтовые команды).

 

 

*****Эпилог

Получили разнообразные способы доступа к данным (в т.ч. в стеках и ПЗУ) , а также форматы команд (от 0 адресных до 1 и 2 адресных). Однако в этом надо разбираться …..

В том числе и в мнемонике, что бы была нагляднее и интуитивно понятнее?????

Изменено 10 февраля, 2009 пользователем zltigo
Последнее предупреждение - пользуйтесь тэгами

[Mahagam 0]

Спасибо. (Нашел знаки препинания на чужой убунте).

Но нету темы!!!. Есть только знаки препинания от некоторых...За них меня банить....

моя твоя понимай. банить нихт! :)

 

В том числе и в мнемонике, что бы была нагляднее и интуитивно понятнее?????

очевидно и наглядно, и интуитивно понятно, что получается монстр сложностью на уровне ядра ARM9, и крайне невысокой частотой. с арм9 не сможет конкурировать по частоте. с 8-ми битниками - по сложности.

 

кстати, где вы найдёте психа, чтобы всё это реализовал?

[vitja 0]

...пациентом больницы имени Кащенко.

нет отдельно тестов для 8-разрядных МК и отдельно для 16-разрядных.....есть один. но всеобъемлющий.....Dhrystone

...поучаствовать

1. Советую смотреть не на знаки препинания, а на водную гладь - это успокаивает...

2. "есть один. но всеобъемлющий.....Dhrystone" - спасибо...

3. Так не участвуйте....

[Leka 0]

Чтобы разобраться в сути эффективного доступа к памяти - предлагаю сравнить разные архитектуры на примере A=B[j] для случая, когда стеки, аккумуляторы и прочие регистры(исключая, конечно, регистровый файл на памяти) - "пустые". :laughing:

[Mahagam 0]

Чтобы разобраться в сути эффективного доступа к памяти - предлагаю сравнить разные архитектуры на примере A=B[j] для случая, когда стеки, аккумуляторы и прочие регистры(исключая, конечно, регистровый файл на памяти) - "пустые". :laughing:

привёл бы пример, отчего отталкиваться.

 

1. Советую смотреть не на знаки препинания, а на водную гладь - это успокаивает...

да я то не волнуюсь, а вот модератор... он может и :smile3046:

[IgorKossak 0]

Господа, хватит о личностях!

Касается всех.

[zzzzzzzz 0]

В своё время каждый строитель МК проходит подобный этап "нахождения самой лучшей архитектуры". И я был грешен... "Мудрость" же такова, что её, самой лучшей, нет в природе. В эпоху софт-процессоров есть только два пути - для экономии времени взять готовый проц. или разработать свой, совершенно не универсальный, но наилучшим образом "заточенный" под конкретную задачу.

 

Пардон за банальность, конечно. Но, поиск оптимума для универсальных процессоров имеет смысл только тогда, когда он будет реализовываться в виде чипа. А вот тут - стена. Не нужны новые. Их и так полно. При этом, сам чип - лишь малая часть работы, которую предстоит проделать для хоть какого-то спроса на него.

 

ИМХО, гораздо более интересная задача для убивания времени, с возможностью "жизни" продукта в будущем - сочинить самый минималистический МК. Чтобы меньше и проще уже ну ни как. 8 разрядов, например. Так как меньше уже совсем нет интереса у пользователей.

 

Если же есть желание строить высокоэффектиные и производительные МК - смотрите в сторону длинного командного слова типа адрес операнда1 + адрес операнда2 + адрес операнда3 + команда и многопортовое ОЗУ. Всё остальное упрощается до безобразия, нечего будет оптимизировать вообще.

[Leka 0]

//a[i] = b[j], a, b - указатели в памяти, i,j - индексы в памяти. 
//Пример: адресация, как у PDP-11, 16-разрядные команды/слова:
r1 = @#a //2слова, 3такта - минимум для однопортовой памяти
r1+= @#i //4,3
r2 = @#b //4,3
r2 += @#j //4,3
@r1 = @r2 //2,3
//18байт, 15тактов. Поправьте, если напутал. 

//"безрегистровая" 3х-операндная, 36-разрядные команды(для FPGA)
buf=b[j] //1слово,3такта - для двухпортовой блочной памяти
a[i]=buf //1,3
//2слова(9байт), 6тактов.

//Добавляйте другие архитектуры...

 

 

В своё время каждый строитель МК проходит подобный этап "нахождения самой лучшей архитектуры". И я был грешен... "Мудрость" же такова, что её, самой лучшей, нет в природе.

:a14: Поэтому ищу/пишу легконастраиваемый компилятор высокоуровневого автокода - чтобы без проблем можно было поменять архитектуру без необходимости переписывать прикладное ПО.

 

...ИМХО, гораздо более интересная задача для убивания времени, с возможностью "жизни" продукта в будущем - сочинить самый минималистический МК. Чтобы меньше и проще уже ну ни как. 8 разрядов, например. Так как меньше уже совсем нет интереса у пользователей.

 

Если же есть желание строить высокоэффектиные и производительные МК - смотрите в сторону длинного командного слова типа адрес операнда1 + адрес операнда2 + адрес операнда3 + команда и многопортовое ОЗУ. Всё остальное упрощается до безобразия, нечего будет оптимизировать вообще.

Есть уже у меня 36-разрядное - для Virtex-5 получается ~300LUT и ~100MIPS, а на подходе Spartan-6, у которого вроде те-же 6-входовые LUT-ы...

 

Уточнил(проект под сукном до написания компилятора) - получаются ~400 6-входовых ЛУТ для системы из ядра с 2К*36 памяти, COM-порта связи с компом(загрузка и запуск программы) и простого VGA контроллера - "helloworld" выводить.

Изменено 10 февраля, 2009 пользователем Leka

[vetal 0]

Поэтому ищу/пишу легконастраиваемый компилятор высокоуровневого автокода

На фтп лежит пакет Lisatek от coware - делает ассемблер и линкер(и еще много чего). Если силами сообщества удастся подобрать ключ к gpg(или pgp точнее не помню), то появится тузла которая из описания ядра поможет сделать на полуавтомате компилятор С :)

[ReAl 0]

На фтп лежит пакет Lisatek от coware - делает ассемблер и линкер(и еще много чего). Если силами сообщества удастся подобрать ключ к gpg(или pgp точнее не помню), то появится тузла которая из описания ядра поможет сделать на полуавтомате компилятор С :)

Если мне именяет склероз, на opencores.org есть проект 16-битного стекового процессора с С-компилятором на базе GCC - там, возможно, есть файлы описания архитектуры для кодогенератора. Если есть - можно попробовать взять в качестве козы, так как должны быть хоь некоторое подобие.

На мой взгляд, может и тяжелее придётся, чем ломаной коммерческой тулзой, но перспективнее.

[Leka 0]

Хочется скрыть уровень машинно-зависимого ассемблера, чтобы упростить переносимость кода, и видеть такую цепочку: ЯВУ --> автокод --> машинные коды. При этом основная оптимизация д/б на уровне ЯВУ --> автокод. Имхо, этот уровень оптимизации может дать самый большой выйгрыш, и имеет смысл попытаться воспользоваться серьезными пакетами разработки ПО - как только подтвердится перспектива.

 

Автокод - предельно упрощенный машинно-независимый ЯВУ, чтобы 1) легко можно было писать на нем несложные программы, и 2) компилятор на конкретную архитектуру можно было настроить "за пару вечеров" - тогда появится смысл в уникальных ядрах под конкретные задачи. Для этого компилятора важнее компактность и прозрачность исходника, а не оптимизирующие способности - вполне достаточно будет, чтобы не мешал оптимизации на уровне ЯВУ --> автокод (+ делал мелкую оптимизацию типа неполного вычисления логических выражений...). Тут лучше самому написать, имхо, а из готового брать только алгоритмы (только разобраться - не всегда быстрее). Пишу уже.

 

Проблема - подобрать автокод, удобный для максимально широкого круга ядер. Пример автокода, каким его вижу, уже приводил в другой ветке (N ферзей). Для "безрегистровой архитектуры" вроде удобно, а вот для регистровых/стековых... не ясно пока.

Изменено 10 февраля, 2009 пользователем Leka

[Rst7 5]

Я вот не пойму смысла этих баталий? Слабо покурить внутреннее устройство GCC, чтобы обнаружить, что сначала он компилит программу в некий псевдокод для виртуальной машины. Вот если генератор из псевдокода в асм для вновь разрабатываемой архитектуры будет требовать минимум извращений, то тогда и архитектура будет оптимальной для поддержки ее гнусем. Это, конечно, при выполнении других условий, например, минимизации количества лутов, или максимального быстродействия, или еще каких, стоящих перед разработчиками.

 

Кстати, гад по портированию гнуся существует в природе, с вдумчивого изучения этого документа и стоит начать.

[Leka 0]

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

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