16+
Пятница
24 февраля
Вход |Карта сайта | |Upload |codebook | PARTS

 О смысле всего сущего 0xFF

 Средства и методы разработки

 Мобильная и беспроводная связь

 Блошиный рынок Объявления

caxapa

Микроконтроллеры ARM 

AVR PIC MSP PLD,FPGA,DSP 

Кибернетика Технологии 

Схемы, платы, компоненты 

Средства и методы разработки

 
   Новая тема Правила Регистрация Поиск »» Архив
Вернуться в конференциюТопик полностью
Evgeny_CD  (28.11.2016 01:33, ссылка, ссылка, просмотров: 12711)
По мотивам опроса насчет "идеального ядра" -> Описание настоящего "дрим ядра" вложено. 
Основные идеи: * долой линейную память * систему тегов в массы * ID потока на аппаратном уровне. * автоматический синтезх всего (уже опиcано ->) 1. Вместо "просто памяти" - переход к объектам. Есть понятие - ID объекта (можно адрес первого элемента объекта), и есть понятие offset - смещение от начала объекта (представляемого как линейная последовательность байтов....long long) для выполнения операции. Вырожденные объекты = современным переменным - offset =0. Суть в том, чтобы управление памятью возложить на аппаратуру. И когда я добавил элементов в массив переменной длины - пусть железяка сама аллокирует память, выстраивает списки из сегментиков памяти и проч. Полное отсуствие многих проблем с фрагментацией памяти и сильное повышение быстродействия - по сравнению с С++ "абстракциями высокого уровня". 2. К каждому объекту прикладываем дескриптор. Права доступа, тип объекта (чтобы по казателю на signed не лазили в unsigned), максимальный размер и прочее. Это теги Эльбруса в переосмысленном виде. Аппартный учет количества ссылок на объект сюда же. Чтобы сборка мусора была простым и быстрым занятием. Лучше всего ее сделать аппаратно. 3. Аппаратная поддержка ID текущего потока. Т.е. RTOS в режиме супервизора ставит в регистре ID потока, который сейчас будет исполняться, и переключает контекст. Этот ID учитывается при работе с декскрипторами. Контекст сохраняется|восстанавливается аппаратно по ID потока. 4. "Автоматический синтез всего" позволит иметь фичастое ядро разумного размера, с набором фич, сторого отвечеющем решаемой задаче. Нафига козе баян? Лично для меня кристалл - это срань транзисоров. Которые как-то поделены между ядром, ОЗУ, FLASH для кода и проч. И оптимизировать надо не ядро, а кристалл в целом. Если я получу ядро в 3 раза больше по LE, но с компактной системой команд (сэконмлю 30% размера кода) и с решенной проблемолй дефрагментации ОЗУ (здесь и 50% ОЗУ сэкономить можно), пусть даже на 30% медленне, то кристалл будет меньше, дешевле и быстрее. Кратное снижение времени на отладку (за счет дескрипторов). Кстати, дебаг ядро и релиз-ядро могут быть разными. После завершения отладки систему дескрипторов можно упростить, что упростит ядро.
Главная | Карта сайта | О проекте | Проекты | Файлообменник | Регистрация | Вебмастер | RSS
Лето 7525 от сотворения мира. При использовании материалов сайта ссылка на caxapу обязательна.
MMI © MMXVII