33. xameleon, 17.01.2013 15:23

цитата: Хмм: цитата: xameleon: возможность обработки прерываний процессами, работающими вне контекста ядра системы Допустим, что есть дешёвое устройство с 600 МГц RISС процессором и гигабитным контроллером ethernet, который вызывает прерывание при получении/отправке каждого пакета. Вопрос: Какое максимальное количество прерываний может возникнуть в такой простенькой системе? Ответ: При минимальном размере фрейма (64 байта) и полном дуплексе - немного меньше 6 миллионов прерываний в секунду. Нет нет. 64 байта - это только (исключительно!) для регистрвого буфера сообщения и без дуплекса - фазы приёма и передачи последовательны. Гигабитный интернет захватывает шину и в режиме DMA раскидывает принятые данные по буферам в памяти. Процессор за приём не отвечает, а в сообщении ему лишь приходит сигнал, что гигабитный контроллер ethernet приянл один или несколько пакетов. По сути - сигналы о прерываниях в L4 приходят пустыми сообщенияим (приходит одно слово - тэг сообщения), а источник прерывания определяется на основе источника сообщений. (Об этом я расскажу в другой раз). цитата: Хмм:Это оставляет процессору 600/6=100 тактов на приём/передачу и обработку пакета. Представьте себе, как микроядро типа L4 попытается за эти такты ещё и успеть переключиться из режима ядра в задачу, а потом обратно. Народ на таких задачах не успевает даже все регистры в стеке сохранить, так что приходится делать специальный аппаратный контекст с отдельным банком регистров для скоростного обработчика прерываний. Понимаю проблемы народа. Посмотите на эту проблему с другой стороны и ответьте на вопрос - данные приходят быстрее, чем их успевает обработать процессор или нет? Я имею опыт написания дравйверов для двух контроллеров - DEC-21140 и Intel 8254x Делалось всё руками непосредственно по спецификациям от AMD и Intel, т.ч. некоторое представление о работе ethernet чипов я имею. Что происходит при приёме пакета? Давайте рассмотрим пример на модели OSI. Задача, являющаяся драйвером сетевой карты (канальный уровень), получает сообщение, после чего она анализирует регистры ethernet чипа. Далее, на основании этих регистров происходит разбор дескрипторов в ОЗУ (разумеется, дескрипторы сформированы ethernet контроллером в момент приёма пакетов). Далее задача-драйвер анализириует заголовки пакетов в ОЗУ (их описывают дескрипторы), находит тип пакета и направляет пакет задаче обработчику-сетевого уровня (модель OSI). После этого задача-драйвер помечает принятые дескрипторы как свободные и сигнализирует об этом контроллеру ethernet. Самая длинная операция в этой схеме - передача буфера, содержащего принятый пакет, следующему уровню модели OSI, чтобы его освобдить для приём следующего пакета. Если скорость процессора не позволяет копировать данные из буферов, принадлежащих драйверу сетевой карты, то между слоями OSI надо передавать указатель на заранее выделенный буфер, а не копировать его между задачами и уровнями протоколов. А теперь вернёмся к понятию контекста ядра. Такого понятия на самом деле в L4 не существует. Зато есть понятие адресных пространств. Обратимся к тезисам аппаратного L4: Процесс – это одна или несколько задач, разделяющие одну и ту же таблицу страниц (адресное пространство). Любые две задачи, исполняющиеся в различных адресных пространствах, по отношению друг к другу являются процессами. Поток – это задача, исполняющаяся в адресном пространстве какого-либо процесса. Любые две задачи, исполняющиеся в едином адресном пространстве, по отношению друг к другу являются потоками. Нет понятия режима ядра и пользовательского режима, а есть лишь ссылка на таблицу страниц процесса. Т.е. вся задержка, это переключение таблицы страниц. А теперь вспоминаем, что виртуальные страницы L4 являются универсальными - регион памяти описывается гораздо меньшим числом универсальных страниц в виду их природы. Поэтому операция переключения процесса может быть дешевле, чем в системах обычными вирутальными страницами. Наконец, возможность исполнять драйвера в выделенном адресном пространстве - это всего лишь возможность. Если в виду каких либо причин не хватает быстродействия, то и нет смысла такой драйвер помещать в userspace. Разве что для отладки.

66. xameleon, 17.01.2013 23:08

цитата: alpha: цитата: Почетный Метеоролог: - другой уровень потребляемой мощности процессора = иная конфигурация цепей его питания = иной характер наводок от активных элементов и дросселей в этих цепях... Это навскидку для случая "замены камня", как Вы изволили выразиться. "Маловато будет!"(с) Не тянет на серьёзный разговор, так - децкий сад, старшая группа. Работа некоторых алгоритмов зависит от частоты. В многозадачных/многопроцессорных системах при смене частоты возникают интересные эффекты. Ошибки в программе, которые не проявлялись на одной частоте, могут дать о себе знать при другой частоте. Имхо, программые ошибки выведут систему из строя быстрее наводок. И это веская причина не делать "тупо апгрейд" на системах с высокими требованиями к надёжности и безопасности.

70. xameleon, 17.01.2013 23:50

цитата: ElbrusFanV2: А вот улучшить дальность обнаружения цели можно тоже через замену вычислителя без всякого повышения мощности. :) При этом полностью проведя весь цикл испытаний системы - от начала и до конца. Оно в принципе и правильно, но если инженеры будут создавать "новую и улучшенную" версию процессора каждый месяц, то всем этим версиям просто физически невозможно будет провести полный тест.

84. xameleon, 18.01.2013 04:33

цитата: ElbrusFanV2: Давайте Вы не будете придумывать то, чего нет и также с успехом это развенчивать. Версии процессоров не придумываются каждый месяц даже на гражданке. А сделать лаг с поставкой в войска и с соответсвенным рассекречиваем почему нет? Есть версия А в войсках, версия Б уже существует, испытана и ждёт своего часа. Прошло пару лет, уже разработали систему В. Ок, рассекречиваем Б поставляем в войска со словами, опаньки, чего мы тут намодернизировали. Хотя уже есть и спроектирована система с лучшеми характеристиками, но эти характеристики держаться в секрете, дабы вероятный противник не разрабатывал средства противодействия. Что в вашем мозгу противится этому? Это интересный вопрос. Честно говоря, я не совсем уловил нить размышления. Что происходит между версиями Б) и В) мне не ведомо, но у меня немного другое представление. Вот тут надо делать по другому: цитата: Есть версия А в войсках, версия Б уже существует, испытана и ждёт своего часа. Версия Б успешно тиражируется для гражданского сектора и пользователи, сами того не подозревая, активно тестируют эту версию. Военные продолжают использовать версию А. Когда готова версия В, гражданские несут свои денежки для покупки новой железки, а версия Б, проверенная временем и тысячами пользователей, идёт в оборонку. Минус идеи - "враги" и конкуренты могут (попытаться) украсть идеи и технлогии. Плюсы - военные получают надёжное и проверенное временем решение. Компаниям удаётся минимизировать расходы - министерство обороны финансирует разработку, а потом эта разработка ещё и продётся гражданским и на них же обкатывается. Может быть такой подход и не очень защищён от утечки Intellectual Property, но конкурировать с такой схемой практически невозможно - там где тратится рубль на разработку "с обкаткой на гражданских", на той же задаче закрытая разработка потребует десять рублей. Практически любая корпорация выполняет военные заказы. Все знают, что Boeing производит не только гражданские самолёты. Но много ли кто осведомлён, что Самсунг тоже выпускает военную технику и вооружения? Если присмотреться, то можно привести десятки примеров. Подозреваю, что байки об устаревших процессорах в американском вооружении появляются не от того, что Пентагон жадничает, а потому что выбираются провренные временем решения. Кстати, я хоть и осуждаю завес секретности над ЗАО МЦСТ, но понять могу - например, описыая какой либо алгоритм, приходится искать грань, чтобы, с одной стороны, он был понятен, с другой стороны, приходится скрывать важные детали, чтобы никто не смог повторить.

145. xameleon, 24.01.2013 14:23

цитата: ПростоЗашёл: Насчёт с/с++ споры бессмысленны. Он останется стандартом на долгие годы вперёд. О чём вообще речь? Спорить можно не о языках, а о компиляторах. Любой язык, чей компилятор может генерировать объектный файл с инструкциями процессора, может использоваться для построения систем. А если система построена на принципах обмена сообщениями, то можно компоновать систему из модулей, реализованных на различных языках программирования. Кстати, систему можно построить даже на интерпретаторе - всякие Java и .NET машины с успехом демонстрируют эту возможность.

236. xameleon, 31.01.2013 02:31

цитата: ElbrusFanV2: http://www.multiclet.com/docs/PO/Examples20130129.7z Обтестируйтесь. eth.h код: typedef struct { __IO uint32_t CR; __IO uint32_t ST; __IO uint32_t MACMSB; __IO uint32_t MACLSB; __IO uint32_t RESERVED0; __IO uint32_t TDP; __IO uint32_t RDP; } ETH_TypeDef; #define APB0PERIPH_BASE (0xC0000000) #define APB1PERIPH_BASE (0xC0100000) //ETH #define ETH_BASE (APB0PERIPH_BASE + 0x00005000) #define ETH ((ETH_TypeDef *) ETH_BASE) Всё замечательно, однако, что такое - TDP и RDP? Если это "Transmit Descriptors Pointer" и "Receive Descriptors Pointer", то где же описаны структуры TDP_TypeDef и RDP_TypeDef? Если же это просто указатели на буфера, в которые помещаются Ethernet фреймы, то тут угадывается "засада" - медленная передача и высокая вероятность потерь принимаемых пакетов.

241. xameleon, 31.01.2013 13:00

цитата: Хмм: В прошлом году УАЛ пыталась привлечь средства госкорпорации «Роснано», но денег не получила. ... один из экспертов ... написал, что "для Российской Федерации создание отечественного микропроцессора неактуально"."[/i] Вот уж простите меня, но есть некоторые сомнения в экспертах РосНано, особенно в области процессоров. Дело в том, что этим "экспертам" просто неоткуда взяться - кто из них участовал в разработке микропроцессоров? Чтобы понять, что я имею в виду, возьмите обсуждение из любой темы этого форума, где обсуждается "какой процессор взять для игры в ..." - вот приблизительно таков уровень экспертов в РосНано. Я конечно могу ошибаться, но судя по косвенным фактам уровень экспертов в плане цифровой электроники весьма низок. Поправьте, если я неправ. Раз уж пошла такая тема, то беда даже не в экспертах, а в количестве компаний, разрабатывающих что-то своё собственное. В развитых странах регулярно создаются и прогорают десятки компаний и лишь немногим удаётся создать что-то конкурентоспособное. Мы не видим лузеров, зато успешные проекты у всех на слуху. Это наглядное подтверждение диалектического материализма - "закона перехода количественных изменений в качественные". То есть для качественного скачка понадобилось бы сотня компаний, типа ОАО Мультиклет. Те, кто пошёл бы по неправильному пути, прогорели бы весьма быстро, а те, кто бы вырвался в гонке, скупили бы на корню идеи и разработки менее успешных конкурентов. За это сообщение сказали спасибо: vss

252. xameleon, 01.02.2013 20:22

цитата: Felid: В принципе, ЦП и так может догадаться, что после окончания цикла надо исполнять код дальше, но современные предсказатели могут прогнозировать в т.ч. и точное число итераций :) Не подскажите, как это реализовано и кого можно почитать на эту тему?

260. xameleon, 02.02.2013 13:35

цитата: T-5000: Архитектура Мультиклета такова, что команды перехода исполняются только в конце параграфа, а сами команды могут стоять в любом месте, а в текущей реализации компилятор их ставит в самое начало. Разрешите два вопроса. Являетесь ли Вы разработчиком Мультиклета? Имеет ли смысл реализовать в Мультиклете аппаратную поддержку микроядра L4? Добавление от 02.02.2013 13:45: цитата: Leka: Нет, на анализе сборника сказок за 300000000 рублей. Ничего другого у Мультиклета нет, существующий чип не демонстрирует и малой толики обещанного. Давайте не будем столь строгими. Насколько можно понять из обсуждения, то сумма, полученная разработчиками, несколько не дотягивает до 300 миллионов рублей. Но дело даже не в этом - судя по всему, разработка компонентов микропроцессора оригинальная, а значит архитектура имеет шанс вырасти во что-то конкурентоспособное - для этого всего лишь нужны настойчивость, немного удачи, деньги и время. Конструктивная критика помогает разработчикам, огульное охаивание лишает разработчиков энтузиазма.

264. xameleon, 02.02.2013 15:34

цитата: Boris Usievich: С чего бы это? Оригинальность совершенно не гарантирует того, что архитектура способна достичь результатов. для этого нужно, чтобы заложенные идеи оказались правильными, а вот в этом есть сильные сомнения. Потому что шанс и гарантия - это разные вещи. Архитектуру можно переделать, опыт и команда есть, потому и шанс.

267. xameleon, 02.02.2013 16:20

цитата: BarsMonster: Насчет Эльбруса - до публикации статьи еще много времени и работы, но о посещении нужно отчитаться : Моноблок на Эльбрус-2С+ удалось пощупать, он живой ) Линукс работает, Firefox, все дела. Каким образом работает Linux - в режиме эмуляции x86 или собран нативно под систему команд Эльбруса? Когда будет статья на Хабре?

325. xameleon, 03.02.2013 13:29

цитата: BarsMonster: Нет, декодирование софтовое (по крайней мере сейчас), видеоядро - какая-то 3rd party видеокарта на PCI шине. Но наличие PCI-E оставляет массу возможностей на будущее :) А в конфигурации, с которой Вы знакомились, компилятор был? Что говорят команды cc -v и ld -v? Я ведь к чему клоню, если компилятор идёт вместе c системой, то с можно построить небольшой бизнес, просто собирая программное обеспечение GNU для новой платформы. Большой бизнес на сборке чужих программ вряд-ли можно построить, но небольшой стартовый капитал для какого-либо проекта вполне можно "насобирать".

330. xameleon, 03.02.2013 15:01

цитата: BarsMonster: Собирать софт под linux-ом умеют многие, не уверен что тут вообще хоть что-то можно "насобирать", даже на пиво, особенно учитывая небольшие тиражи железа :) При переносе софта на новую архитектуру иногда приходится использовать "напильник". Здесь малый тираж может сыграть и некоторое преимущество - пересечение множеств "владельцы Эльбруса" и "обладатели напильника" - может быть мало. :) Т.е. если "./configure; make; make install" не дало результата, то вот тут появляется некоторая возможность "насобирать на пиво".

354. xameleon, 04.02.2013 14:22

цитата: SuperZveruga: В мае появится полнофункциональная модель с контроллером памяти, которую уже можно будет продавать. Можно подробнее о контроллере памяти? Будет ли поддерживать страничную память и каков размер страниц? Добавление от 04.02.2013 14:24: цитата: Wizardry VII: Вот тут продаются процессоры Мультиклет: http://www.zolshar.ru/brand/5656 Не подскажите, чем отличается процессор за 39500 рублей от процессора за 665 рублей?

363. xameleon, 04.02.2013 18:24

цитата: Felid: Также всякие интеллектуальные камеры и системы слежения для полиции, больших серьёзных зданий и прочих органов. Большой и перпективный рынок. Прибавьте сюда станки с числовым программным управлением, роботизированные линии и всё такое.

366. xameleon, 04.02.2013 19:13

цитата: Felid: xameleon — я не в курсе, что сейчас со станкостроением в РФ. Что-то хорошее и покупаемое есть? К сожалению - я также не осведомлён.

504. xameleon, 08.02.2013 12:57

Leka, наверное я немного не по теме. Покажите пожалуйста объявление на Verilog большого регистрового файла. Вот чего-то на меня накатило - может буду пилить свой процессор, если не отпустит :).

506. xameleon, 08.02.2013 13:57

ElbrusFanV2 Спасибо. Вчера пересмотрел на opencores.org почти все 16-ти и 32-х разрядные процессоры. Более-менее готовых и интересных нашёл штук 5. Не могу остановиться на какой-либо реализации - с одной стороны чувства требуют описать свою систему команд, а разум говорит - даже не думай это делать без компилятора. Причём, чем больше узнаю, тем больше вопросов появляется.

567. xameleon, 11.02.2013 17:35

цитата: Boris Usievich: вот только изобретая что-то новое стоит понимать, что до того работали не идиоты и у имеющихся решений есть веские основания делать так, а не иначе. Зачастую многие хорошие идеи губит требование обратной совместимости с уже существующими решениями.

906. xameleon, 06.03.2013 00:16

цитата: futurama: Нужен регистровый файл с количеством банков равным количеству клеток. Дальше развивать идею не буду, а то уворуют. Уворуют? Смешно. Кто? Развивайте идею - интересно же.

1065. xameleon, 14.03.2013 15:41

Что-то тема заглохла. Одна из немногих тем, которую действительно интересно почитать и приятно поучаствовать. А что будет, если я скажу, что тоже задумал спроектировать микропроцессор? Только... к этой задаче я подошёл с написания компилятора языка Си (Си с классами, но без темплейтов), над котором бьюсь уже почти два месяца. Некоторые подробности о компиляторе можно почитать здесь - http://mandrykin.livejournal.com/16765.html Что касается системы команд микропроцессора, то больше всего это похоже на CISC, но размер команды упакован в нескольких первых битах и уже из первого байта о размере команды известно всё. Ах да, моя цель и мотивы несколько отличаются от целей и мотивов других разработчиков - имееется прототип операционной системы и имеются намерения ввести аппаратную поддержку микроядра в микропроцессор. Кстати, синтаксический анализатор готов где-то на 80% от языка Си. Т.ч. если затея с оригинальным микропроцессором не выгорит, то по крайней мере появится ещё один неоптимизирующий компилятор для 80386, с возможностью быстро и с минимальными трудозатратами "прикрутить" поддержку любого микпроцессора.

1067. xameleon, 14.03.2013 16:18

Felid Я пока не выкладывал в общий доступ. Проектировал в MS Excel - вывел в двоичной системе 256 байт, затем с помощью цветов групировал и перегруппировывал. Где-то за пять итераций удалось сгруппировать. В соседний теме, ssvb подсказал: "Попробуйте в качестве источника вдохновения посмотреть на ARM Thumb2. Там можно очень быстро и легко отличить двухбайтные инструкции от четырёхбайтных." В принципе, от этой идеи и отталкивался. Формально описать можно так: Если три старшие бита равны нулю, то это однобайтовая команда. Получилось 32 однобйтовых команды. Иначе, если старший бит равен нулю, то это двухбайтовая команда - 96 двухбайтовых команд. Если старшие три бита равны 1-0-0, то это трехбайтовая команда - 32 трехбайтовых команды Если старшик три бита равны 1-0-1, то это четырехбайтовая команда - 32 четрыхбайтовые команды Если старшие четыре биты равны 1-1-1-1, то это пятибайтовая команда - 16 команд. Кроме этого остался резер - немногим более 50 байт, которые не являются командами и могут быть использованы для дальнейшего расширения системы команд. Документ не выкладываю в публичный доступ не потому что жалко, а потому что он ещё довольно сырой и может дать неправильное представление об идее. Когда всё устаканится - обязательно опубликую.

1071. xameleon, 14.03.2013 16:58

цитата: AlexDi: Рекомендую отталкиваться не от 8битной гранулярности, а от 16 битной Команды длиной 16/32/64 бита. Так будет проще. Вероятно Вы правы, я пока не буду ни настаивать на своём решении, ни соглашаться. цитата: BarsMonster: Любой провальный проект начинается с велосипеда. Да я как бы не мальчик уже - в январе 40 лет исполнилось. Ну вот хочется мне сделать карманный компилятор - никто же не запретит. А микроядерную ОС я уже лет 11 пишу в свободное время. Почему бы не попробовать силы в написании компилятора? Что касается LLVM, то его не рассматривал из за его громоздкости. Те же два месяца, которые портратил на лексический и синтаксический анализ, ушли бы только на изучение LLVM - из области "день потерять - за час долететь". Приблизительно то же самое можно сказать и о gcc, только ещё лицензия не самая благоприятствующая для коммерции. Что там в остатке? Оптимизация? Оптимизация на уровне синтаксиса - не такая уж и неподъёмная задача - например, сворачивание констант в выражениях проще пареной репы. Вывод инвариантов за пределы цикла - сложнее, но тоже можно осилить. А вот машинно-зависимая оптимизация - не уверен, что все предолженные решения могут сильно помочь при оптимизации кода под конкретную систему команд. Хотя могу и ошибаться. В любом случае - создание компилятора проще по сравнению с созданием микропроцессора, т.ч. если не осилю его, то нет смысла браться за микропроцессор. цитата: Ну а проектирование микропроцессора начинается с решения финансового вопроса сего мероприятия, если это конечно не академические эксперименты. Т.е. главный вопрос - это не компилятор и система команд, а кто будет оплачивать банкет. Думаю, verilog описание я смогу сделать на энтузиазме, вот насчёт реализации "камня" - идей нет. Как вариант - прийти с поклоном в http://zeptobars.ru и предложить свои наработки и услуги. А что? Тоже вариант.

1073. xameleon, 14.03.2013 17:10

цитата: vss: С каким интерфейсом? POSIX. Пользовательский интерфейс - командная строка и ANSI графика.

1075. xameleon, 14.03.2013 18:42

цитата: BarsMonster: Clang и GCC собирают Linux и uCLinux "из коробки", а самоделки - в обозримом будущем никогда их не соберут, потому что нужны годы работы, чтобы домашний компилятор допилить до требуемой степени совместимости. Я это знаю и не спорю. Только учтите один момент - для меня важно собрать этим компилятором три вещи: 1) самого себя; 2) код Хамелеона; 3) микроядро L4Ka Pistachio. Собирать Linux и uClinux - такой задачи не стоИт. Поддерживать расширения gnu - тоже задачи нет. По большому счёту, если Pistachio не соберётся, то даже это не проблема, потому что для традиционных платформ gcc никто не отменял, а "L4 микропроцессор" должен аппаратно поддерживать L4-X2 ABI. Вот чего я никак не могу обещать - машинно-зависимой оптимизации. Сейчас мне эта задача представляется совершенно непосильной. Кстати, насчёт "собрать сам себя". Прежде чем приступить к генерации кода, я решил из дерева синтаксического разбора строить обратно исходный код - таким образом можно существенно облегчить отладку, сравнивая/компилируя восстановленный си-код. Генерации ассемблерного кода не появится раньше, чем восстановленный си-код лексического и синтаксического анализаторов соберётся с помощью gcc и msvc.

1078. xameleon, 15.03.2013 01:16

BarsMonster Мне особо нечего возразить - разум соглашается с Вашими доводами, а чувства значения не имеют. Если не возражаете, вернёмся к этой дискуссии, когда мне будет что показать. Тем более, что не исключаю возможность, что не осилю эти задачи.

1087. xameleon, 15.03.2013 14:26

цитата: vss: А какой интерфейс микроядра? Спецификация L2-X2 - http://l4ka.org/l4ka/l4-x2-r7.pdf По моему скромному мнению, это лучшее, что было придумано в области микроядер - L2-X2 предоставляет минимальные абстракции нитей исполнения, адресных пространств и сообщений. Причём, сообщения это база, на которой строится система любой сложности - системные вызовы, прерывания, исключения, таймеры и синхронизация - всё это реализуется на основе синхронных сообщений. Добавление от 15.03.2013 15:18: цитата: Хмм: К этому пункту можно подойти с другой стороны. Сделать систему команд "L4 микропроцессора" настолько логичной, чтобы не возникло потребности в сурово-извращённой машинно-зависимой оптимизации. Не могу адекватно судить, как не может мать судить своего ребёнка. :) По возможности старался делать красиво. Большое влияние на систему команд оказала PDP-11, например, команды MOV, XOR, AND, OR, CMP, ADDC, SUBC, XCHG имеют одну из форм, в которой можно указывать постфиксный/префиксный автоинкремент/автодекремент, с возможностью указания смещения. Выглядеть это будет приблизительно так: код: movb (R11++).field_name, R3 subw R5, (R8).disp xchg (--R4).disp, R0 add (++R7), R9 subw (R8--).another_field, R7 Команды в этой форме займут 4 байта. В то время как обычные формы этих же команд займут 2 байта: код: mov dst_reg, src_reg xor (dst_reg), src_reg and dst_reg, (src_reg) Скрепя сердце пришлось отказаться от CALL/RET - вместо них используется фрейм вызова, как это принято у RISC процессоров. Поэтому возврат из функции вырождается в нечто вроде код: jmp (R15) // Однобайтовая команда Ещё момент - нет команды перехода по адресу, а только по смещению. Т.е. весь код изначально позиционно независим. Смещение может быть знаковым 8, 16, 24 битным числом. Таким образом, максимально можно перескочить на 8 388 607 байт вперёд или назад. Этого вполне достаточно для 32-х битной системы. Что касается DLL, для которых (якобы) может понадобиться переход по адресу, то необходимость в таком переходе отпадает из за механизма сообщений - если нужно вызвать внешнюю библиотечную функцию - посылаем ей сообщение и ждём ответа. Любой обмен между процессами, нитями, динамическими библиотеками осуществляется только на основе Inter Process Communicationы. Если уж возникла острая необходимость перехода по адресу (ну мало ли у кого какой бзик), то адрес заносится в любой регистр, а потом переход по значению этого регистра. При разработке системы команд большое внимание было уделено группировке команд и модификаторов, чтобы упростить HDL реализацию. Добавление от 15.03.2013 15:36: Упс... А ведь смещение и инкремент/декремент в одной команде смысла не имеют. Как же хорошо иногда бывает отвечать на форумах - сразу "выползают" логические несоответствия. Придётся думать ещё. Добавление от 15.03.2013 15:51: цитата: PredatorAIpha: Возможно Вам стоит списаться с этим человеком: http://vinxru.livejournal.com/112555.html Спасибо. Эх, если бы чуть раньше бы узнать о его существовании. Когда я искал компилятор, сделанный людьми, говорящими по-русски, то нашёл лишь вот это: http://home.perm.ru/strannik/ и вот это http://www.interstron.ru/developers_means2.html Оказывается, есть ещё.

1094. xameleon, 16.03.2013 00:10

цитата: Felid: xameleon пришлось отказаться от CALL/RET - вместо них используется фрейм вызова — а как и где вы запоминаете и используете адрес возврата? Адрес возврата кладётся вместе с аргументами функции в фрейм вызова. Т.е. была идея не использовать определённый регистр для указателя стека, а сделать указатель стека по соглашению. Однако, очень меткий вопрос, спасибо. Попытался привести пример, но обнаружил логическую ошибку в дизайне системы команд - без инструкции CALL появляется необходимость в дополнительных командах, которые кладут адрес возврата во фрейм вызова. Но это пол беды, многие же как-то живут без CALL. Проблема вылезла в другом - я не предусмотрел доступ к счётчику команд, поэтому адрес возврата для фрейма вызова может знать только компилятор, а это уже удар по позиционной независимости кода. В итоге получилось кривое решение, требующее трех операторов вместо единственного CALL. Т.е. заставить работать можно, но было бы неоптимально и криво. В принципе, есть окно неиспользуемых кодов с 0xC0 по 0xEF, можно часть из них использовать для CALL. Пользуясь случаем, хочу спросить мнение уважаемых специалистов - какими мотивами пользуются разработчики микропроцессоров, отказываясь от CALL? Я поддался моде и наступил на грабли. А в чём преимущества фрейма вызова? Какие аргументы за? На самом деле вопросов гораздо больше, например, дилемма относительно указателя стека - использовать ли один из регистров общего назначения в качестве указателя стека или задействовать теневой регистр в этом качестве. С одной стороны, если задействовать один из РОН под указатель стека, то некоторые сочетания потеряют смысл - например, умножение на указатель стека бессмысленно - это уже нарушает стройность системы команд. С другой стороны, доступ к теневому регистру требует новых инструкций и ломает правило "степень двойки". Мне кажется, что в любом случае можно решить проблему с указателем стека. Если поместить его в область РОН, то недоступимые команды можно использовать для каких-то будущих целей - например расширения системы команд. Если задействовать теневой регистр для указателя стека, то хранить его можно в Task Control Block - расширении регистрового пространства, отвечающего за многозадачность и передачу сообщений. Искренне надеюсь, что никого не утомил этим длиинным сообщениеи. Добавление от 16.03.2013 01:55: цитата: vss: цитата: xameleon: если нужно вызвать внешнюю библиотечную функцию - посылаем ей сообщение и ждём ответа. Любой обмен между процессами, нитями, динамическими библиотеками осуществляется только на основе Inter Process Communicationы. Это гораздо медленнее, чем в защищенном режиме Эльбруса e2k. Момент в том, что передача сообщений должна осуществляться коммутацией блока регистра сообщений. Отсюда следует два варианта. Первый вариант: Запрашивающая задача и DLL исполняются на одном ядре. Задача, реализующая функциональность динамической библиотеки, находится в "кеше состояния задачи". В этом случае вместо регистров сообщений, исполнительное устройство перекоммутируется на РОНы и Task Control Block (TCB) задачи, выполняющей функции DLL. Второй вариант: Запрашивающая задача и DLL исполняются на разных ядрах. Регистры сообщений перекоммутируются от запрашивающей задачи к задаче, выполняющей функции DLL. "Бутылочное горлышко" данного решения - это случай, когда задача DLL не находится в "кеше состояния задачи". В этом случае может получиться действительно медленно - придётся выгрузить состояние (РОНы и TCB) какой либо задачи из кеша в ОЗУ, а затем подгрузить состояние задачи, выполняющей функции DLL. Нивелировать данную проблему можно увеличением размера кэша состояния задачи, чтобы часто используемые функции как можно дольше держались в нём. Кроме того, не имеет смысла помещать в DLL простые и короткие функции. Имхо, в динамических библиотеках место только полноценным функциям, выполняющим какую либо сложную логическую задачу. цитата: Проекты на микроядре были, например, на фирме Sun в 90-е, и тогдашняя оценка минимального количества sparc-команд для межпроцессного вызова была около 100. О, Sun! Эти ребята умудрились в Solaris (или это был Sun OS?) на каждый userspace thread создавать kernelspace thread. Хуже придумать нельзя - ведь в таком случае микроядро становится лишним слоем. Я могу это доказать - при таком подходе сообщения вырождаются в системные вызовы (а значить пропадает их суть), но при этом никуда не пропадает необходимость синхронизации kernel threads. Фишка правильного использования синхронных сообщений как раз в том, чтобы обрабатывать сообщения на уровне ядра в одном потоке - необходимость синхронизации отпадает и требования к ресурсам значительно снижаются. Давайте рассмотрим как бы мог выглядеть вызов printf("Hello world!\n"); на примере "L4 процессора". 1. Инструкция блокировки буфера сообщений 2. Инструкиция установки тега сообщения 3. Установка указателя на строку сообщения в регистре 1 буфера сообщений. 4. Команда Inter Process Communications В этот момент происходит передача управления "ядру" системы, которое обрабатывает команду. После обработки команды происходит ответное сообщение. Допустим, нас интерсует, сколько байт вывела команда printf. Продолжаем. 5. Анализ тега сообщения. 6. Переход, если ошибка 7. Выбор регистра 1, хранящего результат выполнения функции printf 8. Разблокировка буфера сообщения. Какой overhead мы получили по сравнению с традиционными методами? Инструкции блокировки/разблокировки буфера сообщений и инструкции работы с тегом сообщения. Т.е. пункты 1,2,5,6,8 - это есть overhead. С первого взгляда это кажется ужасно неэффективным, но чем больше передваемых параметров (максимально - 63 регистра), тем overhead падает. Где же обещанный выигрыш? А выигрыш в том, что при таком подходе отпадает необходимость в синхронизации потоков. "Лишние" пять команд при обмене сообщениями с лихвой компенсируются отсутствием семафоров, защёлок и критических секций на уровне ядра. Если 10 задач одновременно в 10 потоков каждая, будут вместе выводить, например, "Hello world", то "ядру" системы не придётся защищать ресурсы от одновременного доступа. Наконец самое вкусное. Если все вызовы обрабатываются синхронно и последовательно, то откуда взялись заявлени о realtime и почему всё не должно тормозить и блокироваться? Здесь долгая история, начавшаяся с того, что ожидание ввода с клавиатуры блокировало всю систему - все последующие вызовы в конкурирующих потоках/задачах ждали завершения обработки блокирующего вызова. Обратите внимание, что понятие "ядро" я брал в кавычки. Фактически, ядро это множество программ, блокированных в ожидании события. Представьте путь, который проходит системный вызов: Прикладная программа --> файловая система --> драйвер --> файловая система --> прикладная программа. Точка блокировки находится в ожидании файловой системой ответа от драйвера. Решение заключается в том, чтобы в точке ожидния ответа продолжать слушать последующие запросы от других прикладных программ. По формату сообщения всегда можно определить, что это - запрос от пользовательской программы или ответ от драйвера, соотвественно, вводим понятие контекста и переключаем контекст на основе полученного сообщения. В результате получаем неблокирующуюся систему с гарантированным временем отклика. Кто теперь вспомнит о пяти лишних командах, задействованных при передаче сообщения?

1099. xameleon, 17.03.2013 14:52

цитата: vss: Если вы хотите оставаться в рамках стандарта POSIX, вам придется синхронизировать printf с доступом к тому же файлу по интерфейсу write - read через дескриптор открытого файла. Там полный букет всего, что есть ядре ОС. Да да да. В Хамемелоне printf заработал по стандарту POSIX где-то в 2006-2007 году. Просто в пылу спора я привел неудачный пример. В моём случае printf выделяет буфер на стеке, вызывает vsnprintf, а сконструированную в буфере строку выводит с помощью write в дескриптор, который соотвествует stdout (кажется единица, надо в сырцы глянуть). Каюсь, в горячке спора привёл неудачный пример. В потдтверждение своих слов код из libc Хамелеона. Старый добрый printf код: int printf( const char * format, ... ) { va_list marker; char buffer[180]; int Status; va_start(marker, format); Status = vsnprintf(buffer, sizeof(buffer), format, marker); va_end(marker); return (Status <= 0) ? Status : FILE_(stdout)->fputs( buffer ); } А это puts. Он простой как три копейки. код: int _FILE::fputs( const char * s ) { int nResult = 0; if( s ) for( nResult = 0; *s; nResult++ ) if( EOF == fputc( *s++ ) ) return EOF; return nResult; } Логика работы fputc зависит от того, пишем в символьное устройств или в файл. Размумеется, буферизируем всё как умеем. код: int _FILE::fputc( int c ) { if( this == 0 ) { L4_KDB_Enter("_FILE not constructed"); return -1; } if( ! S_ISREG( m_nFileMode ) ) { // isatty == true m_pWriteBuffer[m_nWriteWindowSize++] = (char) c; if( c == '\n' || m_nWriteWindowSize >= STREAM_BUFFSIZE ) { write( m_nFileHandle, m_pWriteBuffer, m_nWriteWindowSize ); m_nWriteWindowSize = 0; } } else { if( ! CHECK_BOUND( m_nWriteWindowStart, m_ulWritePosition, m_nWriteWindowSize ) ) { if( m_nWriteWindowSize < STREAM_BUFFSIZE && m_nWriteWindowStart + m_nWriteWindowSize == m_ulWritePosition ) { m_nWriteWindowSize++; } else { FlushCashe(); m_nWriteWindowStart = m_ulWritePosition; m_nErrorNumber = lseek( m_nFileHandle, m_nWriteWindowStart, SEEK_SET ); m_nWriteWindowSize = 1; } } m_pWriteBuffer[ m_ulWritePosition - m_nWriteWindowStart ] = (char) c; m_ulWritePosition++; } return c; } Обращение к ядру происходит только в функиции write. код: ssize_t write( int nFileDescriptor, const void * pBuffer, size_t nBytesWrite ) { int nStatus; int nChunk; int nTotalSent; char * pPointer; L4_MsgTag_t tag; L4_Msg_t msg; L4_StringItem_t SendString; nStatus = nTotalSent = 0; pPointer = (char*) pBuffer; while ( nBytesWrite ) { nChunk = (nBytesWrite > 4096) ? 4096 : nBytesWrite; SendString = L4_StringItem ( nChunk, (void*) pPointer ); L4_Clear( &msg ); L4_Set_Label( &msg, fsWriteFile ); L4_Append( &msg, nFileDescriptor ); L4_Append( &msg, &SendString ); L4_Load( &msg ); tag = L4_Call( fs_service_id ); if ( L4_IpcFailed(tag) ) { nStatus = nTotalSent ? nTotalSent : XAM_EINTR; break; } else { L4_Store( tag, &msg ); nStatus = L4_Get( &msg, 0 ); nTotalSent += nStatus; } pPointer += nChunk; nBytesWrite -= nChunk; } // POSIX workaround if( nStatus < 0 ) { errno = nStatus; nStatus = -1; } else nStatus = nTotalSent; return nStatus; } Собственно функция L4_Call и есть та функция, которую я предлагаю заменить инструкцией "Inter Process Communication". А структура L4_Msg_t - это буфер сообщений, который предлагаю разместить в процессоре и коммутировать при передаче сообщений. Функция L4_Load заменяется инструкцией захвата буфера сообщений, функция L4_Store - заменяется инструкцией освобождения буфера собщений. L4_Set_Label - установка регистра 0 буфера сообщений. L4_Append - установка любого регистра буера сообщений. L4_Get - чтение регистра буфера сообщений. Конечно, я не могу и не имею права сказать, что Хамелеон полностью поддерживает POSIX, но к примеру, Demos Commander (собранный для POSIX) and Almquist shell он исполняет. Можно, конечно, побить меня за качество кода, но пусть бросит в себя камень тот, кто скажет что первые 5 лет жизни Линукса его код был красивым и стройным. Добавление от 17.03.2013 15:11: цитата: Felid: без инструкции CALL появляется необходимость в дополнительных командах, которые кладут адрес возврата во фрейм вызова — хуже того, надо явно туда писать не текущий IP, а который на несколько байт далее, что больше по размеру кода и требует адресную арифметику. И зачем оно такое надо — мопы экономить?… Вы меня окончальельно убедили. Инструкции CALL - быть. Тем более, что с учётом различной разрядности сещения 8/16/24 бита, надо ещё знать, на какое значение увеличить Instruction Pointer. цитата: в моих соображениях для нового сиск-ЦП я сделал 4 отдельных от РОНов указателя: IP, SP, BP и RP — это указатель на вершину стека адресов возврата, который не только отделён от стека данных, но и (вместе с RP) доступен только для чтения. Писать туда можно только CALL-ом. Очень интересная идея c RP. Насолько я понимаю, таким образом Вы разделяете код и данные? Так сказать - дополнительный уровень защиты? А можно ли чуть подробнее об этом? Используется ли в каких либо процессорах отдельный стек для адресов возврата? Если не затруднит, хотелось бы больше информации о преимуществах и недостатках разделения стека по данным и вызовам. цитата: доступ к теневому регистру требует новых инструкций и ломает правило "степень двойки" — это что за правило? Для упрощения адресации, чтобы исключить сложную арифметику, заменив её сдвигимами. И чтобы не было "дырок" в битовых полях, указывающих индекс регистра. Что касается "теневого" регистра, то виноват. С терминологией у меня часто бывают казусы, но я работаю над собой, чтобы не словоблудить.

1120. xameleon, 29.03.2013 05:27

Новости с выставки будут, или информация только для избранных, кто может себе позволить посещение выставки?

1151. xameleon, 01.04.2013 20:25

Упс. Простите, я как-то не учёл, что сегодня день хохм и шуток. Со всей серьёзностью заявляю - это сообщение не шутка и вообще "насрать на первое апреля". Пусть дети и дураки веселятся, а адекватные и целеутремлённые люди продолжают заниматься серьёзными вещами. А слышали ли вы об оригинальном микропроцессоре на основе платы Марсоход-2 (FPGA based)? Один весьма скромный человек, который называет себя Николай, разработал RISC микропроцессор и даже научил компилятор LCC генерировать код для него. Вот что говорит автор: цитата: Доделываю проект системы на кристалле для платы Марсоход2. Пока в него входят: собственный 16-ти разрядный RISC микропроцессор, внутрикристальные озу данных и пзу команд, контроллер VGA(640x480x60), контроллер SDRAM, системная шина. Планирую добавить: кэш команд, устройство чтения АЦП. Проект написан на VHDL. Есть ассемблер к процессору. Удивительно, но автор совершенно не пропагандирует своё творчество. Насколько мне известно, единственное место, где он рассказывает о своей разработке, это форум марсохода: http://marsohod.org/forum/index.php?option=com_kunen…1419&Itemid=2 Если пойдёте по ссылке, то обнаужите описание, исходный код на VHDL, ссылки на демонстрационное видео (весьма убедительное, имхо) и патчи к компилятору LCC. Каюсь, я засветился в той теме, агитируя автора реализовать расширение процессора для микроядра L4. Мои коментарии можете смело пропускать. Одного не пойму, почему автор настолько скромен? Может быть это хитрый план? Насолько я могу судить, он проделал огромную работу и во многом даже обогнал конкурентов. Что вы думаете о его разработке?

1157. xameleon, 02.04.2013 16:17

цитата: Leka: Не единственное, ранее на electronix были ветки - на марсоходе есть ссылка. Возможно я упустил. И всё же меня приятно удивляет это человек - сумел в одиночку сделать процессор, ассемблер, доработать компилятор и написать несколько демок, это очень круто. А ещё меня удивляет "холодность" специалистов - создаётся впечатление, что всем пофигу. Хотя бы кто-нибудь высказал своё мнение - хоть критику, хоть дифирамбы. Отсюда можно сделать вывод, что разработка хороша, потому что народ, который в своё время тоже хотел сделать нечто подобное, но не осилил, старается не замечать того, кто смог. Тем более что электроники весьма специфичные люди, с очень высокой самооценкой, которая не позволяет признать чужие заслуги.

1163. xameleon, 02.04.2013 20:42

цитата: Leka: На electronix есть несколько веток по "своим процессорам", там все, кому интересна эта тема, давно уже высказались. Ага. Видел Вашу переписку в обсуждении "Свои процессоры". Ну так с тех пор "много воды" утекло - тогда компилятора не было и исходники, которые он выкладывал, устарели. На форуме Марсоход более свежие версии. Добавление от 02.04.2013 20:44: цитата: alpha: Угу, круто, только у него это не процессор вроде, а контроллер-однокристалка ... Так это даже больше чем процессор.

1168. xameleon, 03.04.2013 01:21

alpha, ну так больше, за счёт дополнительного обвеса. Т.е. формально - просто процессор с некоторыми контроллерами. цитата: И кому он нафиг нужен такой? Наверное сам по себе этот процессор мало кому нужен. Хотя, если постараться, то применение найти можно. Интересен потенциал разработчика. Я хоть и не большой специалист в HDL, но с точки зрения программиста оценить могу. На мой скромный взгляд, процессор где-то на уровне ARM2-ARM3 (могу ошибаться). Ниже я написал о-о-о-о-очень дли-и-и-и-и-нный ответ, а потом... стёр его. Всё равно никто не оценит. Добавление от 03.04.2013 02:14: цитата: ElbrusFanV2: На самом деле я очень давно читал про марсоход, но действительно разработать свой процессор и адаптировать какой-либо компилятор для него это довольно простая задача. Вопрос только в трудозатратах. Я заранее прошу прощения за отклонение от темы и за мнение, идущее вразрез с мнением большинства участников, но есть один момент - целеустремлённость автора. Тот же Эльбрус (который не SPARC, а который оригинальный) не имеет "отца", а если и имеет, то его детище ему не принадлежит. В то время как разработчик, который владеет своим детищем, имеет колоссальную мотивацию. И эта мотивация способна сдвинуть горы. "Выстрелит" ли Эльбрус? Не знаю, но если бы Борис Бабаян имел контрольный пакет акций, то судьба у Эльброс была бы другая. А ещё лучше, если бы Всеволод Бурцев был отцом и владельцем компании (да, я понимаю, что при социализме частная собственность на средства производства невозможна, просто мысли). Что касается трудозатрат, то мало кто может представить, сколько энергии может потратить "фанатичный разработчик" - отдых, семья, развлечения - всё это может уйти на второй план когда автор одержим идеей. Нет другого стимула заставить человека выложиться на 100%, кроме как одержимость своей собственной разработкой. А если добавить к этому финансирование и наёмный труд, то автор вполне сможет мотивировать работников. Практически любая современная успешная корпорация выросла из таких вот одержимых авторов. цитата: http://kit-e.ru/articles/cpu/2002_06_80.php Вот Вам цикл статей про это. Интересно и познавательно, жаль что VHDL - мне Verilog нравится больше.

1182. xameleon, 03.04.2013 23:31

цитата: ПростоЗашёл: Неверно, потому что в данном случае есть уникальный коллектив без которого вопрос принадлежности абсолютно неважен. Это похоже на футбольную команду где играют суперзвёзды и которые имеют своё слово и влияют на принятие решений. Суперзвёзды, это скорее Intel, AMD, ARM и MIPS. Более корректное сравнение ЗАО МЦСТ - футбольный клуб при (крупном) заводе. Неееет. В этой игрё всё не так. Бабаян грозился сделать "убивцу Интела". Сделал? Нет. Наоборот, часть разработчиков перешло под крыло Интела. Что может потерять руководитель ЗАО МЦСТ? Самое страшное - понизят в должности и урежут госфинансиование, плюс свернут какие либо разработки. А что бы было, если бы МЦСТ таки заборола Интел? Премия разработчикам, медалька на шею генеральному конструктору и хвалебные передачи по Первому каналу. Профит в случае удачи невелик, как и невелики потери в случае поражения. А если бы это была действительно частная компания? В таком случае совсем другая игра - проигравший может лишиться всего - дома, семьи, друзей и закончить свою жизнь в картонной коробке на улице. Но в случае успеха всё становится наоборт - яхты, спортивные автомобили, самолёты и дворцы - всё к ногам победителя. Разумеется, я утрирую. Но общий смысл понятен - играешь по-мелкому - мало теряешь и мало приобретаешь. Играешь по-крупному - всё или ничего. Так какой смысл напрягаться и напрягать других, если разница между успехом и поражением условно говоря ничтожна? цитата: Скажем, она поможет получить 100-120млн$ на производство 20нм чипа? То есть Вы типа приходите и говорите: "Мне нужно 100 зелёных лимонов, потому что у меня есть Мотивация!" 1. Демонстрируют прототип, а не мотивацию. 2. Удачный прототип может заинтересовать инвесторов. 3. $100 000 000 - ни один инвестор не даст. Такую сумму можно попытаться собрать только выпустив акции. И то не факт, что в России это возможно. После МММ, "Хопёр Инвест" и прочей шелупони - ни один здравомыслящий человек не понесёт свои кровно заработанные деньги в команию, которая может оказаться очередным лохотроном. Для производства 20нм действительно нужно 100млн или сумма с потолка? Кстати, я сейчас использую довольно старый AMD Athlon 64 3000+. Если Интернет не врёт, это техпроцесс 90нм. Этого камня мне вполне хватает для РАБОТЫ, тем более что я его не покупал, а работодатель любезно предоставил мне компьютер. Поймите меня правильно - я ничего не имею против команды, разрабатывающей различные семейства Эльбрусов и ничуть не сомневаюсь в их компетентности, но если бы эта команда работала на "капиталиста", то я уверен, она бы смогла показать лучший результат. Добавление от 04.04.2013 00:02: цитата: alpha: ElbrusFanV2: Мне моих познаний хватает, чтобы не фанатеть от лесопилки, на продукцию которой не устанавливается Вынь с Офисом. Если вспомнить Open Office, то он устанавливается почти везде, где можно запустить X Window System. А это практически любая POSIX совместимая система. цитата: alpha: применение найти можно. Хорошо, если так. А вообще, область применения определяется на этапе постановки задачи, т.е. ещё до проектирования. Я согласен с Вами, но только отчасти. Не согласен с подходом. Если взять любой современный микропроцесоор, то все возможности он приобрёл в результате эволюции. Отрицая отечественных "кулибиных", Вы автоматически ставите крест на эволюции. Невозможно на пустом месте сделать совершенный процессор, способный конкурировать с лидерами индустрии. Взять, к примеру, "Мультиклет" - несмотря на заявления разработчиков, мы все понимаем, что в нынешнем виде его нельзя ставить в один ряд даже с младшими моделями лидеров. Но "Мультиклет" имеет шанс вырасти во что-то серьёзное, если продолжит развиваться и пройдёт такой же путь, который прошли 8086, ARM и MIPS.

1185. xameleon, 04.04.2013 12:02

цитата: ПростоЗашёл: Вы сравниваете компании и коллективы и мешаете всё в кучу. МЦСТ - это уникальный коллектив, который сохранил преемственность со времён Лебедева, Брука и многих других. Да я всё понимаю - перестройка, развал Союза, перманентный кризис. Мой посыл в другом - если бы лидер этого коллектива, который стоял у истоков компании, владел бы (именно владел, а не был назначен по указке сверху) контрольным пакетом акций предприятия, то история бы развивалась иначе. Всё-таки частная собственность делает чудеса. Не верите? Загляните в историю любой известной западной компании - практически все они выросли из нескольских инженеров-энтузиастов или учёных. Но Вы не найдёте ни одной успешной компании, которая была создана решением правительства или богатым дилетантом. цитата: Мультиклет пытается что-то сделать, но пока у них нет чего-то захватывающего дух. С этим совершенно согласен, но тут ничего удивительного нет. Не может маленькая компания конкурировать с крупной корпорацией. Единственный путь для "Мультиклета" - развиваться быстрее лидеров. Тот путь, который прошёл Интел за 30 лет, пройти за 10. цитата: Нынешний Эльбрус был разработан архитектурно именно этими людьми. Разработчиков сплавило государство, здесь всё это писалось сто раз. Не хочу спорить об эффективности государства. Вероятно, государтсво может быть эффективным, но частный бизнес БОЛЕЕ эффективен. "Жажда наживы" более сильный стимул, чем похвала. цитата: Это означает уничтожение "футбольной команды", переход её в низшую лигу, потому что заменить игроков некому. В классическом "капиалистическом обществе равных возможностей" игроки могут организовать свой клуб. Имхо, мы слишком углубились в аллегории. Считаю, что сравнение наукоёмкого бизнеса некорректно с бизнесом на нефти и мелкооптовой торговлей. Я всё же прошу обратить внимания на истории создания корпораций, производящих высокотехнологичную продукцию. Причём, что характерно, частная инициатива движет не только микроэлектроникой, но и автомобилестроением и другими отраслями. Прошу понять меня правильно - я не утверждаю, что любой инженер может создать успешную компанию. И дело даже не в том, что хороший инженер может быть плохим бизнесменом. Для успешного бизнеса нужна конкуренция. Но конкуренция не с корпоративными монстрами, а с такими же маленькими компаниями. Например, можно было бы говорить о перспективах отечественной электроники, если бы таких компаний как "Мультиклет" было бы пару сотен. Рынок вскоре отсеет слабых, а те, кто смог удержаться на плаву, конкурировали бы между собой. Более сильные компании поглотили бы слабых. Затем идёт насыщение внутреннего рынка и выход на международный. Вы легко найдёте подтверждение моих слов, изучая истории создания успешных западных и дальневосточных компаний (Япония и Корея). В озвученной выше концепции есть один недостаток - как многие заметили, рынок микроэлектроники уже насыщен дешевой и качественной продукцией зарубежных компаний. И этот факт ставит крест на надежду становления микроэлектронной промышленности России. В таких условиях развиваться невозможно. Возможно, решение проблемы есть, только мне оно неизвестено. Может быть создание искусственого спроса на такие изделия? Но как?

1187. xameleon, 04.04.2013 12:27

цитата: Хмм: Что надо такое изобрести, чтобы Вам захотелось срочно сменить текущий процессор на Мультиклет? Наверно это ответ на вопрос чего не хватает Мультиклету, и ответ этот получится печальным. Ну дык, Вы же знаете - думаю, аппаратное микроядро L4, внятная система команд, хороший С/С++ кросс-компилятор и хотя бы 500 Мгц. (не, лучше гигагерц) вызвали бы желание сменить процессор. Только... я ведь всё же программист - новый процессор, это новый хлеб для программистов. ой, немного не так. Я бы не менял текущий процессор, потому что "сижу на игле" MS Visual Studio. Это самая главная причина. Если кто-нибудь создаст сравнимую среду разработки, то ничего меня не будет держать на x86/amd64. Более того, даже когда пишу что-либо под Linux, всё равно прототип делаю в MSVS. И даже при после переноса прототипа на POSIX своместимую платформу, использую MSVC как редактор кода (слава создателям Samba). И если на целевой платформе вдруг обнаруживается баг, то с помощью #ifdef код возвращается обратно в MS Visual C и отлаживается как консольное приложение Windows. Это самый оптимальный вариант для отлаживания низкоуровневых вещей и протоколов. Добавление от 04.04.2013 12:31: цитата: MIC user: > рынок микроэлектроники уже насыщен дешевой и качественной продукцией зарубежных компаний Вообще-то для любого разумного потребителя это является достоинством, а не недостатком. Ага. Нефть в обмен на продовольствие. Ключевое слово - зарубежные. Туземцы тоже меняли золото на бижутерию, и где теперь эти дикари?

1189. xameleon, 04.04.2013 13:36

MIC user, корень проблемы в менталитете граждан. Но раз уж Вы высказали своё мнение, то предложите Ваш вариант решения проблемы, а именно - вывода российской микроэлектроники на мировой уровень. Или предлагаете смириться и "забить"?

1244. xameleon, 05.04.2013 13:12

Хе-хе. Весёленькое обсуждение. После вчерашнего спора и испорченного настроения, хотел опубликовать здесь черновик системы команд с аппаратной поддержкой микроядра L4. Ну то есть то, что обещал месяц назад. Так сказать - вынести на суд общественности, похвастаться, учесть критические замечания и позаимствовать ваши идеи. В результате день ушёл на доработку документа. В результате "доработки", как обычно, велезла масса ошибок, мелких проблем и мест, которые срочно требуют оптимизации. Поэтому публикация системы команд в очередной раз откладыается. Чтобы сконцентироваться на оптимизации наиболее часто используемых инструкций, в процессе переработки решил очередной раз глянуть статистику - какие команды гененрирует (из моих исходников) компилятор gcc для amd64. До этого тысячи раз пристально вглядывался в ассемблерный код, но никогда особо не задумывался, какие команды используются наиболее часто. Результат обескуражил - безусловный лидер - различные формы команды MOV, на втором месте команды сравнения и условных переходов, третьи по частоте - арфиметические команды, сдвиги и логические операции. Команды вызовов подпрограмм занимают четвёртое место. Причём, методы С++ классов активно используют адресацию от регистра со смещением (this + смещение функции). Отдельно стоят операции работы со стеком - пролог и эпилог функции - push и pop соотвественно. Пожалуй, большую часть инструкций x86 компилятор не использует вообще! За всю практику ни разу не видел, чтобы компилятор использовал инструкции LOOP, SCAS, STOS и им подобные, а префикс REP видел только во вручную написанных библиотечных функциях. Тут следует оговориться - я практически никогда не использую операции с плавающей запятой, потому что в системном программировании они нужны очень очень очень редко. Кстати, о математическом сопроцессоре. В соседней теме, где сравнивают x86 c конкурентами, в процессе обсуждения родилась идея, использовать "интеллектуальный" сопроцесср, который с помощью CPU "кормится" сложными математическими выражениям в форме Обратной Польской Записи, а ответ возвращается так же в виде сообщений. Имхо, удачная идея - потому что можно получить профит на числодробильных задачах, посылая математическому сопроцессору на последующих итерациях только изменённые коэффициенты, если каким-то образом сказать сопроцессору помнить выражение с предыдущей итерации. Кроме того, такой подход позволяет иметь неограниченное число сопроцессоров, управляемых центральным процессором - это свойство сообщений. Однако, в этом случае появляется новая неприятная проблема - эту стройную идею ломают циклы с итераторами с плавающей запятой. Например, вот такой: код: for ( double f=0.0; f <= 1.0; f += 0.01) Хотя... если подумать, то можно, наверное, ввести в систему команд математического сопроцессора поддержку выражений для циклов. В этом случае вместе результатами расчёта математического выражения в ответном сообщении можно возвращать и логическое значение условия выхода из цикла. Т.ч., уважаемые господа, очередные вспышки на Солнце или следующий спор о мироустройстве, могут сподвигнуть меня на публикацию "идеальной системы команд" для "идеального микропроцесора".

1246. xameleon, 05.04.2013 13:57

цитата: Boris Usievich: Вы бы почитали мануалы от Intel - узнаете, что тот же loop не рекомендован к применению со времен 486. держат его исключительно для совместимости. Так это же отлично! Это лишнее подтверждение того, что x86 содержит в себе массу legacy функциональности, которая лишь занимает площадь на кристалле. Требование совместимости - хороший якорь, который тормозит любую разработку, будь то железка или софт. цитата: совершенно неудачная, x87 был стековый и от него отказались. Мы это уже обсуждали :) x87 не умел оперировать сложными выражениями, поэтому и преимуществ не было. Разве он мог хранить инвариантное выражение? Кроме того, если не ошибаюсь, команды для x87 располагались в той же области памяти, где и команды CPU. Я же имею несколько другое - не располагать в программном коде команды сопроцессору. С точки зрения процессора, арифметические выражения и сами числа - это просто набор байт, который с помощью сообщения передаётся сопроцессору. Если провести очень грубую аналогию, то с точки CPU, математический сопроцессор, это "чёрный ящик", которому что-то передаётся и в отвеет что-то возваращается. Микропроцессор вообще ничего не знает о семантике команд сопроцессора. Фактически, даже нет необходимости использовать ОПЗ, например, сопроцессор может быть настолько интеллектуальным, что будет сам переводить из привычной человеку нотации в ОПЗ. Т.е. использование ОПЗ удобно и оптимально, но совсем не принципиально с точки зрения организации взаимодействия устройств.

1249. xameleon, 05.04.2013 14:30

цитата: Boris Usievich: Ради ваших замечательных идей никто не будет гробить производительность. Признаюсь, я не силён в операциях с плавающей запятой - они вне области моих интересов. А по основной работе, за счёт которой и существую, просто использую не задумываясь, как оно устроено на низком уровне. Однако, есть подозрение, что на тестах именно предложенный подход покажет исключительную производительность. Дело как раз в том, что вычисляемое выражение после первой итерации _уже_ расположено в сопроцессоре. Что проще? Каждый раз заново выбирать полностью математическое выражение или просто обновить несколько коэффициентов? Думаю, ответ очевиден. И распараллеливание. Не зря же сейчас используют видеокарты для тяжелых вычислительных задач. Это очень близко к проповедуемой мной идее. Отличие лишь в том, каким образом происходит взаимодействие CPU и вычислительного устройства.

1255. xameleon, 05.04.2013 16:53

цитата: Boris Usievich: если вы хотите вычислять одно и то же выражение независимо миллион раз, то смотрите на GPU. А это уже интересный вопрос. Очень любопытно, на каком классе задач встроенный сопроцессор имеет преимущество перед GPU? Подкину дровишек в тему. Серверные примемения легко обходятся без плавающей запятой. Имхо, транзисторы, занятые сопроцессорм, в серверных конфигурациях гораздо оптимальнее задействовать для аппаратного ускорения TCP/IP - аппаратно считать контрольные суммы, считать/хранить хэши таблицы маршрутизации и т.д. Для физических, химических и биологических расчётов, а так же для компьютерной графики GPU - лучшее решение. Что остаётся на долю FPU? Вопрос без иронии, на самом деле интересно.

1405. xameleon, 08.04.2013 12:40

цитата: BarsMonster: Переход всей страны на Linux в любом случае нужен в том числе и для массового использования в будущем отечественных процессоров. Не на Linux, а на Xameleon. За это сообщение сказали спасибо: vss

1408. xameleon, 08.04.2013 13:38

цитата: Krufter: Xameleon MMU требует обязательно? MMU активно используется для вызова sbrk (который меняет размер кучи (heap)) - системный вызов sbrk в Хамелеоне подгружает виртуальные страницы к адресному пространству процесса, если при выделении памяти (malloc) не находится "дырки" достаточного размера. Здесь ничего нового, так поступают все известные мне системы. Второе место, где активно используется виртуальная память - область данных процессов и нитей. Сделано это через "page stream", область памяти которая растёт по мере увеличения числа задач/потоков. Этот код легко заменяется на статически выделенную область памяти под заранее заданное количество процессов/потоков. Подход "пула виртуальных страниц" для хранения свойств процессов выбран для увеличения быстродействия. Таким образом максимально быстро происходит выборка соответствующей структуры по номеру задачи - номер задачи является индексом массива, а вся работа по организации плоской линейной структуры приходится на MMU. В принципе, можно сделать версию без MMU, но при этом потеряется некоторая функциональность. Т.е. для встраиваемых применений вполне реально сделать версию без MMU. А вот для систем общего назначения без MMU никак.

1492. xameleon, 09.04.2013 21:30

цитата: MIC user: А в чем смысл разработки процессоров позавчерашнего дня ? Даже с автомобилями, тьфу-тьфу, как-то разобрались. Само собой, если обнаружится проект по созданию чего-то нового, интересного, эффективного и окупаемого в конечном итоге - я за такой процессор. Новое и интересное это аппаратный планировщик, регистры сообщений и MMU с поддержкой flexpages. Причём, эти новшества никак не отменяют и не (сильно) противоречат модным тенденциям - конвеерам, предсказателям и Out of Order execution. Наоборот, с ростом числа ядер растут преимущества от модели взаимодействия через синхронные сообщения.

1498. xameleon, 09.04.2013 23:05

цитата: Boris Usievich: а слабо это хоть чем-нибудь подвердить? на практике попытки реализовывать всю эту теоретическую красоту разбились о хреновую производительность. На практике этим серьёзно не занимался никто. Изначально был такой миф, над которым долго смеялись немцы: "Ваше микроядро потому быстрое, что маленькое и помещается в кэше процессора". Из ответов на такие утверждения развился целый фольклор. Очень интересно слушать о хреновой производительности того, чего ещё не существует. Имею в виду именно аппаратную поддержку. Что касается прототипа системы, то если есть интерес можете потестировать версию "Concept", которая, собственно, доказывает реальность использования микроядра. Для начала история мифа о "хреновой производительности". Его истоки лежат в организации взаимодействия ядра и прикладного кода. Если "тупо" переложить системные вызовы на синхронные сообщения, то получаются бло-ки-ров-ки. С этим сталкивается абсолютно каждый разработчик. Это природа синхронных сообщений. И решают это проблему в лоб - на каждую пользовательскую задачу/нить создают нить в ядре. Иногда делают сериализацию вызовов, что несколько улучшает производительность. Именно отсюда растут ноги "хреновой производительности" - никаких преимуществ в добавлении лишней абстракции к существующей парадигме обработки системных вызовов. А на уровне ядра, нити, выполняющие всю низкоуровневую работу, так же как и в монолитных системах, продолжают конкурировать за ресурсы и блокируют друг друга. При таком подходе преимущества от реализации системных вызовов через сообщения не может быть в принципе. Т.е. вообще. Интересно, найдётся ли хоть один человек в мире, кто в здравом уме это оспорит? Добавляйте хоть тысячу процессорных ядер, но при таком подходе монолит окажется более оптимален. Решение лежит на поверхности - сколько бы исполнительных ядер не поддерживала система, задачи надо распределить таким образом, чтобы каждая задача, владеющая каким либо ресурсом, исполнялась только на одном ядре. Сложную задачу можно разбить на несколько более простых, но основополагающий принцип - любым ресурсом владеет только одна единственная задача. Таким образом исключаются блокировки, защищающие ресурс от одновременного доступа. цитата: Boris Usievich: цитата: xameleon:Наоборот, с ростом числа ядер растут преимущества от модели взаимодействия через синхронные сообщения. а слабо это хоть чем-нибудь подвердить? При традиционном подходе, с увеличеникм количества ядер, растёт и конкуренция за ресурсы, а тут уже два варианта - или тупо греть процессор, накручивая спинлоки, или переключать контекст, ломая кэши. Сейчас считается, что покрутить спинлок, это меньшее из зол. А теперь сравните со спокойным последовательным исполнением задачи, где точки блокировки строго определены, а сама блокировка возможна только при ожидании передачи или приёма сообщения. В итоге имеем отказ от спинлоков и детерменированное количество переключений контекста, которых по определению меньше, чем при конкурентной борьбе за ресурсы.

1518. xameleon, 10.04.2013 13:40

Boris Usievich Таки непонятно, убедили ли Вас мои аргументы о премуществе аппаратного микроядра или нет? К предыдущему посту хочу добавить, что в случае аппаратной реализации микроядра как части процессора, накладные расходы на обмен сообщениями сравнимы с обычным вызовом CALL. Ценой нескольких дополнительных тактов на процедуру "Inter Process Communication", которая реализуется как новая инструкция в системе команд, мы исключаем потери на синхронизацию и полуаем массу новых возможностей. К сказанному выше, а именно отказу от объектов синхронизации на уровне ядра ОС, можно добавить следующее: Таймеры, привычном нам виде, становятся не нужны - они реализуются через Send/Receive timeouts. При этом знчительно упрощается код, использующий таймеры. Аппаратный планировщик с древовидными приоритетом. Причём, принудительное переключение задач при исчерпании кванта времени скорее всего означает ошибку - задачи переключаются при обмене сообщениями. Отпадает необходимость в запрете прерываний, инструкции останова процессора и инструкциях инициализации внутренних данных планировщика. Поясню третий пункт. Команда запрета прерываний не нужна в виду того, что обработчики прерываний - такие же задачи, как и любые другие. Достаточно дать наивысший приоритет задаче, которую по какой-то причине нельзя прерывать, и уже ничего её не остановит, пока она не войдёт в фазу обмена сообщениями или не совершит какое либо недопустимое действие. Инструкция HALT становится попросту не нужна. Процессор сам переходит в режим низкого энергопотребления, если все задачи находятся в состоянии ожидания входящего сообщения или в ожидании готовности приёмника. Инструкции инициализации не нужны по простой причине - поскольку задачами управляет аппаратный планировщик, то начальная установка счётчика команд, указателя стека, регистра флагов, таблицы страниц, приотритета задачи и любая другая информация - это всего-лишь сообщение аппаратному планировщику.

1521. xameleon, 10.04.2013 14:39

цитата: Boris Usievich: нет, естественно. Вы стабильно игнорируете то, что все предыдущие попытки внедрить микроядро обломились из-за проблем с производительностью. Спасибо, что на этот раз не проигнорировали. Первое, что я хочу возразить - в мире нет разработок, в которых бы попытались разместить микроядро на кристалле. Если я не прав - буду благодарен, если покажете таковые. А теперь расспотрим предыдущие попытки: Система Minix от Таненбаума. Благо, код первой версии Minix целиком опубликован в его книге о построении операционных систем. Анализируя код первой версии Minix можно с уверенностью сказать, что он и не мог отличаться высокой производительностью - Minix писалась для студентов, большинство мест делались понятными в ущерб производительности. Помимо этого Таненбаум был пионером в микроядерном подходе, многие вещи были реализованы для обкатки идей. С таким же успехом можно сравнивать Windows 95 c Windows 7, как сравнивать Minix с L4 Pistachio. В первом случае мы сравниваем Windows, во втором случае сравниваем микроядра. Теперь посмотрим на GNU Hurd. Я не знаю, но каким-то образом эти ребята умудрились релизовать некоторые вещи через опрос в цикле. Около десяти лет назад я запускал Hurd на Compaq Presario. Как результат - бешенные вой кулера и зависание от перегрева. Как надо реализовать ОС, чтобы в режиме ожидания выжимать 100% процессорного времени? Дальше хуже - один из энтузиастов решил перенести Hurd на микроядро L4. Помню как сейчас его разочарование от результата - Hurd/L4 скушал всю память. А это именно подход, когда микроядро использовалось в виде прослойки для организации системных вызовов. Теперь Solaris от Sun. Эта мысль кажется крамольной, но есть подозрение что Sun сдулся как раз из за огрехов проектирования этой операционной системы. Всё тот же подход - нить в userspace порождает нить в kernelspace. Остаётся только догадываться, как процессоры Sparc и Java помогали держаться компании "на плаву". А теперь более удачный пример - Mac OS X на микроядре Mach. Что бы там не говорили маркетинговые лозунги о гибридном ядре, но Mach это всё же изначально микроядро. А вот гибридный подход, это костыли. Обычные костыли, вызванние недостатками Mach и необходимостью совместимости с предыдущими версиями. Тем не менее ни один маковод не согласится с Вами, что Mach это тормоза. Следующй пример очень удачный и не в Вашу пользу - это микроядро Neutrino и основанная на нём QNX - оно не тормозит и даже realtime. Наконец, микроядро L4 - это абсолют, это квинтэссенция всего лучшего, что было исследовано и открыто в области микроядер. В L4 существует только одна проблема - это перестройка мышления разработчиков, которые собрались его использовать. Чтобы оптимально испльзовать L4 - нужно мыслить категориями синхронных сообщений, а это очень трудно, если всю жизнь использовал асинхронные или не использовал сообщения вообще. цитата: К сказанному выше, а именно отказу от объектов синхронизации на уровне ядра ОС все прямо бросились выкидывать работающий код и все переписывать под вашу разработку :cool: Всё лежит в несколько другой плоскости. У меня есть разработка ядра операционной системы. Микроядро L4 это разработка не моя, а покойного Jochen Liedke, Технического Университета города Karlsruhe, Дрезденского Технологического Университета и Университета Нового Южного Уэльса в Австралии. Я лишь использую их разработки и активно продвигаю идею аппаратного микроядра.

1525. xameleon, 10.04.2013 15:27

цитата: Boris Usievich: А теперь более удачный пример - Mac OS X на микроядре Mach. Что бы там не говорили маркетинговые лозунги о гибридном ядре, но Mach это всё же изначально микроядро. Это не микроядро именно потому, что производительность нужна. Вот картинка, демонстрирующая монолоит, микроядро и гибрид: http://upload.wikimedia.org/wikipedia/commons/d/d0/OS-structure2.svg Вероятно, Вы её уже видели. Вот именно она и даёт мне право кинуть камень в огород Mach - не надо мыслить категориями kernel space и user space - микроядро L4 предоставляет другую абстракцию - address space. И всё! Только адресные пространства. Только адресные пространства. Только адресные пространства. Это мантра. Адресное пространство - это понятие, реализованное c помощью MMU процессора, а именно таблицы страниц. Нужна максимальная производительность - поместите всё всё всё в единое адресное пространство - и ядро и драйвера и пользовательские задачи. Единственное, что может этому помешать, отсутствие команды относительных условных и безусловных переходов и вызовов. Иными словами, позиционно независимый код может целиком исполняться в едином адресном пространстве. Никаких накладных расходов на поддержку виртуальной памяти. В противовес - можно каждую каждую задачу, каждый драйвер, каждый модуль ядра - всё всё всё поместить в своё собственное выделенное адресное пространство. При этом просядет производительность, но можно доверить писать драйвера школьнику с семью классами образования - его драйвер никогда не повалит операционную систему, не приведёт к kernel panic, не покажет синий экран смерти. И самое вкусное - можно произвольно комбинировать любые сочетания прикладных программ, драйверов и модулей ядра, например, сделав "кривую" схему, расположив все пользовательские задачи в одном адресном пространстве с ядром, а каждый драйвер вынести в отдельное адресное пространство - глупо, но возможно. Более того, можно ключом указывать загрузчику, где размещать каждый модуль - в выделенном адресном пространстве или в контексте другого процесса. Такой гибкости не предоставляет никто. Пора уже, пора отказаться от разделения kernel space/user space - из этого подхода уже выжат максимум и никих революционных изменений уже не будет. Будущее за понятием "Адресные пространства". цитата: вопрос в том, что вы на этой системе делаете. А то ничегонеделание не тормозит :) Наверняка Вы используете Windows. Нажмите Ctrl+Alt+Del, затем "Запустить диспетчер задач" и Вы увидите, что 99% времени загрузка процессора равна ~0. Подавляющее большинство компьютеров, планшетов, телефонов и даже серверов, большу часть времени заняты выполнением команды HLT.

1533. xameleon, 10.04.2013 17:23

цитата: Boris Usievich: Нужна максимальная производительность - поместите всё всё всё в единое адресное пространство - и ядро и драйвера и пользовательские задачи. И ваша система будет падать от тривиальных ошибок в пользовательских программмах. И что еще хуже, ее будут ломать за 10 секунд "хакеры" c 5 классами образования. все еще непонятно, почему таких OS никто не делает? Моя падать не будет, ибо пользовательские задачи и ядро исполняются в различных адресных пространствах. Между тем, подход "всё в едином адресном пространстве" вполне оправдан для встраиваемых приложений. цитата: Хотите и вируальную память отменить? и програаммы будут падать по недостатку памяти? Ну вот с чего Вы сделали такой вывод? Напротив, я прошу поддержку универсальных виртуальных страниц, чей размер определяется следующей формулой 1024 * 2 ^ N, где N находится в диапазоне от 0 до значения, покрывающего всё адресумое пространство. Микроядро L4 Pistachio эмулирует такие страницы программно, на основе физически поддерживамых архитектурой страниц. цитата: Пора уже, пора отказаться от разделения kernel space/user space Идите в форум по софту, там вам объяснят, почему вы неправы :) Ага. И начинать с самого начала объяснять народу что такое flexpages, адресные пространства, синхронные сообщения и вообще проводить полный ликбез. Зачем? Кому надо - и так знает/узнает. Вообще-то я Вас хорошо понимаю - это большая психологическая ломка, когда приходится пересматривать традиционные решения - всё внутренне естество сопротивляется, используя при этом накопленные знания. Однако, если хорошо рассудить, то понятие kernel/user space лишь частный случай адресных пространств. Только при использовании адресных пространств у программиста появляется больше степеней свободы. 99% защиты обеспечивается разделением адресных пространств. Что там у нас в остатке kernel space - привелегированные команды? А вспомните - пару ответов выше я предложил напрочь отказаться от таких команд - любое управление процессором должно осуществляться через передачу сообщения аппаратному планировщику. А тот минимум, который необходим для управления процессором - это всего лишь сообщения аппаратному планировщику. Создание или уничтожение адресного пространства, создание, инициализация или уничтожение нити исполнения, привзяка нити к адресному пространству, управление любым режимом работы микропроцессора - всё это реализуется через сообщения аппаратному планировщику. Разумеется, не каждая задача имеет права на управление процессором - если будет интерес, то я расскажу как выстроены привелегии в L4-X2.

1538. xameleon, 10.04.2013 19:47

цитата: Boris Usievich: чтобы вам там объяснили, где вы неправы и там это будет топиком, в то время как тут - оффтопик :) В этой теме есть надежда, что кто-нибудь из причастных к разработке CPU заинтересуется. Тем более, что запрос на что-нибудь революционное давно читается в глазах участников. :) За это сообщение сказали спасибо: vss

1608. xameleon, 12.04.2013 04:30

цитата: Krufter: Распишите, если не трудно, подробнее о том, что вы предлагаете реализовать в железе и о возможности портирования вашей ОС на процессор без MMU, но с контроллером памяти. Не скажу, что мне легко далось это сообщение, но я разместил его на форуме Мультиклета. Основной документ, описывающий все аспекты микроядра L4-X2, находится здесь: http://l4ka.org/l4ka/l4-x2-r7.pdf На основе более чем 10 летнего опыта использования микроядра L4 Pistachio, появилось представление о том, каким образом аппаратно реализовать спецификацию L4. В результате было создано описание аппаратного планировщика: https://docs.google.com/file/d/0Bzo8HAmNqHgAQ1BJeEc5…/edit?usp=sharing В настоящий момент мы работаем над новой расширенной и исправленной ревизией этого документа. Говоря простым языком, необходима возможность синхронно передать 64 машинных слова между задачами. В данном случае под задачей подразумевается последовательность инструкций процессора, использующая регистры общего назначения, счётчик команд, указатель стека и флаги. Заранее прошу прощения у разработчиков процессора Multiclet, если в этом посте продемонстрирую непонимание приниципов его работы. Рассматривая процессор Multiclet, самым простейшим решением будет передача блока регистров сообщений между клетками. В таком случае получим схему, где каждая клетка выполняет одну единственную задачу. Однако, это простейшее решение не будет оптимальным в виду синхронности. Поясню на простом примере - допустим, пользовательская задача выполняется на одной клетке, а ядро системы на другой. Простейший системный вызов, например чтение данных, в виду свойства синхронности сообщений, заблокирует пользовательскую клетку до получения ответа - таким образом получаем простой пользовательской клетки во время выполнения операции чтения клеткой, выполняющей функции ядра. Решением проблемы "простоя в ожидании" может быть переключение контекста, то есть всякий раз, когда клетка блокируется в ожидании какого либо события, её можно использовать для выполнения другой задачи. Для этого необходимо каким-то образом переключить контекст - сохранить регистры текущей задачи и загрузить регистры другой задачи, незаблокированной в ожиданнии, имеющей наивысший приоритет и имеющей неиспользуемый квант времени. Частный случай такой схемы - задача инициатор сообщения и задача приёмник сообщения выполняются на одной и той же клетке. Для переключения задач могут быть задействованы различные способы, это могут быть блоки регистров, которые коммутируются к клетке, это может копирование регистров в какой либо внутренний кэш или во внешнюю память, а так же может быть комбинация различных методов - с точки зрения программы это несущественно, а важно лишь то, что операция переключения задач может произойти лишь во время обработки сообщения. С точки зрения L4, принципиальный момент в том, что внешние прерывания и аппаратные исключения - это тоже сообщения. Таким образом сообщения являются базовым принципом взаимодействия задач и основным инструментом управления процессором. Свойство синхронности сообщений описывается следующим правилом: "Сообщение может быть передано тогда и только тогда, когда принимающая задача находится в состоянии ожидания сообщения". В противном случае передатчик сообщения блокируется до готовности приёмника сообщения или до истечения таймаута, указанного в сообщении. Для приёмника сообщения действует то же самое правило - он блокируется до приёма сообщения или до истечения указанного таймаута. Время тайматуа задаётся логарифмической величиной с граничными значениями "не ждать" и "ожидать сообщение". В случае нулевого таймаута ("не ждать"), сообщение может быть передано только при условии, что приёмник уже находится в состоянии ожидания, в противном случае команда передачи сообщения вернёт ошибку "Превышено время ожидания ответа". Эта же ошибка будет возвращена, если за время таймаута сообщение не было принято или передано. Оригинальный документ (l4-x2-r7.pdf) определяет три типа данных, которые могут быть переданы в сообщениях - простые нетипизированные слова, строки (в том числе составные) и универсальные страницы памяти. Спецификация l4-x2 определяет способ отображения физической страницы памяти в виртуальное адресное пространство задачи через операцию передачи сообщений - если задача владеет страницей памяти и помещает её описатель в сообщение (типизированное слово), то это сообщение производит отображение передаваемой страницы в виртуальное адресное пространство задачи приёмника. Отсутствие MMU исключает возможность передачи универсальных страниц памяти (flexpages). Спецификация l4-x2 называет строкой блок памяти, который описывается указателем на начало блока и длиной блока. Составные строки могут описывать несколько несмежных блоков памяти. Во время передачи сообщения эти блоки (определены типизированными словами) копируются из адресного пространства задачи источника сообщения, в адресное пространство задачи приёмника сообщения, по адресам, назначенным строкой акцептором. Минимальная реализация может использовать лишь простую передачу нетипизированных слов между клетками. Отстутствие адресных пространств так же исключает необходимость передачи строк - в данном случае можно передавать обычные указатели на блоки памяти и их размер посредством нетипизированных слов в сообщениях. Что касается возможности портирования на процессор без MMU, то это возможно, но с уходом от POSIX совместимости. Существет главный системный процесс Supervisor, который на основе примитивов L4 реализует управление процессами и виртуальной памятью, попутно реализуя часть стандарта POSIX (fork, exec, sbrk, signal и т.п.). Без виртуальной памяти о POSIX совместимости можно забыть - и копию процесса не создать, и кучу не увеличить. Супервизор сильно завязан на "универсальные виртуальные страницы" и в полную силу использует возможности витуальной памяти. Гораздо оптимистичнее обстоят дела с файловой системой, сетевым стеком и драйверами устройств - они минимально зависимы от виртуальной памяти, а если где и используют динамическое выделение памяти, то практически всегда имеют альтернативную реализацию аллокаторов памяти из статического пула. Т.е. запустить операционную систему на процессоре без MMU возможно, но при этом будет нарушена POSIX совместимость. В настоящий момент система по функциональности лишь приближается к раннему стандарту POSIX, а отстутствие виртуальной памяти ещё дальше отодвинет систему от этого стандарта.

1995. xameleon, 06.05.2013 16:54

цитата: pui_i: Массовое производство может снизить только цену, но не повысить производительность относительно конкурентов. Производительность Э - ниже плинтуса. Производительность, производительность. А всем ли нужна производительность? Более 15 лет наблюдаю картину, когда обновляешь систему и она начинает тормозить - как минимум больше и больше уходить в SWAP. Доходит до того, что работать становится невозможно. Это касается не только ОС, но и софта, в т.ч. сред разработки. Затем следует апгрейд железа и всё повторяется снова. И таких метаморфоз уже около десятка. Кому нужна производительность? Для каких-то расчётных задач и для игр. Большинству офисных задач достаточно одной десятой от производительности Эльбруса. Не хватает памяти и мегагерц? Пишите оптимальный код, используйте продвинутые алгоритмы, оптимизируйте "узкие места" вручную, считайте такты. Добавление от 06.05.2013 17:01: цитата: SuperZveruga: И это более чем актуально. Последнии версии офиса от Билли идут с новым форматом документов. Формат патентован и закрыт. Накой госструктурам такое счастье? Откуда информация? Майкрософт отказалась от "Office Open XML"? Добавление от 06.05.2013 17:06: цитата: SuperZveruga: Дак использовать его в своих коммерческих целях без разрешения Майкрософт нельзя. Попробуйте написать программу с использованием формата xlsx или docx. Они ведь и придумали новый формат из-за свободного его использования в опеноффис. Боятся миграции. Закручивают гайки. Минутку. Я писал для своей компании экспорт в OOXML - DOCX, XLSX, PPTX и XPS. Не хотите ли Вы сказать, что продавая продукт, который умеет экспортировать отчёты в эти форматы, компания нарушает какой либо закон?

2031. xameleon, 07.05.2013 15:30

цитата: vss: Это вроде есть. Для военных же пишут системы. Будьте добры, скажите, что за системы пишут для военных? Назовите хотя бы одну, не основанную на Linux/BSD. Может быть Вы имели в виду PTS DOS? Добавление от 07.05.2013 15:36: цитата: vss: Там большой объем программирования, который, наверное, хочется выполнять в комфортабельных условиях - иначе большую систему не сделаешь. Комфортабельные условия, это удобная среда разработки и кросс-компиляция. Ядро операционной системы обычно предоставляет интерфейс для управления памятью и задачами. Чуть выше, но тоже в ядре операционной системы, находится уровень файловой системы. Сетевой стек - тоже часть ядра, но это не обязательно - во времена, когда сетевая карта и модемы были экзотическимим устройствами, сетевой стек устанавливался отдельно от операционной системы.

2196. xameleon, 17.05.2013 23:50

цитата: matik: Проблема как раз в том, что некоторые задачи требуют общего адресного пространства, а иногда и одной копии ОС. И тут на помощь должны прийти синхронные сообщения в стиле L4.

2221. xameleon, 19.05.2013 03:12

цитата: matik: Что Вы имеете в виду? Расшифруйте. Насколько я помню (специально не смотрел), с синхронными сообщениями проблема вроде была еще острее (наступала еще раньше). Если несколько ядер/процессоров используют общую память, то необходимо защищать эту память от одновременного доступа, чтобы не повредить структуру. Синхронные сообщения позволяют отказаться от использования объектов синхронизации, потому что синхронизация достигается самими сообщениями. Т.е. задачу, которая хорошо распараллеливается, но требует общей памяти, на 100 процессорной системе можно считать на 99 процессорах, а один процессор задействовать для управления и распределения ресурсов. Блокировки вычислительных задач будут происходить только при взаимодействии с управляющим поцессором. Код управляюещго процесса реализуется таким образом, чтобы максимально быстро обслуживать сообщения от вычислительных процессов. Это принцип. Предложите реальную задачу и её традиционное решение, я предложу её решение с помощью синхронных сообщений.

2229. xameleon, 19.05.2013 13:18

цитата: matik: Синхронные сообщения позволяют отказаться от использования объектов синхронизации, потому что синхронизация достигается самими сообщениями. Это только благие намерения, увы.[/i] Отнюдь. Я на синхронизации "собаку съел", поэтому знаю, о чём говорю. цитата: Угу. И в результате в Вашей системе будет 99 постоянно простаивающих процессоров, и один захлебывающийся обработкой очередей заданий. :-\ А суммарная производительность, увы, станет только меньше. Я же просил Вас привести пример расчётной задачи. Тогда можно говорить предметно. цитата: Кроме того, чем дальше произвольно взятый процессор от того, который распределяет задачи - тем дольше ему ждать распределения. В общем, зря Вы думаете, что никто не пробовал решить проблему. Все простые варианты испробованы. В процессе спора Вы забыли, что речь шла о задачах, которым нужна разделяемая память. Это подразумевает, что они исполняются локально на многопроцессорной машине. В этом случае понятие "дальше" не имеет значение. цитата: Код управляюещго процесса реализуется таким образом, чтобы максимально быстро обслуживать сообщения от вычислительных процессов. Это очередная маниловщина. Какая-то ветка-катастрофа: в ней почему-то отмечаются в основном отвлеченные мечтатели :( Ещё раз: Приведите пример хорошо распареллеливаемой задачи, требующей разделяемой оперативной памяти. цитата: А теперь с нетерпением слушаю, КАК решить проблему катастрофического роста служебных сообщений с ростом количества нод. Я не предлагал использовать синхронные сообщения для обмена служебными сообщениями между нодами. Только в пределах процессоров/ядер одной ноды. цитата: И заодно объясните, с ЧЕМ Вы будете синхронизировать свои "синхронные" сообщения. Они синхронные ЧЕМУ? Какой из скоростей? Межнодового обмена? Внутринодового обмена? Внутрипроцессорного обмена? Речь об обмене сообщениями между нодами не идёт. (Повторюсь, речь шла о расчётных задачах, которым необходима разделяемая память). Т.е. синхронизация исключительно внутри ноды. Понятие "скорость" в данном случае бессмысленно, поскольку синхронизация происходит исключительно между источником и приёмником сообщения - тот, кто не готов, тот блокируется. Итак, о какой расчётной задаче мы говорим?

2275. xameleon, 20.05.2013 05:26

цитата: VLev: начнём с linpack. Похоже, я готов съесть свой галстук. Мне не удалось придумать оптимальное использование синхронных сообщений для Linpack. Но это не значит, что это невозможно - просто я не осилил. цитата: Ну да ладно, ограничимся одной нодой, там тоже можно о синхронности поговорить. Асинхронность там нужна для повышения темпа обмена с памятью. Если делать как было предложено --- 99 процессоров считают, один общается с памятью, то и темп обмена будет на уровне 1/100 от возможного. Где профит? Подразумевалось, что 99 процессоров не только считают, но и общаются с памятью, а сотый процессор это координирует, например, разделяя матрицу на логические сегменты. При этом управляющий процессор следит, чтобы у каждого сегмента был лишь единственный владелец. При таком раскладе большую часть времени будет простаивать именно управляющий процессор, а не вычислительные. Впрочем, судя по коду Linpack, Вы были правы - в случае общего адресного пространства при увеличении числа процессоров узким местом станет быстродействие памяти.

2374. xameleon, 24.05.2013 14:32

цитата: Boris Usievich: Ben Laden А что тогда делается на Вин-машинах? Скорее всего рисование красивых картинок на больших экранах Вот оно. Вот! Это же решение. Решение для отечественных процессоров - тонкий клиент. Аппаратный X-терминал со специализированным процессором, выполняющим функции X-сервера. Всего-то надо - поместить на кристалле видеоадаптер, сетевую карту, аппаратный IP/TCP/UDP стек, аппаратный X-сервер с рендерилкой фонтов, USB для клавиатуры и мышки. Возможны расширения для будущих версий кристалла - подсистема Audio, XRender, Shape, Xinerama, Xv - всё в камне. Сложно? Да. Возможно? Да. Конкуренция есть? Нет. Востребовано? Конечно! Преимуществ великое множество. Вот некоторые из них: 1. Рынок сбыта почти неограничен - начиная от учебных заведений и заканчивая режимными предприятиями. Добавьте сюда "линуксоидов", кто захочет по цене монитора обзавестить ещё одним компом для жены, детей, родителей. 2. Тонкий клиент - один мощный компьютер способен обслужить несколько десятков терминалов. 3. Упрощенное администрирование - гораздо проще сконфигурировать и легче защитить от вирусов один сервер приложений, чем следить за десятком персоналок. 4. Решается проблема охлаждения - греться особо нечему. 5. Решается проблема свободного места - всё устройство реализуется в виде моноблока. 6. Минимальная конкуренция на рынке аппаратных Х-терминалов - во-первых, они вышли из моды, во-вторых, сейчас "днём с огнём" не отыскать аппаратный X-терминал. Предвижу возражения скептиков, мол, зачем изобретать то, что уже отжило. Так оно "отжило" по нескольким причинам - во первых, маркетинговые ошибки - эти терминалы были дороже "писишек", при том, что любую писишку можно легко превратить в X-терминал. Во вторых, X-протокол постоянно расширялся, а X-терминалы плохо поддавались апгрейду. (Доказательство - найдите среди X-терминалов устройство, поддерживающее, например, протокол Xinerama). В третьих, отрасль постепенно отворачивалась от протокола X11 в сторону RDP. Обсудим идею? Какие будут аргументы против? Что скажут Verilog/VHDL программисты?

2376. xameleon, 24.05.2013 14:40

цитата: vss: Тонкий клиент: http://www.mcst.ru/t_klient_.shtml Наверное, интересная штука, а где кнопка "Купить"? А где ссылка "Технические характиристики"? Почему бы не сделать это в виде SoC?

2378. xameleon, 24.05.2013 14:43

цитата: Boris Usievich: сомнительно. потому как к этому замечательному клиенту придется городить еще и сервер. от того, что вы перенесете свою задачу на сервер, потребности в железе не уменьшатся. Linux, BSD, (вероятно) Mac OS X - уже готовые серверы.

2381. xameleon, 24.05.2013 15:22

цитата: Boris Usievich: xameleon от того что вы поставите на сервер *nix быстрее он не станет Хех. Разве я отрицал необходимость быстрых процессоров или сравнивал быстродействие систем? Нет, я просто предложил направление, где конкуренция минимальна и которое востребовано. Фишка ведь в том, быстродействие современных компьютеров с лихвой покрывает 90% задач. К примеру, компьютер, который можно сейчас собрать за 15 тыс. рублей, вполне способен обслужить класс в кабинете информатики. Или, к примеру, АСУ на производстве. Разве там нужны большие вычислительые мощности? В большинестве случаев хватило бы мощного сервера и множества теримналов. Среднестатистический офис тоже не требует больших вычислительных мощностей. Почта, WEB, текстовый редактор, да электронные таблицы - суперкомпьютер не нужен. Хотя, OpenOffice ещё тот монстр - способен сожрать любые ресурсы, ну дык это проблема не системы/железа, а проблема рук программистов - если перед программистами поставить задачу, чтобы программа могла обслуживать больше число клиентов и не тормозила и не жрала память, то, я верю, - программисты справятся. Другое слабое место - если пользователи рабочих станций повадятся одновременно смотреть видеоролики в интернете. Вероятно, система просядет. А вот нефиг в рабочее время лазить по youtube - пущай работают, а не глупостями занимаются.

2383. xameleon, 24.05.2013 15:49

цитата: ПростоЗашёл: Мне интересно, а скольким человекам это нужно? Вы это не считали. Нужно это немногим. Если разобраться, то компьютеры вообще не многим нужны. Просто это модно и интересно, а вот необходимости нет. цитата: С одной стороны есть стики на, скажем, RK3188 типа QC802 Android Mini PC TV Dongle Rockchip RK3188 Quad core 1.8GHz 2GB RAM 8GB ROM WiFi Smart TV Player и разные MB на его основе. Чем ваша гипотетическая штука будет лучше, учитывая на порядок большую цену? Откуда цена больше? Вот с чего Вы взяли? Просто история имеет свойство повторяться на новом витке - современные компы мощнее мэнфреймов тридцатицатилетней давности. Используется эта современная мощь весьма тупо - большую часть времени она _не_используется_. Ниша тонких клиентов сейчас пуста. Особенно с уходом с рынка Sun, которая пыталась играть на этом поле. Самое время прийти и захватить рынок. цитата: Вы просто обнаружили тренд и пытаетесь его продавать, а поезд то уже ушёл. Выиграет тот кто вовремя почувствует и правильно поймёт будущий тренд В свете этой темы - нынешний локальный тренд российской микроэлектроники - радиационно стойкие чипы. На следующей неделе или месяце (здесь) будут обсуждать другие вещи - вот и другой тренд. :)

2386. xameleon, 24.05.2013 16:07

цитата: Boris Usievich: Нет таких направлений, Спорное утверждение :) цитата: прикиньте сколько стоят приличные мониторы на класс, и стоит ли при этом экономить на спичках :) ну и 30 счетных программ запущенных на несчастном компе за 15 штук доставят немало тормозов :) Да вот сходу. Старенький AMD Athlon 64 Processor 3000+ 1.8 GHz и 6Гб ОЗУ. Сравним с классом на "Электроника БК-0010Ш" - такие стояли в моей школе в 1990 году. Поделим 1.8 GHz на 30 рабочих мест - получаем 60 Мгц на рабочее место. Это даже быстрее большинства персоналок того времени. Поделим 6Гб озу на 30 рабочих мест - получаем 204 Мб. Сравним с "Электроника БК-0010Ш", которых вполне хватало, чтобы получить азы компьютерной грамотности? Итого, каждое рабочее место школьника в 20 раз быстрее рабочего места школьника в 1990 году. Каждый школьник имеет доступ к оперативной памяти в 196 тысяч раз больше, чем мог бы получить в 1990 году. Т.ч. я бы не был столь категоричен. Да и вообще, когда ресурсов мало, это дисциплинирует, заставляет включать мозг и писать оптимально. Добавление от 24.05.2013 16:09: цитата: alpha: Ну и кто из наших "брендов" может предложить "облака"? Облака - это нечто другое. Я имел в виду старый добрый протокол X11. За бренды не скажу, но думаю в России не мало умельцев, которые при желании могли бы создать аппаратный X-терминал на основе FPGA. Был бы интерес.

2388. xameleon, 24.05.2013 16:15

цитата: Boris Usievich: xameleon Ниша тонких клиентов сейчас пуста. потому что они никому не нужны в реальности. Не то, чтобы не нужны, просто те, кто мог бы использовать тонкие клиенты, не имеет о них представления. Дешевые аппаратные X-терминалы вполне бы могли захватить рынок. Давайте спросим, кто из здесь присутствующих запускал X-сервер не локально, а по сети. Добавление от 24.05.2013 16:20: цитата: Boris Usievich: xameleon Сравним с классом на "Электроника БК-0010Ш" - такие стояли в моей школе в 1990 году. оно уже тогда было убогим. Со своей задачей они таки неплохо справились. А самые любытные даже в машинных кодах чего-то программировали на факультативах. цитата: но думаю в России не мало умельцев, которые при желании могли бы создать аппаратный X-терминал на основе FPGA. Нафига тут FPGA городить если с этим справится дешевый универсальный процессор? сделать не проблема, проблема это впарить хоть кому-то. Так FPGA нужен лишь как макет, для демонстрации и отладки. А затем в кремний. Насчёт впарить - это другой разговор. Премущества я уже озвучил выше - компактность, малое энергопотребеление, отсутствие движущихся частей, централизованное администрирование, более высокая защита, дешевизна.

2400. xameleon, 24.05.2013 22:50

цитата: kayleth: Что будет делать ваш субъект со своим уникальным аппаратно-програмным комплексом, если нужно будет принять данные из формата 7-офиса, а этот комплекс "случайно" с ним не совместим? Office Open XML хоть и проприетарный, но весьма неплохо документирован. Если нужно принять данные из 7-го офиса - написать парсер. цитата: kayleth: Возможно вы захотите Wysiwyg. Но если его реализовать, тогда будет выполнен большой задел для графических "оконных" интерфейсов, т.е. использования текстового режима в ОС будет нецелесообразно (по факту будут реализваоны многие API для окон). Объем выполняемых операций в данном случае возрастет и будет ближе к 16-битным CPU (мин.). Требования к памяти тоже возрастут. Протокол X11 был опубликован в 1987 году, не считая более ранних ревизий. Для "иксов" написаны тысячи программ. В простейщем случае программы, написанные 10-15 лет назад, на современнном железе можно запускать десятками. В смысле по десять копий. Добавление от 24.05.2013 23:10: цитата: VLev: Кстати, что именно в X может быть принципиально улучшено аппаратной реализацией? Себестоимость железки. При массовом выпуске стоимость чипа относительно стоимости монитора очень мала. Т.е. в идеале чтобы чип встраивался в каждый монитор вне зависимости от необходимости.

2403. xameleon, 25.05.2013 00:48

Ben Laden А чем в данном применении Эльбрус будет лучше Атома или ВИА Наверное тем, что можно сделать специализированный чип, который функционально будет проще Атома или VIA, с более простым техпроцессом, а потом поставить производство на конвеер, по типу билетов на метро, чтобы себестоимость была менее 100 рублей. Кроме того можно изначально адаптировать схему под TFT матрицу, упростив обвязку.

2405. xameleon, 25.05.2013 03:35

цитата: matik: Это не будет Эльбрусом, процессором общего назначения. Так я нигде и не утверждал, что это должен быть Эльбрус.

2414. xameleon, 26.05.2013 04:15

цитата: nenin: цитата: Wizardry VII: Ерунду не говорите. Тогда как раз в ходу были Электроника УКНЦ МС 0511.01, БК 0010-01 и КУВТ Ямаха MSX-1/2. В 1990 году? :insane: ДВК-3, EC1841, IBM-XT, IBM-AT - как-нибудь так... В школьных кабинетах информатики?

2471. xameleon, 30.05.2013 03:57

цитата: Ben Laden: ПростоЗашёл Как же не связанные, когда закрытый софт никто даже портировать не будет. А он нужен, закрытый-то? Да и wine никто не отменял.... Разумеется - нужен. Если бы не закрытый софт, всякие фрюниксы выглядели бы сейчас приблизительно так: Утрирую конечно, но мешок аргументов под рукой.

2478. xameleon, 30.05.2013 13:42

цитата: Ben Laden: Убунты, например, не хватит разве? И выглядит она всвсе не так убого, как на картинке, это что-то совсем уж древнее. На картинке дедушка оконных менджеров - twm. Я к тому, что без коммерческого софта на Эльбрусе будет как-раз таки Убунта (или нечто уровня Убунты). И через год, и через 10 лет. Особенно в России. Современные Linux и его производные выросли вот из этого - https://www.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz - если почитать исходники, видно что это примитивная студенческая поделка. Причём, формат файловой системы "подсмотрен" у Minix. А вот здесь небольшой анализ на тему "Кто пишет ядро Linux" - http://www.pcweek.ru/foss/article/detail.php?ID=109200 Кстати, Intel предоставляет несколько другие данные - http://software.intel.com/en-us/blogs/2009/08/24/who…-the-linux-kernel, но тенденция просматривается. И что мы видим? Лидирует "Красная Шапка" - для которой Linux это хлеб и которая двигает его в корпоративный сектор. Рядом идёт Novell, основной продукт которой - NetWare, был убит не без помощи Linux. Следующими идут компании производящиее железо - IBM, Intel, MIPS. Причём, у Intel никогда и не было своей ОС, а вот у IBM в кармане кое-что имеется - http://www-03.ibm.com/systems/z/os/zos/ и http://www-03.ibm.com/systems/power/software/aix/ А теперь собственно ответ, почему нужен коммерческий софт - без коммерческого софта все потуги приведут лишь к появлению "принципиально новых" BolgenOS. Открытый софт хорош в странах, где существует сильная IT индустрия, представленная крупными корпорациями. В этом случае свободный и открытый софт дополняют друг друга и создают конкуренцию. В развивающихся странах открытый софт это необходимость, но в то же время он препядствует становлению коммерческих продуктов.

2482. xameleon, 30.05.2013 18:55

Ben Laden Отечественные процессоры тут при том, что запускать на них кроме свободных клонов юникса - нечего. Альтернативы попросту нет. Поэтому разработчики процессоров общего назначения и молятся на Линукс. Кстати, я тоже не понял Ваши сомнения относительно необходимости закрытого софта - он _уже_ не нужен, не везде нужен или не нужен вообще? А моё мнение простое - без отечественных компаний, пишуших коммерческий софт, отечественные процессоры особого смысла не имеют.

2573. xameleon, 03.06.2013 16:11

цитата: Ben Laden: futurama В защищенном режиме никакие трояны и прочие малвари не смогут никуда внедрится и красть данные. Под Линуксом это невозможно и под Атомами. И дело тут в софте, а не в железе. Если компилятор и линкёр знают, что есть раздельные стеки для аргументов и для вызова функций, то с некоторым усилием можно "заточить" ядро для этой фичи. С прикладным софтом полегче - во многих случаях достаточно просто скомпилировать его под Эльбрус, даже не используя "напильник". Только... приём с разделением стека на код и данные не даёт стопроцентной защиты. Он лишь закрывает одну большую дыру в защищенности. Однако, если долго и внимательно медитировать над исходным кодом ядра Линукс, то наверняка можно найти ещё сотню дырок поменьше, от которых разделяемый стек не спасёт.

2605. xameleon, 04.06.2013 13:55

цитата: ПростоЗашёл: nenin На счет Линукса: не надо строить иллюзий. Даже если бы дело обстояло и так мрачно как Вы нарисовали, то его использование желательно по совсем другим причинам чем безопасность. По каким причинам? Вот, скажем, если бы в России была компания, производящая закрытую коммерческую операционную систему, то чем использование Linux будет лучше, чем использование коммерческого продукта c закрытым исходным кодом?

2612. xameleon, 04.06.2013 16:37

цитата: ПростоЗашёл: Тем, что если вдруг эта компания обнаглеет, то всегда найдутся те, кто продолжит разработку перспективного продукта на основе открытого кода и лицензии. Пример LibreOffice я приводил. Понимаете, неважно где сделано, в России или нет если лицензия свободная и код открыт. Китайцы взяли Ubuntu и модифицируют под себя. Не понимаю. Если бы Вы 10 лет писали какой-то продукт, вкладывали деньги в разработку, а потом его взяли китайцы и модифицировали под себя, Вам бы от этого лучше стало? Они ведь, китайцы, могли бы купить Ваш продукт, Вы бы заработали денег и вложилил бы их в дальнейшее улучшение продукта. А так - Вы просто подарили китайцам плоды своего труда. Где профит? Верну Вам пример с LibreOffice - эти все свободные Wysiwyg офисы появились не вдруг, а как замена (ЗАМЕНА!!!) коммерческим продуктам. Заглянем в историю? (http://en.wikipedia.org/wiki/Comparison_of_word_processors) Очевидно, что до появления первого свободного текстового процессора EZ Word (1985), на рынке уже были четыре коммерческих продукта - WordPerfect (1980), Ichitaro (1983), Microsoft Word (1983), AppleWorks (1984). Как видно - временной промежуток между первым коммерческим продуктом и первым свободным - 5 лет в пользу коммерческого. Сравните качество продуктов самостоятельно. Что Вы хотите доказать? Что индустрию двигают свободные продукты? Это смешно. Опять же, больший профит от СПО пока что поимели корпорации, используя его как инструмент конкурентной борьбы. А ещё некоторым из них СПО сильно сэкономило расходы на R&D - возмите для примера хотя бы Android. Прошу понять меня правильно - я не против свободного ПО и Linux использую с 1995 года. Но конечному потребителю польза от СПО в том, что, во первых, он может выбирать между условно-бесплатным и коммерческим. Во вторых - СПО заставляет напрягаться коммерческие компании, делая свои продукты лучшего качества, чтобы их продукцию продолжали покупать. Итог в том, что если в вашем палисаднике нет компании, которая бы производила коммерческий продукт, то она и не появится, пока существует условно-бесплатный аналог. Т.ч. приходится кушать то, что дают. Наконец, возвращаясь к процессорам. Иногда недостатки архитектуры можно компенсировать алгоритмом. Например, поиск перебором на быстром железе проиграет поиску через хэш-функцию на медленном железе. Но если все будут пользовать единый открытый код, то нивелировать недостатки железа более продвинутым алгоритмом будет проблематично. Впрочем, закрытый код так же работает и для защиты Intellectual Property - http://ru.wikipedia.org/wiki/Блоб

2688. xameleon, 10.06.2013 16:57

цитата: Нуб: А прерывания-то зачем, еще в эпоху 8080, если я не ошибаюсь, их чехвостили за это и в хвост и в гриву, и сам термин (в рамках супера) как-то не пременим ) да и вообще сам термин прерывание он сейчас хоть какое-то значение имеет ? Какой-то странный вопрос. Существует полторы альтернативы прервыаниям - опрос в цикле и сообщения. Опрос в цикле греет процессор, жрёт батарейку и вообще отнимает время от полезных задач. А вот передача прерываний сообщениями требует чтобы процессор аппаратно поддерживал такой механизм.

2692. xameleon, 11.06.2013 13:54

А вот вопрос ко всем - есть ли в этой теме читатели/писатели, относящиеся к руководству (люди принмающие решения) названных компаний? МЦСТ, Ситроникс, Ангстрем, Микрон, Миландр, Мультиклет и др. Если такие люди здесь присутствуют, то второй вопрос - не желаете ли создать консорциум? Цель консорциума весьма простая и понятная - разработка и принятие стандарта, совместимого с L4 eXperimental Kernel Version X.2.

2696. xameleon, 11.06.2013 14:51

цитата: KT: xameleon Думаю, что обсуждать это можно. Но организовать консорциум и заставить его реально работать будет очень непросто. Организовать сложно, с этим не спорю, а вот заставить работать будет проще. Собственно, участников и не нужно будет заставлять работать - когда дело дойдёт до обсуждения стандарта, участники сами будут продвигать выгодные им решения и критиковать решения конкурентов. Добавление от 11.06.2013 14:56: цитата: Boris Usievich: смешной вы, хотите чтобы все вокруг все бросили и занимались вашей идеей? Идея не моя, а покойного Jochen Liedke. Я лишь жрец этой религии :) Зачем всё бросать? Есть немало наработок, которые не отрицают существующие решения, но дополняют их. Участие в консорциуме ни к чему не обязывает, но даёт возможность коомпаниям протолкнуть свои идеи и стоять у истоков спецификации, что теоретически может дать конкурентные преимущества. К примеру, конкретно по аппаратному микроядру или к спецификации L4X2 у Вас замечания или претензии имеются?

2707. xameleon, 12.06.2013 13:33

цитата: Krufter: Ну надо сначала разобраться как у вас всё работает и в чём основные преимущества над другими, тогда и напишу вопросы по портированию. Преумещства возникают на многопроцессорных/многоядерных конфигурациях. Попытаюсь в очередной раз объяснить идею на простейшем примере - КР580ВМ80 (аналог 8080). Для начала сделаем его "многозадачным" - введём понятие Блок Описания Задачи - TCB (Task Control Block). Для простоты ограничим максимальное число задач 64 задачами. Под каждую задачу отведём 64 байта и расположим массив блоков описания задач по адресу 0x1000. Таким образом для получения TCB задачи по её номеру используем простейшую формулу TCB = 0x1000 + 64 * Task_ID. Так же используем аппаратный таймер, который будет вызывать процедуру, последовательно выгружающую текущее сотояния задачи в текущий TCB и восстанавливая следующую задачу из следующего TCB. TCB "закольцованы", поэтому после последней задачи переключаемся на первую. Некоторым аналогом TCB в процессоре i386 является TSS (Task State Segment) В результатет получается "многозадачный" процессор без приоритетов и распределния времени. Имеет ли он смысл? Возможно, если напрячь мозги, можно найти область применения, но для реальных задач необходимо предусмотреть возможность синхронизации. Умышленно выбрав 8-ми битный процессор, мы получаем проблему доступа к 32-х битным значениям. А что если таймер сработает в момент записи младших байт 32-битного слова? Это лишь половина "беды", другая проблема - доступ к видеопамяти. Если одна задача пишет на экран слово "Привет", а другая задача слово "Пока", то в такой схеме возможно получить вывод "ПрПоивекат" - вывод от двух задач перемешается. Одно из оптимальных решений этих проблем - использование сообщений. Из 64-х доступных задач выделяем одну, отвечающую за вывод на экран и посылаем ей сообщения. Мы подошли к самому интересному - для реализации сообщений вводим дополнительную инструкцию - EXCHANGE_MESSAGE. У неё есть два аргумента - номер задачи приёмника и номер задачи источника. Если аргумент приёмника равен нулю, значит задача не посылает сообщения, если аргумент источника равен нулю, значит задача не слушает сообщений. Если аргумент источника равен 0xff - задача слушает собщение от любой задачи. Итак, задача, владеющая экраном, блокирована в инструкции EXCHANGE_MESSAGE и слушает сообщения от любых задач. Задачи, выводящие сообщения на экран, посылают данные с помощью инструкции EXCHANGE_MESSAGE сообщения задаче владельцу экрана. В случае, если какая-то задача не готова - например, задача владелец экрана ждёт данные для вывода на экран, или задача, выводящая данные, ждёт готовности владельца экрана, в TCB ожидающей задачи помечается её состояние и при переключении задач она пропускается. В самом простейшем случае, команда EXCHANGE_MESSAGE всего лишь помечает состояние в TCB и переключает задачу, отдавая свой квант времени следующей задачи. На самом деле всё где-то в сто раз сложнее и оптимальние, но на этом простом примере я попытался показать принцип. К сожалению мне необходимо убегать, продолжу в другой раз.

2711. xameleon, 13.06.2013 01:51

цитата: Krufter: Возможно будет испытать вашу ОС в деле на мультиклеточном процессоре новом? При наличии средств разработки и development board - я и мой компаньон могли бы попытаться перенести систему на мультиклеточный процессор и предоставить команде разработчиков бинарный образ системы. Пока что мы не в том положении, чтобы предоставить исходный код даже при условии Non Disclosure Agreement. Но мы не просим устройство и средства разработки "на халяву" и готовы их купить. Если Вас такие условия устроят, то можно поговорить о проблемах переноса - прежде всего это механизм передачи сообщений. Для быстрого портирования на новую платформу необходим L4-ABI, поскольку аппаратно он не предусмотрен, то его программная реализация на новом железе - это вполне объёмный и самостоятельный проект. Впрочем, сама идея L4-ABI настолько универсальна, что даже без операционной системы это вполне самодостаточная вещь. Попробую пояснить - если бы мы писали систему не на микроядре L4, а на микрояде Neutrino, то всё равно первоначально понадобилось бы переносить микроядро Neutrino, а уже затем систему. цитата: Реализовать программно MMU, контроллер памяти будет и можно будет до 4 ГБ внешней памяти использовать(предварительно). Т.е. смотря что проще переделать вашу ОС на процессор без MMU или реализовать MMU программно и попробовать работу ОС в полном объёме? Думаю, на данном этапе более оптимальным решением будет программная реализация MMU. Если разрабатывать его наспех, то в результате получится стандартный MMU как и во всех других процессорах - с поддержкой виртуальных страниц фиксированного размера. В таком случае, при реализации L4 Flexpages их придётся эмулировать на основе стандартных страниц. Поэтому лучше сделать программную эмуляцию - при этом возникнет понимание и опыт, необходимые для реализации аппаратных L4 Flexpages. А если по каким-то причинам flexpages не понадобятся, то традиционные виртуальные страницы являются частным случаем flexpages. Отличие flexpages от обычных виртуальных страниц можно увидеть на вложенном рисунке - поле S определяет размер страницы, который равен 2s. Т.е. для привычных страниц размером 4кб значение S будет равно 12. Программный MMU мог бы выглядеть так - несколько байт в TCB зарезервированы под виртуальны и физические адреса нескольких активных страниц. При любом обращении к памяти происходит сравнение адреса, попадает ли он в диапазон текущей страницы, т.е. анализируется начало страницы и её размер. Если нет выхода за границы активной страницы, то происходит трансляция виртуального адреса в физический. Поскольку TCB активной задачи находится во внутренней памяти процессора, то накладные расходы близки к нулю. С учётом больших страниц, мы даже получим выигрыш в скорости по сравнению с 4-х килобайтными страницами - меньше выходов за границы. Если адрес не попадает в диапазон активной страницы, то происходит обращение к таблице страниц и поиск страницы наименьшего размера для трансляции физического адреса. Если соответствия не найдено, т.е. адрес не попал в диапазон таблицы страниц процесса, то происходит аппаратное исключение. Программный анализ таблицы страниц процесса для поиска пары трансляции виртуального адреса в физический я называю "программный MMU". Очень важный момент в различии реализации исключений в традиционных микропроцессорах и в L4 совместимом микропроцессоре. В традиционных микропроцессорах при невозможности транслировать виртуальный адрес в физический, происходит аппаратное прерывание, котрое обрабатывает операционная система. В случае L4 исключение страницы обрабатывается иначе - микроядро посылает сообщение специальному процессу, называемому Pager (обработчик сообщений страниц). Причём, у каждой задачи может быть свой собственный Pager - идентификатор задачи обработчика страниц хранится TCB процесса. Таким образом, помимо регистров общего назначения, включающих счётчик команд и указатель стека (или фрейма вызова, как это сделано в Мультиклете), необходимо добавить регистр, хранящий идентификатор задачи обработчика исключений страниц, и несколько пар трансляции виртуального адреса в физический - одна пара для счётчика команд и две пары трансляции для обращения к данным. На основе этой схемы вполне возожно реализовать программную реализацию обработки исключений страниц (MMU) в стиле L4. Разумеется, следующим шагом будет логично реализовать этот MMU-алгоритм аппаратно со всеми возможными оптимизациями. Возможно это явно не следует из моего поста, поэтому хочу подчеркнуть, что "пользовательский" обработчик страниц (Pager), получает информацию об исключениях страниц посредством фазы приёма сообщений инструкции EXCHANGE_MESSAGE. Таким образом можно создавать очень гибкие системы с различными алгоритмами организации виртуальной памяти. p.s. Даже сейчас я описал менее одной десятой от идеологии и возможностей микроядра L4. К сообщению приложены файлы: 1.png, 736x563, 84Кb

2728. xameleon, 14.06.2013 15:23

цитата: zzeng: У FPages ожидается засада со свопированием. Верно. В текущей версии системы Xameleon своп не поддерживается. цитата: Если я правильно понял, сегмент размером в 513мб будет состоять из двух страниц - 1мб и 512мб. Тоже верно, только сначала идёт страница большего размера, а затем меньшего - так проще выравнивать - т.е. 512 Мб и 1 Мб. Т.е. страница 512 Мб должна размещаться с адреса, кратного 512 Мб. Это обязательное условие и оно всегда выполняется. цитата: Причем залить в своп или прочитать можно только страницу целиком. Прочитать большую страницу займет несколько секунд. Хорошо, если при этом колом стоять будет только один процесс. Наверное так, но есть один момент. Сегмент кода свопировать смысла нет, а даже где-то вредно. Если код программы занимает 513Мб, то с очень большой вероятностью это плохая программа. С трудом могу представить даже статически слинокванную программу, в которой код будем занимать пол гигабайта. В общем, предлагаю отказаться от свопа исполняемого кода. Что касается данных, то вытеснять на диск имеет смысл лишь динамически аллокируеумую память. А теперь вспомиинаем, что в L4 каждый процесс может иметь свой обработчик исключения страниц, посему алгоритм вытеснения памяти на диск можно поместить в user space и держать его в libc. Более того, можно иметь несколько алгоритмов своппинга для разных требований и классов задач. Такие возможности не предоставляет ни одна из существующих систем.

2730. xameleon, 14.06.2013 16:39

цитата: Krufter: Так вот в новый процессор аппаратно сейчас помимо РОНов(8 штук) и Индексных регистров(15 штук) нужно ещё какой-то регистр добавить? Напишите пожалуйста рекомендации что вам нужно в новом Мультиклеточном процессоре. Сразу только могу сказать о регистрах для эмуляции ММU. Чтобы сформулировать остальные пожелания, понадобится некоторое время на повторное и более глубокое изучение процессора - системы команд, способов адресации и т.д. Что касается MMU, то необходима следующая стуктура Старший регистр: | Виртуальный адрес страницы | Размер страницы | Права доступа | Младший регистр: | Физический адрес страницы| При обращении к памяти происходит проверка на попадание адреса обращения к памяти в диапазон, заданный старшим регистром. Если условие удовлетворено, то физический адрес вычисляется по формуле: Физический_адрес = Виртуальный_адрес - Виртуальный_адрес_страницы + Физический_адрес_страницы. Это должна быть аппаратная проверка и подстановка. Чем-то напоминает сегментную модель, за исключением трансляциии физичесого адреса. Таких структур должно быть несколько - одна для выборки команд, и несколько для остальных типов обращений к памяти. Эти регистры должны обновляться при переключении задач. В случае, если при выборке команд адрес не попадает в диапазон текущей страницы кода, или при обрщении к памяти адрес не попадает ни в одну из активных страниц, должен происходить переход на подропрогамму эмуляции MMU. Этой подпрограмме необходимы следующие данные - номер задачи (для выборки таблицы страниц соответствующей задаче), адрес счётчика команд для возобновления исполнения программы, адрес и тип обращения к памяти. Эмулятор MMU ищет соответствие в таблице страниц задачи и если находит, то обновляет соответствующую пару регистров и рестартует исполение команды. Если страница не отображена в адресное пространство задачи, то эмулятор посылает сообщение задаче Pager. Здесь возникает много вопросов и сопутствующих инженерных задач. Например, достаточного ли одной пары трансляции для сегмента кода? Что если тело небольшого цикла будет на границе двух страниц и захватит обе? В этом случае на каждой итерации будет происходить обращение к эмулятору MMU и производительность упадёт в десятки раз. Другая инженерная задача - если держать две пары трансляции для обращения к памяти, то какую из пар обновлять данными новой страницы? Не получится ли так, что каждое обращение к памяти будет затирать нужную пару трансляции. Например: mov ax, [si] mov [di], ax Уже понадобится некоторая эвристика, чтобы сбаланисровать обращение к страницам, на которые указуют регистры SI и DI. Наконец, эмулятору MMU понадобится некоторый механизм для обращения к регистрам задачи, хранящим пары трансляции. Как это реализовать - расширением системы команд или каким либо другим способом? И несколько встречных вопросов - какие инструменты Вы предлагаете для многозадачности, синхронизации задач и обмена сообщениями?

2775. xameleon, 17.06.2013 17:18

цитата: Krufter: Может быть, вы сможете сделать сначала реализацию без всяких MMU? Чтобы влазило в несколько килобайт? Я не уверен, что способен сделать это на энтузиазме. Перечитал "РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ ПО ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ" и "МП MCp0411100101 Руководство по экплуатации". Первое, что пришло в голову - можно лишь использовать некоторые элементы и идеи из микроядра L4. Как сделать полноценнюу реализацию - идей нет. Затруднение вызывает регистровое пространство, общее между четырьмя процессорными блоками. Идея, раскидать задачи между процессорными блоками мне кажется трудноосуществимой неосуществимой как раз из за общего регистрового пространства - во первых, слишком мало регистров на задачу, во вторых, ломается возможность распараллеливания на уровне команд. Таким образом первой и основной задачей мне видится реализация многозадачности, а именно возможность сохранения текущего состояния регистрового пространства в какой либо памяти и загрузка регистрового пространства из памяти. Т.е. распараллеливание на уровне команд это абстракция более низкого уровня и мы её не рассматриваем - она просто работает на другом уровне, не интересном в обсуждаемом контексте. Вот в этом месте, при попытке реализовать многозадачность программно, появляются "грабли" в виде регистра IRETADDR, который доступен только для чтения. Т.е. можно было бы попытаться реализовать многозадачность используя обработчик прерывания, сохраняя в обработчике текущее состояние процессора, затем восстанавливая состояние процессора данными другой задачи, наконец, подменяя значение регистра IRETADDR на адрес другой задачи, тем самым производя переключение задач. Но IRETADDR доступен только для чтения! Переключение задач - базовая возможность, без которой нет смысла говорить о сообщениях, синхронизации задач и прочих вещах.

2777. xameleon, 17.06.2013 17:47

цитата: исчезающий: Согласен. Просто у людей есть иллюзия, что аппаратная защита - это какая-то мистическая серебряная защитная пуля. Но на самом деле, там и железо сложное, и часть операционки этим всем занимающаяся не самая тривиальная, и драйверы могут всё испортить, и т.д. Проблем тоже много. MMU - это страничная организация памяти. При активном выделении/освобжении памяти организуются дырки. В случае страничной организации памяти, всегда можно выделить непрерывный кусок памяти, который собирается из множества кусков (страниц). В случае managed приложений непрерывные блоки памяти точно так же придётся собирать в непрерывные блоки из кусков, только реализовывать это уже придётся программно. А иллюзия у людей в том, что managed код это решение всех проблем. Пока что не видел ни одной системы, ядро которой реализовано на типобезопасных языках. Видел лишь надстройки поверх существующих решений. цитата: Реализаций множество. Есть и таблицы преобразования, ести и подсчёт ссылок, есть и сканирующие сборщики мусора, есть и типизированные по временам жизни переменные (это относительно новый подход, есть такой интересный язык Rust у Mozilla). Наверняка есть ещё методы, о которых мне не известно. Стоит принять во внимание, что подсчёт ссылок это несколько из другой оперы. Этот механизм помогает от утечек памяти и реализован ещё в Component Object Model технологии. Сборщик мусора позволяет снизить латентность программ - блоки памяти лишь помечаются как "готовы для освобождения", а в момент простоя системы или при нехватке ресурсов начинается процесс "сборки мусора".

2786. xameleon, 18.06.2013 17:13

цитата: Krufter: Вы имеете ввиду раскидать задачи по клеткам? Да, я имею в виду именно это. Не могу понять, каким образом можно раскидать задачи по клеткам. И не вижу возможности синхронизации задач между клетками. В случае переключения задач в прерывании - сообщения и синхронизацию можно реализовать программно. цитата: Дак это просто регистр возврата из прерывания. В нём происходит запоминание адреса параграфа на который мы вернёмся. А вернуться мы можем и не по этому регистру а вообще хоть куда если захотим. Я пока не понимаю зачем IRETADDR делать на запись. В новой версии появятся ещё команды связанные с переходами и регистры. Я пытался представить, как можно организовать переключение задач на существующем базисе (на основе документации), поэтому и зацепился за IRETADDR. В идеале, конечно, лучше раскидать задачи по клеткам, но это не отрицает необходимсть переключения задач. Иначе четыре клетки придётся поделить пополам межу системой и пользовательскими задачами - одну на ядро, одну для драйверов устройств и две на пользовательские задачи. цитата: Далеко от Екатеринбурга живёте? Если на автомобиле, то приблизительно 2200 км. В Ростовской области живу.

2826. xameleon, 21.06.2013 17:42

Как бы могла выглядеть закладка в процессоре? Ну, к примеру, в x86 совместимом. Некоторые инструкции процессора не имеют смысла, например сочетание LOCK NOP вызовет аппаратное исключение. А что если встроить проверку и, к примеру, задать определённую достаточно длинную последовательность команд, которая будучи вставленной перед LOCK NOP, не вызовет исключения, а войдёт в некий недокументированный режим. Как воспользоватся такой закладкой? Самое простое - превратить процессор в нагревательный элемент - вместо исполнения кода заставить крутиться в бесполезных бесконечных циклах. Можно что-нибудь закоротить для пущей надёжности - это довольно просто. Гораздо сложнее, я бы даже сказал невозможно, сделать закладку, способную украсть данные или передать управление извне - для этого аппаратная закладка обязана взаимодействовать с программной закладкой. Смысла в такой затее не так уж и много, а сложнось очень высока. Как вариант закладки, вносить искажения - в режиме атаки добавлять случайные коэффициенты к арифметическим операциям - будет веселуха. И немного прозы - http://habrahabr.ru/post/168607/

2861. xameleon, 24.06.2013 15:07

цитата: Boris Usievich: осталось все еще непонятным, с какого бодуна производитель железа начнет заниматься вредительством, а также, как эта мифическая закладка будет отличать своих от чужих :gigi: Это смотря что понимать под термином "закладка". Можно назвать это недокументированной возможностью для отладки.

2922. xameleon, 24.06.2013 22:38

цитата: Ben Laden: А если изнутри - ну так против лома нет приёма. Насчет же приёмников, встроенных прямо в процы - это настолько детская байка, что и обсуждать неинтересно. :-\ Соглашусь в том, что приёмники и антенны на материнской плате это чушь. А вот зря Вы упускаете возможность доступа "изнутри". Можно представить ситуацию, когда достаточно повысить уровень привелегий с "гостя" до "администратора". Я утрирую, но с таким инструментом уборщица или ночной сторож теоретически могут получить доступ к информации, закрытой сильными паролями. Можно на это посмотреть и с другой стороны - сами по себе "теории заговора с закладками" хороши уже тем, что служат стимулом производства "железок" у себя, соответственно дают некоторый шанс производства высокотехнологичной продукции, вместо скатывания до уровня банановой республики. Перефразирую известную поговорку: "Если закладок не существует, то их следует придумать".

2978. xameleon, 25.06.2013 18:39

цитата: matik: AlexDi А вот любой контроллер PCI(e) по самому принципу своей работы может писать в системную память что угодно Вообще-то нет, не всюду, и не что угодно. Так что это, мягко скажем, преувеличение. Судорожно вспомнию спецификацию различного PCI железа и вспоминаю, что же может запретить PCI устройству в режиме Bus Master записать в любую память. Не припоминаю ограничений, но единственной проблемой может быть выравнивание и размер записываемых данных. Что касается "что угодно", то возьмём для примера сетевую карту. Если есть доступ к её регистрам, то можно включить режим loopback и заворачивать обратно передаваемые пакеты. Какой либо дескриптор приёмного буфера можно указать на системную память и рассчитать так, чтобы часть пакета легла в аккурат в нужное место. Задача весьма нетривиальная, но для пытливых умов ничего невозмжного нет - мне это не интересно, Вам это не интересно, а хакеру Васи или хакеру Джону может быть интересно и он сможет этим воспользоваться. Кстати, проблему выравнивания достаточно просто решить, предварительно вычитав весь блок памяти, а затем переписав часть блока памяти, вернуть его назад. Разумеется, это всё досужие домыслы, поскольку не существует известного способа писать в регистры сетевой карты из userspace.

3044. xameleon, 26.06.2013 20:55

Доргой matik, не боитесь проспорить? У меня за плечами опыт написания нескольких драйверов для разных систем, последнее, что припоминается - DEC21140 и Intel8254x. цитата: matik: xameleon Судорожно вспомнию спецификацию различного PCI железа и вспоминаю, что же может запретить PCI устройству в режиме Bus Master записать в любую память Для начала, ни о какой "любой" памяти речи не идет: для PCI (PCI-E) устройств в служебной области памяти (той самой, которую резервирует БИОС при старте системы) выделен определенный пул адресов. Никто не позволит начинать передачи по абсолютно любому адресу. Правильно, это область регистров сетевой карты. Пользовательскому приложению туда писать невозможно. цитата: Далее: само PCI устройство может разбудить систему (передавая заранее условленный сигнал), но НЕ МОЖЕТ выступить инициатором передачи. Кто-то другой (получатель) должен запросить данные. Поэтому про "PCI устройство, произвольным образом перезаписывающее память", можете не рассказывать ;) Только с разрешения инициатора запроса, и только по определенным выделенным адресам. Ну дык, почитайте же, куда пишутся принятые сетевые пакеты и откуда читаются передаваемые сетевые пакеты. В сетевой карте есть регистр, который указывает на таблицу дескрипторов приёмника, которая описывает блоки памяти, в котоорые происходит приём пакетов. Так же в сетевой карте есть регистр, который указывает на таблицу дескрипторов передатчика, которые указывают на блоки памяти, откуда сетевая карта выбирает передаваемые пакеты. Обе таблицы находятся в оперативной памяти, соответственно, в случае наличия прав доступа к регистровому пространству сетевой карты, можно подсунуть любые таблицы дескрипторов. Стоит ли упоминать, что буфера, на которые указывают дескрипторы, могут распологаться по любому (выровненному) адресу в пределах разрядности шины адреса? цитата: Если есть доступ к её регистрам Доступ, который в общем случае невозможно получить из произвольной программы. Если у Вас есть доступ к регистрам чипсета \ процессора \ контроллера памяти, Вы можете запрограммировать что угодно. Я об этом сразу честно сказал. цитата: Но как Вы получите этот доступ - Ваш рассказ умалчивает. А зря, это самое интересное. Такой способ мне неизвестен. Скорее всего такого способа вовсе не существует. цитата: Так вот, чтобы активировать аппаратную закладку таким образом, у Вас УЖЕ должен быть доступ, который и так позволяет сделать с машиной что угодно. Если такой доступ есть - закладка не нужна. Закладка бы пригодилась, чтобы получить доступ к управлению устройствами на PCI шине из пользовательской задачи. Причем, даже свой обработчик прерывания не нужен - вполне достаточно было бы читать статусные регистры в цикле. (На самом деле я ненавижу опросы в цикле, но мы же говорим о гипотетической возможности распоряжаться памятью из userspace) цитата: Какой либо дескриптор приёмного буфера можно указать на системную память и рассчитать так, чтобы часть пакета легла в аккурат в нужное место. Это совсем фантастика. Если Вы не являетесь диспетчером виртуальной памяти операционной системы, Вы не знаете, какому конкретному физическому адресу соответствует виртуальный адрес. А если Вы диспетчер виртуальной памяти - Вы и так можете сделать что угодно, закладка не нужна. С этим утверждением не буду спорить, поскольку в целом оно верное, но если кому-то дать инструмент с помощью которого легко и безнаказанно читать/писать любой регион доступной физической памяти, то есть ненулевая вероятность, что этот "кто-то" вполне сможет воспользоваться этой возможностью. Кстати, при таком раскладе не спасёт программное обеспечение с открытым кодом, поскольку даже верифицированное и сертифицированное ядро не смогло бы противостоять таким атакам.

3050. xameleon, 26.06.2013 21:22

цитата: KT: xameleon Вопрос: что может помешать сетевому устройству по собственной инициативе считать физическую память по произвольному адресу? Я не знаю ответ на этот вопрос. Возможно, репутация разработчиков?

3053. xameleon, 26.06.2013 21:30

цитата: KT: xameleon Вопрос был - есть ли для этого какие-то механизмы в протоколах шин PCI(-Express)? Скажем, IOMMU... (я бы хотел не касаться здесь вопроса закладок и пр. Чисто технически, каковы возможности у произвольного PCI(-Ex) устройства?) Скажу честно - не знаю. Я так глубоко не копал.

3140. xameleon, 28.06.2013 12:12

цитата: vss: Это вопрос типа того, почему монолитное ядро ОС, а не микрокернел. Потому, что иначе неэффективно. Ну вот с чего бы это микроядро неэффективно? Потому что так Торвальдс сказал?

3146. xameleon, 28.06.2013 13:16

Кстати, как сторонникам, таки противникам возможности наличия закладок, предлагаю почитать эту сказку - http://lib.ru/INOFANT/BISHOF/wargames.txt Фантастика полная, но чертовски интересно написана и сюжет хороший. Про мальчика, который влез в Сеть Пентагона и чуть было не начал тотальную атомную войну. Что касается ведомственных сетей, то хоть они и не подключены к интернету, но всё равно это компьютерные сети. Наверняка большинство из них основано на протоколе X.25. Те, что поновее, скорее всего используют Frame Relay, а самые старые качают данные на чём либо вроде v32bis. Похоже, такие сети лучше защищены от атак со стороны, поскольку в общем случае создают лишь "тупой" виртуальный канал между двумя точками. В порядке стёба можно рассмотреть возможность закладок в коммуникационном оборудовании. Около 15 лет наззад мне довелось пользовать (не адмиистрировать) X.25 маршрутизатор. Было очень забавно вводить случайные адреса и коннектится к различным ведомственным серверам. Разумеется дальше логина пробраться не доводилось, да и цели такой не было, но было реально интересно. Правда, в случае чего и по рукам (и по голове) могли надавать.

3148. xameleon, 28.06.2013 13:36

цитата: Boris Usievich: xameleon Ну вот с чего бы это микроядро неэффективно? Потому что уже пробовали, результат не понравился :) Уже 10 раз обсуждали. :) Результат не понравился тем, кто пытался тупо переложить монолитный подход на микроядро, тем самым создавая лишний уровень абстракции. Кстати, вот есть такое субъективное мнение, почему QNX не пошёл на десктопы - отличный дизайн и реализация ядра, но графическую подсистему писали "в лоб". Последний раз я смотрел на QNX очень очень давно - впечатление, что GUI делали топором на коленке. И дело было не во внешнем виде, а в очень неоптимальной отрисовке виджетов. Это было первое и сильное впечатление, с тех пор больше никогда не смотрел на QNX. Может быть сейчас всё поправилось.

3155. xameleon, 28.06.2013 13:51

цитата: vss: Потому, что для того, чтобы его опровергнуть, надо сделать эффективную ОС на микроядре. Как это сделать, если изолировать модули ядра ОС техникой отдельного адресного пространства, не очень понятно. Как по мне, то разнесение модулей ядра по разным адресным пространствам, это интересная, но не обязательная возможность микроядра. С моей точки зрения, методика взаимодействия модулей через сообщения более важная и характерная особенность микроядер. А когда мы взаимодействуем через сообщения, то где находятся модули - в едином адресном пространстве или в различных, это уже вопрос второстепенный. Например, как вариант - решение о том, в каком адресном пространстве исполнять сервис файловой системы, может принять администратор, явно указав тип запуска в конфигурционном файле.

3199. xameleon, 28.06.2013 17:39

цитата: vss: Если модули взаимодействуют через сообщения, но находятся в одном адресном пространстве, они могут взаимодействовать и не через сообщения. Вопрос не в том, какой способ взаимодействия удобней или эффективней. Вопрос в том, как исключить иные, не рекомендуемые и ошибочные способы взаимодействия. А вот и не согласен. Это именно тот путь, по которому идут 90% разработчиков - меняют системные вызовы на сообщения и получают те же самые проблемы, что и в монолите, только отягощённые ещё лишним слоем в виде сообщений. В случае микроядра необходимо переосмыслить способ обслуживания системных вызовов. Попробую пояснить на простом примере. Вот, мы смотрим статистику процессов в монолитной системе и видим у каждого процесса два параметра - сколько он использовал времени в User Space и сколько времени в Kernel Space. Т.е. обслуживание системных вызовов в монолитной системе есть в некотором роде продолжение пользовательского процесса в режиме ядра системы. В то же время различные системные вызовы, порождённые пользовательскими процессами, продолжают конкурировать в контексте ядра. В случае же микроядра, ядро системы это один или несколько процессов, которые в общем случае можно сделать единственными для всех пользовательских задач. Т.е. понятие Kernel Time это время системнго процесса, обслуживающего определённую категорию системных вызовов. Иными сломами, у пользовательских процессов нет понятия времени, проведённого в контексте ядра. Вместо него используется понятие времени проведённого _всеми_ процессами в модуле, обслуживающем вызовы файловой системы, точно так же есть понятие времени, проведённого всеми процессами в модуле, обслуживающем сетевые функции, и т.д. по аналогии. Вот в этом месте сразу возникает проблема блокировки пользовательских процессов, стоящих в очереди на выполнение. В монолитах такой проблемы нет, поскольку процессы продолжают конкурировать в контексте ядра - если какой-то процесс ждёт данные или событие, то его время отдаётся соседу, данные для которого могут уже лежать в кэше. Именно в этом моменте микроядра упираются в свою эффективность и каждый разработчик решает эту проблему по-своему. Многие разработчики идут по пути создания на каждый пользовательский процесс ещё один процесс в контесте ядра, а уже в ядре работают так же, как если бы это была монолитная система. Профит отрицательный - микроядро при таком раскладе только жрёт ресурсы и при том не даёт никаких явных преимуществ. Чтобы получить преимущества от микроядра, необходимо все системные вызовы одной категории обслуживать в одном потоке, а в случае блокировки сохранять состояние вызова и переходить к обслуживанию следующего. В случае снятия блокировки любого из предыдущих системных вызовов, мы об этом узнаем в одном из двух случаев - в случае завершения или блокировки текущего вызова. В случае снятия блокировки, восстанавливаем состояние и выполняем вызов до завершения или следующей блокировки. Таким образом эффективность микроядра зависит во многом от организации обслуживания вызовов. Я не буду подсказывать, но есть способы очень эффективно сохранять и восстанавливать состояние текущего вызова - он настолько прост, что тот, кто поймёт способ, будет уверен что он всегда это знал или сам придумал. ;) Добавление от 28.06.2013 17:46: цитата: Wizardry VII: Как-то на сайте "compression.ru" была похожая ситуация. Один паренек с Израиля долго выпытывал про один наш метод предобработки данных для сжатия. Наши вислоухие дурачки помогли как могли. А после выяснилось, что он уже патентует чужую разработку Надеюсь, это был упаковщик Алексея Бабушкина? А если серьёзно, то какая к чёрту разница, откуда человек? Хорошую разработку любой может украсть, т.ч. пора самим научиться секреты фильтровать.

3397. xameleon, 02.07.2013 21:43

цитата: vss: цитата: В случае микроядра необходимо переосмыслить способ обслуживания системных вызовов. Это да, но в первую очередь надо обеспечить, чтобы помимо официальных системных вызовов нельзя было войти в модуль ОС просто передав туда управление по адресу. Сам принцип передачи сообщений располагает к надёжности - задачи могут быть изолированы различными аппаратными способами - сегментам, страницами, задачи даже могут быть разнесены на различные исполнительные устройства, но при этом все задачи взаимойдествуют исключительно через обмен сообщениями. Других точек входа в модуль может просто не быть. цитата: Нужно защищать память внутренностей модуля от произвольных туда обращений, и одновременно надо при передаче управления модулю делать его память доступной модулю быстро. Вот именно поэтому процессоры без MMU не выдерживают конкуренции. Можно сделать быстро, используя общую память и указатели, при этом не использовать защиту памяти вообще. Можно сделать медленно, копируя блоки памяти между изолированными процессами. С учётом требований к защите, которую Вы ставите во главу угла, отображение страницы из адресного пространства вызывающего процесса в адресное пространство вызываемого процесса, будет самой быстрой защищенной операцией, не требующей копирования. А по другому - наверное никак. По большому счёту, проблемы изоляции процессов универсальны, только микроядра предоставляют более гибкие и широкие возможности. цитата: А вопросы планирования вычислений, приоритеты и тому подобное - это все важно, но это другое. Защита памяти - это обеспечение семантики вычислений, их правильности, планирование времени - это обеспечение производительности. Производительности и уменьшения энергопотрбления и тепловыделения. :) цитата: Обычно учат сначала действовать правильно, потом - то же, но быстро. Это традиционный способ воспитания навыков. Конечно, бывают случаи, когда правильно - это обязательно достаточно быстро, но давайте начнем с простого. Если защищённо, медленно и без MMU, то остаётся сегментная адресация, но при этом придётся копировать данные между сегментами. Или расшаривать некоторые сегменты между несколькими процессами. При этом сегменты будут похожи на "универсальные виртуальные страницы" - тот же MMU, только программный.. Опять же, в пользу микроядер - правильные микроядра предоставляют абстракцию адресных пространств, скрывая детали реализации. С помощью концепции адресных пространств можно сделать мощную и гибкую модель защиты памяти. Не только модули ядра защищены от прикладных задач, но и прикладные задачи могут быть защищены от модулей ядра. Наконец, аргумент надёжности мироядер по сравнению с монолитом никто не оспаривает - изначально, когда пошла первая волны моды на микроядра, сторонники микроядер использовали надёжность как аргумент против быстродействия, которое противопоставляли сторонники монолита. Но я хочу сказать, что с помощью механизма сообщений можно реализовать более оптимальную и равномерную загрузку процессоров, а так же уменьшить количество переключений контекста, по сравнению с монолитными ядрами.

3408. xameleon, 03.07.2013 04:49

цитата: pui_i: цитата: xameleon: Вот именно поэтому процессоры без MMU не выдерживают конкуренции. Можно сделать быстро, используя общую память и указатели, при этом не использовать защиту памяти вообще. Можно сделать медленно, копируя блоки памяти между изолированными процессами. Есть давно SIP и не нужно ни какое копирование. Вы замкнулись в своем L4. Да ну? Возможно, я отстал от жизни. Какой-такой SIP? Неужели компьютерная революция мимо прошла? Давайте подробности.

3436. xameleon, 03.07.2013 20:55

цитата: pui_i: цитата: xameleon: Да ну? Возможно, я отстал от жизни. Какой-такой SIP? Неужели компьютерная революция мимо прошла? Давайте подробности. http://en.wikipedia.org/wiki/Singularity_(operating_…)#Security_design Singularity почти целиком поместится в один процесс L4. То есть в одну пользовательскую задачу, состоящую из одного адресного пространства и нескольских сотен или тысяч нитей исполнения. Кто-то считает это преимуществом Singularity, но есть мнение, что это преимущество микроядра L4. Добавление от 03.07.2013 21:05: цитата: pui_i: ничего не понял. если речь идет о модификации бинарника, то ОС может проверить свои контрольные суммы, как это делает хром ОС, например. Я тут не вижу отличия ОС с управляемым кодом от обычной ОС. На управляемом коде вирусы писать значительно сложнее, если вообще возможно. "Хром ОС"? Это такой навороченный процесс init над ядром Linux?

3440. xameleon, 04.07.2013 01:28

цитата: pui_i: Singularity (или подобные ей) может поместится в процесс любой современной ОС, L4 то здесь вообще причем? Собственно ниже VM, в том или ином виде обычная ОС, но ее подсистемы тесно интегрированы с VM. Потому что L4 это минимальная прослойка между железом и виртуальной машиной. цитата: Речь выше шла о безопасности памяти, на что я ответил что все решается SIP которому не нужны штуки вроде MMU. А виртуальная машина может работать на системе без MMU? Да даже если и так, давайте сравним способы синхронизации и обмена сообщениями в L4 и Singularity? цитата: Если линукс и mach - это позавчерашний день, то L4 всего лишь вчерашний. У Вас календарь испорчен - микроядро L4 намедни в кристалл просилось.

3443. xameleon, 04.07.2013 05:34

цитата: pui_i: цитата: xameleon: Потому что L4 это минимальная прослойка между железом и виртуальной машиной. Достаточно бесполезная прослойка. Можно под это прослойкой что-то запустить, можно убить, можно квотировать ресурсы ну и все собственно. Это может любая ОС из 70-80-х. Любая? Не любая. MS-DOS нативно не умел многозадачности/многопоточности. RT-11 умел только с версии RT-11TS. цитата: Да еще и весь трафик сообщений между программами идет через ядро, а не напрямую. Контроль на более низком уровне отсутствует. Зачем так жить пацаны? Если в L4 несколько программ выполняются в едином адресном пространстве, то при передаче сообщения переключения контекста не происходит. В случае аппаратного L4 всё ещё более просто - буфер сообщения коммутируется от одной задачи к другой задаче, если задачи выполняются на разных ядрах, а если на одном, то перегружаются регистры общего назначения, а блок сообщений не перегружается. цитата: цитата: Да даже если и так, давайте сравним способы синхронизации и обмена сообщениями в L4 и Singularity? Сообщения делаются очень просто, через расшаренную память, в юзер спейсе. Это еще один бесплатный бенефит от управляемой памяти. А в юзер спейсе они всяко быстрее чем в ядре, даже если это L4. А тут ничего революционного нет - в соообщении L4 точно так же можно использовать расшаренную память и перекидываться указателями. А если понадобятся Software Isolated Processes, то вместо указателей можно обмениваться дескрипторами, описывающие структуры и блоки памяти. Только... сдаётся мне, что при большой фрагментации памяти, поддержка неперывных блоков управляемой памяти потребует больше процессорного времени, чем страничная организция памяти. цитата: цитата: У Вас календарь испорчен - микроядро L4 намедни в кристалл просилось. Да нет все правильно написано, особенно в контексте затрагиваемой "безопасности". Безопасность L4 по сравнению с управляемыми средами - детский лепет. Это разные типы безопасности и одна не исключает другой. Безопасность L4 основана на понятии адресных пространств, безопасность SIP достигается за счёт управляемого кода. Теоретически ничто не мешает запустить управляемую среду поверх микроядра. цитата: В гипотетическом управляемой среде, можно например, запретить программе складывать числа, просто включив эксклюзивную VM для это программы без этого опкода. Я уже не говорю о каком нибудь отказе функционала вроде доступа к файлам. Можно делать вообще все что угодно. На сколько только хватит фантазии. Насчёт возможности выключения опкода в VM не спорю, но аргумент с файловой системой неудачный - управляемый код в данном случае не даёт никаких преимуществ. цитата: В кристалл запихивать механизмы ОС - бесполезная трата ресурсов, также как и запихать VM. Это философский вопрос. С таким же успехом я могу заявить, что выполнение кода в программной виртуальной машине - бесполезная трата электроэнергии. Но я не буду столь категоричен. Кстати, x86 Task State Segment и инструкция "lock cmpxchg" это тоже в некотром роде механизмы ОС на кристалле, но весьма примитивные.

3606. xameleon, 09.07.2013 16:16

цитата: Leka: В прошлом году вот такую несложную программу, например, пробовал компилировать в нетлист для FPGA, см ниже. Программа на Паскале - эмулятор PDP-11, RT11SJ V05.04G загружает без ошибок. Неужели в 227 строчек поместился эмулятор 1801ВМ1? К сообщению приложены файлы: 1.jpg, 400x473, 82Кb

3621. xameleon, 11.07.2013 13:47

цитата: Leka: RT-11SJ определяет "LSI 11 or PDP 11/03 Processor" Угу. Например у меня RT-11SJ сильно ассоциируется с ДВК-2 и пятидюймовыми дискетами. А в ДВК как раз стоял К1801ВМ1, по системе команд совместимый с PDP 11/03. цитата: Мне достаточно было, чтобы загружалась RT-11SJ и выполнялись основные системные программы, включая компиляторы. А как Вы реализовали устройства ввода/вывода?

3629. xameleon, 12.07.2013 12:49

цитата: kayleth: Операционка есть, Офис есть, специальный софт портируют (у них вообще часто управление и доступ через WEB-интерфейс) Это какая такая операционка есть у Эльбруса?

3633. xameleon, 12.07.2013 14:43

На мой скромный взгляд, никто не сможет сказать о "русских линуксах" лучше автора сего произведения: http://ilibrary.ru/text/986/p.12/index.html

3651. xameleon, 15.07.2013 20:04

цитата: vss: Дело не только в портировании Линукса на Эльбрус, но и в доработках под реальное время и в доработках по средствам защиты от несанкционированного доступа. Гарантированный реалтайм можно получить лишь запустив ядро Линукса под каким либо планировщиком как задачу с наименьшим приоритетом. Только в этом случае конкурирующие с линуксом задачи будут realtime, а само ядро к режиму реального времени не очень располагает. Расширенные средства защиты от несанкционированного доступа - Access Control List. Я бы даже сказал "POSIX Access Control Lists".

3666. xameleon, 16.07.2013 16:20

цитата: Valeriy Shunkov: Есть подозрение, что весь цивилизованный мир при необходимости работать в реальном времени не просто так использует VxWorks, а не допиленные линуксах. Если ничего не случится, то может быть через год или два я покажу кое-что, что может оказаться не менее интересным, чем VxWorks. А может быть и не покажу. Есть намерение написать на Verilog свой микропроцессор с поддержкой аппаратных синхронных сообщений и многозадачности. Модифицировать какой-либо существующий микропроцессор с открытым исходным кодом не интересно, но интересна своя собственная система команд. Для процессора нужен компилятор, иначе процессор гарантированно не будет никому интересн. Если уж делать новый процессор, то логично делать к нему и компилятор. Если кто-то не осилит написание компилятора, то создание процессора уж и подавно. Можно взять готовый компилятор и дописать к нему генерацию кода для новой системы команд. А можно попробовать написать компилятор "с нуля". В общем, получается пока так: http://l4os.ru/download/compare/regenerated.html Так что, господа, если затея с компилятором выгорит, то я подкину вам пищу для обсуждений. За это сообщение сказали спасибо: vss

3673. xameleon, 17.07.2013 00:22

цитата: Ратибор Алиен: будьте проще и народ к вам потянется (с) Сергей Вакуленко (нонче работает на МИПС) написал стройную операционку для микроконтроллеров, в том числе и наших, полувоенных. http://code.google.com/p/uos-embedded/ Кроме того, джаст фо фан запилил bsd2.11 для старших микроконтроллеров PIC32 (128 КИЛОбайт оперативки и MPU) http://retrobsd.org Угу. А ещё Сергей Вакуленко давным давно написал Demos Commander, который работает на любых юниксах и даже под ДОС. Более того - несколько лет назад deco запустился даже поверх микрояда L4. (с небольшой posix прослойкой:) Не понял Вашего наезда. Я подписан на "Живой Журнал" Сергея Вакуленко, регулярно читаю и иногда комментирую. Вроде бы в курсе всех новостей. Что Вас смутило в моём комментарии?

3675. xameleon, 17.07.2013 00:42

Ратибор Алиен Ну я же не прошу у Вас денег, так какая Вам разница?

3908. xameleon, 24.07.2013 13:58

цитата: bess: документ Интела по будущему расширению AVX-512 http://download-software.intel.com/sites/default/files/319433-015.pdf Бедный бедный Intel - скоро длина некоторых инструкций будет сопоставима с размером подпрограмм, выполняющих аналогичную функциональность. Однако, я полностью согласен с Вами, что сокрытие описания системы команд Эльбруса - это неправильно. Вот вопрос к тем, кто утверждает, что знание системы команд не нужно: если компиляторы такие умные, то почему в коде ядра Linux столь много ассемблерных всавок?

3911. xameleon, 24.07.2013 14:31

цитата: ПростоЗашёл: Они всегда были умными или ядро должно полностью переписываться заново или может программисты должны в принципе бесконечно переписывать работающий код? Никакой революции в компиляторах/оптимизации Си кода за последние 20 лет я не заметил. Эволюция - да, была. Пассаж о бесконечном перепесывании исходного кода я не понял. Наоборот, с усовершествованием процессоров некоторые инструкции можно заменить другими, более оптимальными. Т.ч. Ваш аргумент о "бесконечном переписывании" исходного кода говорит против использования директивы asm в Си коде, но тем не менеее - ассемблерные вставки активно испльзуются в коде ядра Linux. Опять же, практически любой современный С/C++ компилятор умеет генерировать ассемблерный код - ключ /Fa для MS Visual C, ключ -S для gcc. Будет очень удивительно, если тщательно скрываемый компилятор для Эльбруса не умеет генерировать ассемблерный код.

3927. xameleon, 26.07.2013 20:16

цитата: vss: 1. Работа с регистрами - конфигурирование аппаратуры. В языке С просто нет конструкций для этого. Трудно возразить. Только работа с аппаратуртой через регистры c помощью in/out практически ушла в прошлое. Современное оборудование отображает порты устройств на шину адреса. К портам большинства современных устройств можно обращаться через указатели. цитата: 2. Ядро ОС не использует стандартные библиотеки. Это ядро Linux не использует стандартные библиотеки, а на какой-нибудь микроядерной операционной системе такое вполне возможно. В любом случае - стандартные библиотеки завязаны не только на систему команд, но и на ядро. Например, чтобы реализовать библиотечную функцию код: int pthread_mutex_lock (pthread_mutex_t *mutex); - понадобится знание ассемблера, поскольку реализация архитектурно зависима. В то же время понадобится знание системных вызовов ядра, чтобы отдать ему время, проведённое в блокировке. цитата: vss: 2. Технический. Необходимость знать систему команд в том объеме, в каком ее надо знать для разработки системы программирования. Даже при написании прикладных программ необходимо знать систему команд. Это очень помогает в разработке, оптимизации и в отлове ошибок. В этом bess на 100% прав.

4195. xameleon, 02.08.2013 00:27

цитата: kayleth: 2. 64 бит- скорее всего нет, иначе бы "раструбили во все трубы". Молчат, значит пока ограничились старой, но проверенной схемой/ кодом (VHDL) Intel IA-32 (x86) Структура модуля МВ3S1/C (http://www.mcst.ru/mb3s.shtml) L4Ka::Pistachio/x86-x32 (http://www.l4ka.org/94.php) на нём запустится?

4197. xameleon, 02.08.2013 00:51

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

4200. xameleon, 02.08.2013 04:03

цитата: Кое-кто: Ах, Майкрософт наше все. Что там особо функционального использует рядовой пользователь в Ворде? Если пользователь не может набирать в редакторе vi документ в формате TeX, то ничего удобнее MS Word для него ещё не придумали. Продвинутый рядовой пользователь может использовать стили, создать оглавление, проверить правописание, пронумеровать страницы, создать колонтитулы, вставить картинку. Если "пользователь" не в состоянии выполнить эти операции, то офис не для него - стране нужны рабочие руки. OpenOffice хорош тем, что его код открытый и тем, что собирается практически под любую платформу. Но эта мультиплатформенность имеет и обратную сторону - большое количество зависимостей и требуемых библиотек. Например, если заглянуть репозиторий проекта (https://svn.apache.org/repos/asf/openoffice/trunk/main/), можно ужаснуться от огромного количества зависимостей. Навскидку - boost, cairo, i18n и т.д. И весь этот зоопарк работает тормознее MS Office. Я не хочу сказать, что все эти библиотеки неоптимально написаны, но кроссплатформенность требует дополнительного слоя абстракции от API системы, а дополнительный слой это бОльшие накладные расходы. Наконец, если мы говорим об Эльбрусах, то подразумеваем Linux, а это значит, что офисное ПО исполняется поверх X Window System, которая, как ни крути, в силу архитектурных особенностей более медленная чем Windows GDI. Ну и собственно пример проблемы с OpenOffice, который наверняка поставит в тупик рядового пользователя: http://web.archiveorange.com/archive/v/hhSc5KOL1h5nLH2zQkJE

4213. xameleon, 02.08.2013 14:59

kayleth, таки Pistachio x86-32 запустится на МВ3S1/C или нет? Если запустится, то дайте две. Это принципиальный вопрос.

4548. xameleon, 03.09.2013 03:28

Ох уж эти FPGA. Недавно приобрёл плату Марсоход-2 (http://marsohod.org/index.php/howtostart/marsohod2) в надежде сделать ещё один "Отечественный микропроцессор" Мечты ударились о суровую реальность - "команду за один такт" можно сделать используя RISC, а вот CISC уже необходимо реализовать через конечные автоматы (state machines), что рушит идею выполнять команду за такт. Пайплайны и хитрые конвееры тоже (пока) не получились - 10320 логических элементов и отсутствие знаний и опыта программирования на Verilog не позволяют реализовать задуманное. Ежели кто из уважаемых участников конференции готов безвозмездно помочь советами или даже поучаствовать в создании ещё одного ни-с-кем-не-совместимого "отечественного микропроцессора", то дайте знать. Раз уж отвечаю в эту тему, то пользуясь случаем хочу задать вопрос: "Имеет ли смысл регистры "Счётчик команд", "Указатель стека" и "Регистр флагов" помещать в общее регистровое пространство?" Т.е. решил я адресовать регистр 4-мя битами - получились регистры от R0 до R15. Первая идея была такая: R15 -Instruction Pointer, R14 - Stack Pointer, R13 - Flags. Но потом эта идея перестала нравиться - во первых, если разместить их отдельно, то будет на три регистра общего назначения больше, во вторых, обращение к регистрам флагов, IP и SP, помещенных в общий регистровый файл - на Verilog это выглядит не очень красиво и не оптимально. Ещё плюсы в том, что команды переходов вырождаются в операции MOV и ADD, а флагамии можно управлять операциями OR и AND. Но появляются и бессмысленные комбинации, типа использования регистра флагов или счётчика команд в оперции сдвига - то, что не может пригодиться в принципе. С другой стороны - общее число регистров ну просто обязано быть степенью двойки, потому что это решает множество проблем. Ну и как быть? Как бы вы реализовали эти регистры?

4747. xameleon, 20.09.2013 14:52

цитата: Felid: А в космосе в это время спутники поджидает кое-что похуже Солнца: Проект «Во́яджер» как бы опровергает это утверждение. Вроде бы связь с аппаратами до сих пор сохранилась? Это ли не чудо? цитата: выход из строя одной из ячеек оперативной памяти бортовой ЭВМ — программу удалось переписать и загрузить так, что этот бит перестал влиять на программу;

4824. xameleon, 23.09.2013 15:42

цитата: matik: Какой будет длина кодированной последовательности, чтобы не было случайного срабатывания? Вполне можно уложиться в 16 байт. Дело в том, что эта последовательность не просто должна появиться на шине данных, а должна быть подмешана в инструкции. Для этого достаточно взять любую из несуществующих инструкций, которые вызывают исключение "неправильный код команды", и задержать это исключение до следующего байта. Далее задерживать исключение до конца последовательности. Вряд ли кто-то будет разбираться, почему исключение пришло на такт или несколько тактов позже. Вероятность случайного срабатывания близка к нулю. Для пущей надёжности можно включать детектор последовательности только при определённом состоянии флагов Z,C,O,D. Заметьте, я не рассуждал о том, каким образом эта последовательность попадёт в исполняемый файл и что должно произойти после активации последовательности, а лишь ответил на вопрос о длине последовательности. Более того, вроде бы современные процессоры имеют микрокод, который якобы можно перепрошить. Почему-то никто не боится, что в исполняемом коде случайно встретится последовательность, которая включит режим обновления микрокода. И вообще, "закладки", это жупел, который просто необходим некоторым людям, которые не понимают, что отечественную микроэлектронику необходимо развивать. Не каждому дано понять, какова пропасть между лидерами отрасли и российскими разработчиками. Зато угроза "закладок" понятна нетехническим специалистам. Повторюсь: "если закладок нет, то их необходимо придумать".

4830. xameleon, 23.09.2013 16:23

цитата: Boris Usievich: видимо потому что из user mode это невозможно Да, мой промах. Сначала написал, а потом уже осознал. Но это не отменяет факт, что 16 байт будет достаточно для практически недоказуемой активации чего-нить эдакого скрытого.

4839. xameleon, 23.09.2013 17:18

цитата: Boris Usievich: если производитель процессора зачем-то захочет это сделать. Ибо никакого способа передать эти 16 байт кроме как внедрить свою софтину попросту не существует. А нужна ли аппаратная "закладка", если есть доступ к софту? В качестве возможного сценария - получить привелегии администратора через какой-нибудь пасьянс или "злых птичек". Фишка в том, что такую дыру никакими обновлениями системы не закрыть, а обнаружить на порядки сложнее, чем дыру в софте. Но если рассудить, то в сетевую карту поместить закладку более целесообразно, чем в процессор.

4877. xameleon, 25.09.2013 16:53

Дилетантский вопрос про радиационную стойкость. Если поместить чип под излучение и он даст сбои, то восстановится ли его работоспособность после прекращения излучения?

4927. xameleon, 26.09.2013 14:50

цитата: matik: А Вашу закладку можно встроить только в ЯДРО процессора, после декодера (или в него). До этого момента чип не знает, как данные делятся на инструкции и собственно данные. Именно это я и имел в виду. О других способах закладок я рассуждать не буду, поскольку слаб в электронике. цитата: Для этого достаточно взять любую из несуществующих инструкций, которые вызывают исключение "неправильный код команды", и задержать это исключение до следующего байта. Далее задерживать исключение до конца последовательности. Вряд ли кто-то будет разбираться, почему исключение пришло на такт или несколько тактов позже. Вероятность случайного срабатывания близка к нулю. Не, это все эротические фантазии, и так не сработает :) Сами подумайте, почему. Не представляю. Пусть несуществующая команда займёт пять байт. И ещё одинадцать байт для защиты от случайного срабатывания. 2 в степени 88 весьма большое число. Вероятность случайного срабатывания равна 1 / 485 009 821 345 068 724 781 056. С учётом того, что вся последовательность может оказаться в кэше, то задержки исключения может и не быть. Единственной видимой реакцией на хитрую последовательность может быть лишь отсутствие исключения по неправильной команде. А результатом успешного детектирования последовательности - повышение привелегий userspace задачи. Хочу обратить внимание - я не утверждаю, что такая закладка существует. Я лишь рассуждаю, как бы реализовывал закладку, если бы такую задачу поставили передо мной. :) цитата: Вы не ответили, Вы ПРИДУМАЛИ, что "16 байт будет достаточно". Причем ни единого доказательства этого утверждения нет. Да и обещанная закладка в питании чипа так работать не сможет. Выше описал. В аналоговой части и radio-frequency мои познания чуть более чем ничего. цитата: Извините, но спор "нужно ли врать ради благих целей" давно решен. А Вы предлагаете именно этот, давно навязший софизм. НЕТ, даже благая цель "поддержать отечественные разработки" НЕ является основанием для вранья про закладки. НЕ РАБОТАЕТ это. Ну может быть кто-то и врёт, а я лишь допускаю такую возможность. Это как в гостиницах, где у горничных есть универсальный ключ от всех дверей. :) цитата: Если пилить деньги под вранье про электронику - то зачем при этом кормить электронщиков? На бумаге можно что угодно написать. В том числе про успехи отечественной электроники. Камень в огород МЦСТ? Я бы с удовольствием продолжил этот разговор, но сказать больше нечего. Ну разве что в очередной раз крикнуть, что будущее за процессорами с аппаратной поддержкой микроядер. :)

4930. xameleon, 26.09.2013 14:59

цитата: C.A.R.C.A.S.S.: или вот тут http://habrahabr.ru/post/156049/ Все зависит от степени облучения: мощность, время. В результате проявляются временные ошибки (Soft Error, нарушением логики) и постоянные ошибки (Hard Error, нарушение физики) Спасибо. Выше кто-то сказал, что данные от спутников "Вояджер" (как и высадка человека на Луне) это фейк. Не буду спорить, а лишьь поинтересуюсь - советская программа «Венера» и данные переданные с этой планеты - тоже фейк? И если не фейк, почему космическим аппаратам 40 летней давности не помешали излучения Солнца и звёзд?

4949. xameleon, 26.09.2013 19:13

цитата: nenin:Ну а самые первые спутники были на лампах. :) В принципе, и сейчас ничто не мешает вынести сторожевой таймер в отдельное устройство и реализовать его на лампах. Схема будет не очень сложная - периодически через какое-то количество тактов должен прийти фронт сторожевого сигнала, а затем спад этого сигнала. Разумеется, формировать сторожевой сигнал должна полупорводниковая микросхема. Программно. Что будет означать её работоспособность. Если сторожевой сигнал не пришёл, то обрубается питание полупроводниковой системы, задержка, включение питания, устанавка сигнала сброса, задержка, сброс сигнала сброса. Наверное несколькими десятками радиоламп можно обойтись. Вот только энергопотребление такой схемы будет велико.

4986. xameleon, 27.09.2013 16:22

А вот скажите, уважаемые, какие есть способы превратить IP core в микросхему? Если вдруг доделаю прототип процессора с поддержкой микроядра и на руках будет его Verilog код и софт-модель на языке Си, моделирующая поведение этого процессора, что делать дальше? Вот лично вы, участники этой темы, готовы будете потратить своё время на ознакомление или даже каким-то образом поддержать проект?

4993. xameleon, 27.09.2013 20:09

цитата: Leka: А компилятор? Пока от компилятора только лексический анализатор и ~85% процентов от синтаксического анализатора языка Си.

5020. xameleon, 03.10.2013 14:32

цитата: KT: А ещё нужен софт (ядро ОС, дистрибутив, и прочая), БИОС (под Ваш проект, возможно, его нужно будет подрихтовывать)... Предложите маленьким компаниям следующее Образ какого-либо Линукса для VirtualBox с кросс-компилятором под нативную систему команд Эльбруса Удалённый shell через ssh на систему с процесссором Эльбрус. Сделайте вменяемую цену на эти продукты/сервисы - люди к вам потянутся. Пофит!

5022. xameleon, 03.10.2013 14:52

цитата: KT: как организовать. Но: только на нашей территории, и если будет понятна методика. Машины давать на дом не можем, своим не хватает :(. Какая территория? ssh elbrus1.mcst.ru и вперёд. Или вам нужно глянуть в глаза человеку, чтобы определить, что он не американский/китайский шпион? У ЗАО "МЦСТ" нет, не было и, вероятно, не будет своей операционной системы, а значит что там крутится какой-нибудь Linux или в лучше случае BSD. А это значит, что дать удалённый shell можно всем, кому это действительно нужно. А если страх утечки сильно велик, то ведите полный лог каждого сеанса. Таким образом вы не только сможете опередилить "потенциального шпиона", но и найти слабые места железа и софта.

5028. xameleon, 03.10.2013 16:44

цитата: KT: Общую адекватность оценить. Разве это не достаточное основание? Это самый простой способ, согласен. Но тем самым вы (ЗАО МЦСТ) сужаете круг желающих прикоснуться с отечественному процессору. цитата: Вы спрашивали относительно производительности х86 . Большинству тех, с кем я общался, интересна Винда, именно её я подразумевал при тестировании только на нашей территории. И как Вы предлагаете с ней ssh elbrus1.mcst.ru? Простите, очень может быть Вы не с теми общались? Crusoe от Transmeta тоже исполнял x86 в эмуляции и кому он нужен теперь. Всё уже забыли и о Crusoe и о Transmeta. цитата: А если Вам нужен Линукс - то почему не перейти к нативным кодам? Вот вот вот - отвечаю ниже как раз после "паяльника" :) цитата: Вы узнаете, что кто-то слил себе полный образ диска. Что дальше - гоняться за ним с паяльником? Если мы говорим о клонах Юниксов, то защитить довольно просто. Дайте человеку shell, vi и сс. Я так понимаю, что ассемблерный код, сгенерённый компилятором, вы (МЦСТ) показывать не хотите. Решается довольно просто. Во первых, аттрибут -r на все исполняемые файлы, чтобы пользователь даже заглянуть в них не смог. Во вторых, асемблеру as и линковщику ld можно назначить права запуска от специального пользователя, а сс установить suid бит, чтобы при старте он работал от этого пользователя. И самое главное правило - не храните ничего секретного на машине, доступ к которой открыт из Сети. Дополнительная защита - файрволл, который разрешает доступ к машине по ssh только из списка разрешённых IP-адресов. Любая компания, которая претендует на звание серьёзного разработчика, может позволить себе статический IP адрес. Понимаете, уважаемый KT, если пользователь без прав может что-то утянуть, чего он не должен, то нужна ли такая система и есть ли в ней смысл? Даже для /etc/passwd уже десятки лет существует /etc/shadow Ну и немного помечтать о том, что можно сделать, имея shell, vi и cc. В редактор vi можно закопиастить исходный код протокола Z-modem, собрать его компилятором в домашней директории и использовать для передачи исходных текстов непосредственно через ssh. А дальше уже дело техники - из GNU/BSD исходников в домашней директории вполне можно собрать работоспособную и удобную консольную среду. При этом сетевые интерфейсы системы могут быть закрыты для пользователя.

5030. xameleon, 03.10.2013 17:39

цитата: ПростоЗашёл: Если Вы, предположим, производитель паровозов, тоже потянутся при этих условиях? Первональную инфраструктуру создают гики. Без инфраструктуры производители паровозов даже не заметят нового процессора.