Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 6, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21 |
|
<< Предыдущая тема | Следующая тема >> |
| Аппаратная основа ОС21 | ||
| Переход на страницу 1 [2] 3 4 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| ddc |
| ||
Free Software Zealot   ID пользователя #202 Зарегистрирован: Воскресенье 06.02.2005 09:32Местонахождение: Москва Сообщений: 189 | Я считал и считаю, что ОС-21 должна в первую очередь работать в безвоздушном пространстве. Причём желательно подальше от компьютеров. Почему все так рвутся вперёд, не понимая возможностей существующего?.. Но это всё, конечно, моё сугубо личное мнение... | ||
| Наверх | | ||
| captain cobalt |
| ||
  ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Lordius написал(а) ... Замечательно.Для затравки идея такова: «- реализовать асинхронную безадресную архитектуру». Очень простой вопрос: как насчёт Pефал-машин. Имхо, единственная модель вычислений, для которой возможности могут оправдать вложения в аппаратную реализацию. Lordius написал(а) ... Тем не менее, аппаратный параллелизм абсолютно необходим.Долой все эти кеши, блоки предсказания ветвлений и прочую мутоту Для фон-Нейманов единственное оставшееся направление - EPIC. Roman I Khimov написал(а) ... Поддерживаю.ОС-21 должна работать на любой аппаратной платформе (ОК, я не беру в расчет семейство MCS51 и прочие "очень embedded"), в том числе и на x86{_64}. Аппаратная часть может способствовать работе ОС-21 (читай - аппаратная реализация машины .NET  ), но только после того как ОС-21 зарекомендует себя на обычном железе. До тех пор аппаратура и софт могут свободно развиваться параллельно.Но аппаратная поддержка .NET - это слишком жирно и не гибко. Хотя отдельные вещи, например, сборка мусора, были бы полезны. Lordius написал(а) ... Что это означает?Это чего регулярно писать кодогенератор для каждой новой железяки, которую реализуют в будущем. Зачем остовлять потомкам ковыряние известно в какой архитектуре Надо обойтись без кодогенераторов? Или надо разработать "единственную и лучшую" архитектуру, которая должна вытеснить intel? Lordius написал(а) ... Никогда это не интересовало.А схему этого самого Ceres'a раскопать где-то можно, хотя бы блок-схему, принципиалку. Срочно топать на oberon2005, ещё есть шанс донести этот вопрос собственно до Вирта. А вот цитата из книги "Project Oberon": Ceres-1 was built around a National Semiconductor 32032 microprocessor, which was in 1985 the first commercially available processor using a 32 bit wide bus. It appeared as particularly attractive to the compiler builder because of its regular instruction set. The computer was equipped with 2 MBytes of main memory, a 40 MByte disk, a diskette, a 1024*800 pixel display, and of course with keyboard and mouse. These resources were more than adequate for the Oberon System. Ceres-2 was introduced in 1988 and replaced the processor by its faster version, the NS 32532, which increased its computing power by a factor of at least 5 over its predecessor. Memory was extended to 4 - 8 MByte and the disk to 80 MByte. In order to install the software, "only" a few modules had to be adapted, the kernel because of different page structure, and device drivers because of different device addresses. In 1990, a low-cost version, Ceres-3 was designed, and 100 computers were built and installed in laboratories. This single-board computer is based on the NS 32GX32 processor without virtual addressing unit, and includes a 4-8 MByte memory. The distinctive feature is that the file system is implemented in one (protected) half of memory instead of a disk, increasing operating speed dramatically. Ceres-3 is free from mechanically moving parts (no fan) and therefore is completely noiseless. It is primarily used in laboratories for students. The usefulness of a central server for system file distribution is evident. Lordius написал(а) ... Стековая архитектура мне не очень нравится. Именно потому, что существенно ограничивает адресацию данных и параллелизм.Зачем, берем безадресную /стековую/ архитектуру за основу обработчика. Благо открытые реализации которых имеются. Увязываем n-ое количество таковых обработчиков. чем-то последовательным и высокоскоростным. czarker написал(а) ... Замечательно.Я считал и считаю, что ОС-21 должна в первую очередь работать в безвоздушном пространстве. Причём желательно подальше от компьютеров. Почему все так рвутся вперёд, не понимая возможностей существующего?.. Это в точности то, что я пытаюсь донести. В настоящее время Bluebottle - это технологический лидер в области системной архитектуры. Она не является венцом творения. Это лишь направление, которое доступно здесь и сейчас, и в котором можно двигаться. Однако, ковбои, прочитавшие (по диагонали) учебник Таненбаума даже не хотят пытаться "понять возможности существующего". И лишь рассуждают о клонировании подходов 80-90-х годов. Печально.  bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| den1 |
| ||
| ID пользователя #363 Зарегистрирован: Вторник 05.07.2005 16:47Местонахождение: Россия. Москва. Сообщений: 151 | captain cobalt написал(а) ... den1 написал(а) ... Что ясно-то было? У меня же , мнение по вопросу практически не изменилось с конца 80-х. Это всё было ясно ещё тогда. Кто "победит": Серая Слизь или Нанотех? Победят, как всегда, наши конечно .Вобще в "Нанотехе", на мой взгляд, достаточно неразвито используются идеи "Машин создания" Дрекслера, как раз. То есть "Нанотех", к несчастью, написан так, что формирует неправильное представление по теме у читателя. Насколько я понял, автор как бы прячет свою сосредоточенность на вечных ценностях, чтобы у читателя складывалось впечатление, что именно они -главное в рассказе. На самом деле, нещадным образом эксплуатируется нанотехнологическая концепция. Повторюсь, не лучшим образом. Это только вредит популяризации самого подхода. С другой стороны, возможно, хоть что-то здесь - лучше, чем ничего. А ясно было - к чему всё движется. Могу не вспомнить точно, но до массовой популярности - материалы по теме у нас стали появляться ещё в "Технике Молодёжи" . | ||
| Наверх |
| ||
| ddc |
| ||
| Free Software Zealot ID пользователя #202 Зарегистрирован: Воскресенье 06.02.2005 09:32Местонахождение: Москва Сообщений: 189 | captain cobalt написал(а) ... Боюсь, Bluebottle интересна не как ОС, а как среда исполнения ПО. А вот её системный дизайн, насколько я знаю, не может похвастаться стройностью и изяществом FreeBSD или хотя бы (даже!!!) общей правильностью Linux или Plan9 (ОС, появившейся до моего рождения). В настоящее время Bluebottle - это технологический лидер в области системной архитектуры. Она не является венцом творения. Это лишь направление, которое доступно здесь и сейчас, и в котором можно двигаться. Но это всё, конечно, моё сугубо личное мнение... | ||
| Наверх | | ||
| Lordius |
| ||
 ID пользователя #130 Зарегистрирован: Четверг 21.10.2004 01:00Местонахождение: Kiev, Ukraine Independent Сообщений: 74 | captain cobalt писал: "Стековая архитектура мне не очень нравится. Именно потому, что существенно ограничивает адресацию данных и параллелизм." Это чем она уважаемый ограничивает параллелизм? Вначале стековые процессоры были 8-битные и успешно "перемалывали" данные. 32-битные, на которых завершилось их развитие в железе очеь успешно работали приблизительно в 4 раза быстрее.На массовых х86 овощерезках добавление 2-го процессора увеличивает производительность в 2 раза? Что такое стек  там есть понятие адреса???Адресация, это зачем? пакетная обработка Вот где я это нашел, идея мне очень и очень понравилась http://www.osp.ru/os/1997/06/78.htm Не может быть чтобы никто не писал под подобное чудо ОС? | ||
| Наверх | | ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Lordius пишет В стековой архитектуре большинство команд работают с элементом на вершине стека. Каждая команда должна дожидаться окончания предыдущей. Вершина стека тоже одна на стек. Команды которые двигают вершину стека должны дожидаться окончания друг друга.Это чем она уважаемый ограничивает параллелизм? Конкретный пример. В IA-32 FPU имеет стековую архитектуру. Это существенно ограничивало его производительность. Поэтому в intel начиная с pentium ввели для него register renaming с помощью команды FXCH. Смысл именно в том чтобы уйти от стека и перейти к плоской работе. Подробнее - в мануалах по оптимизации. Lordius пишет Наверное, не пакетная, а потоковая?Адресация, это зачем? пакетная обработка Как нарисовать окружность на растровом дисплее? Нет ли необходимости прямого доступа к произвольному пикселю? bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Lordius |
| ||
| ID пользователя #130 Зарегистрирован: Четверг 21.10.2004 01:00Местонахождение: Kiev, Ukraine Independent Сообщений: 74 | Очень интерсно  ), бесконечное поле памяти на чем будем организовывать?Если обсуждение сути будет перемежатся предложениями создания ОС-21 в абсолютном межгалактическом вакууме:) или использования серой слизи в качестве элементной базы:)Тогда далеко пойдем, очень далеко. От сути обсуждаемых вопросов.. Вот:) | ||
| Наверх | | ||
| Lordius |
| ||
| ID пользователя #130 Зарегистрирован: Четверг 21.10.2004 01:00Местонахождение: Kiev, Ukraine Independent Сообщений: 74 | Ага согласен, но разработчики из Sun когда разрабатывали PicoJava\процессор для непосредственного исполнения программ написаных на Java\ Это ограничение обошли, там разработали вот что "Технология зацепления команд позволяет одновременно обрабатывать до четырех команд. Для выполнения примера, приведенного на рис.2 без зацепления команд (a) потребуется четыре такта процессора. Стековый регистровый файл picoJava (b) позволяет за один такт извлечь операнды из нижней части стека, выполнить нужную операцию и сохранить результат " Есть еще регистровые окна - вроди бы Фуджитсу разработала, где это все?  <span class='smalltext'>[ 130_1710000.gif ]</span> | ||
| Наверх | | ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Вот именно. Для распараллеливания кода необходим его анализ. Если речь идёт об анализе прямо на лету во время исполнения, то это называется "суперскаляр" (катерория машин), который, как известно, must die. Огромное количество вычислительных ресурсов тратится именно на этот анализ распараллеливания, и эти ресурсы неапрямую недоступны программно. Гораздо лучшее решение - сделать все аппаратно реализованые вычислительные ресурсы программно доступными, а задачу эффективного их использования и распараллеливания отдать компилятору.Цитата из той же статьи: Исследования показали, что в различных Java-приложениях от 23 до 37% команд (в среднем 28%) можно зацепить с другими командами. Предположим невероятное - что все эти команды удалось сцепить в нулевое количество команд. Тогда производительность в среднем возрастёт на эти 28%. Насколько это существенно? Не было ли потрачено ещё больше вычислительных ресурсов на анализ распараллеливания?Пример на картинке тоже показательный. В стековом коде четыре команды и три адреса операндов из середины стека. В плоском коде одна команда и три адреса операндов из середины стека. Какой код будет более компактным? Какой код требует меньше ресурсов на анализ распараллеливания? В чём семряжный смысл использования стековой машины? bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Vadim Ushakov |
| ||
 ID пользователя #409 Зарегистрирован: Четверг 18.08.2005 04:25Местонахождение: Красноярск Сообщений: 85 | Den1 писал об одноуровневой памяти в другом топике. Но там и так много чего обсуждается, так что я пишу здесь; да и правильнее это - соответствует название топика. Идея одноуровневой памяти везде и всюду слушком... э-э-э... странная, что ли. Предлагаю другое решение. Имеется некая высокоскоростная шина передачи данных. Настолько высокороскоростная, что на современном уровне технического прогресса мы пока не можем достичь таких скоростей. По шине обмениваются данными _активные_ _устройства_, т.е. устройства, содержащиее в себе процессор. Детали реализации этой шины не важны, может быть даже она не будет иметь привычную нам организацию "кучи проводников, на которых сидят устройства". Вероятно, что устройства могут обмениваться данными по шине паралельно и незавимо друг от друга: A читает данные с B, а C в это время пишет данные на D; т.е. аппаратно реализована в виде нескольких паралельных каналов передачи данных. Главное, что любое устройство на шине может: 1) определить адреса всех прочих устройств; 2) определить тип устройства по его адресу; 3) послать любому устройству или нескольким устройства сразу сигнал прерывания; 4) читать/писать данные из/в адресного пространства устройства. Последний пункт не всегда возможен - устройство может не иметь своего собственного адресного пространства. Доступ в адресное пространство другого устройства производится просто адресацией на шине. Например, полный 256-битный адрес состоит из 128-битного адреса устройства и 128-битного адреса в адресном пространстве устройства. Адрес устройства 0 используется как "петля" - всегда указывает на "свое устройство". Адрес устройства 1 - это ГОЗУ (об этом ниже). Еще некоторый диапазон адресов будет зарезервирован под какие-то системные нужды - а в остальном подключай столько устройств, сколько позволяет конкретная аппаратная реализация. Не следует удивляться "диким" 128-битным адресам - это просто сделано для неограниченной масштабируемости в будущем. А сейчас, например, можно реализовать такую шину с 8-битным адресом устройства и 40-битным локальным адресов - хватит еще на многие годы. Где вы видели компьютер, к которому подключено 200 устройств? ГОЗУ - это глобальное оперативное запоминающее устройство. Там лежат данные, которые используются всеми активными устройствами. Теоретически, максимальная емкость ГОЗУ - 2 в степени 128. Практически - сколько конкретная реализация позволяет затолкать в слоты. Поскольку ГОЗУ - объект, к которому так или иначе обращаются все устройства и делают это достаточно часто, его наверное лучше реализовать не как отдельное устройство, а как часть контроллера системной шины - только слоты для оперативки будут торчать на системной плате. Что касается активных устройств, тут спект широк. Вот несколько примеров. 1. Процессор общего назначения. Наверное, что-то похожее на Itanium - очень тупой, быстрый и с кучей регистров. Локальной памяти не имеет. Исполняет код из ГОЗУ или адресного пространства других устройств. Хочешь повысить общую мощность компа - покупай побольше процессоров и распихивай по слотам. 2. Процессор 3D-графики и физических рассчетов. Есть своя локальная память. Заточен на очень быстрое выполнение операций с векторами. Хочешь на своем компе рендерить фильмы - покупай кучу 3D-процессоров, лишь бы слотов на материнке хватило. 3. Процессоры, заточенные под конкретную вычислительную ситуацию. Например устройство, которое полностью аппаратно и с высочайщей скоростью рендерит сцену по спецификации DirectX последней версии... Или OpenGL... Или еще что-то, что появится в будущем. 4. Видеокарта. Отдельное от 3D-процессора устройство. Может, в принципе, иметь локальную память, а может под видеобуфер использовать ГОЗУ. Очень тупая - ничего не вычисляет, просто переключает буфера видеопамяти. Как только 3D-ускоритель закончил рендеринг - говорим видеокарте, что теперь буфер находится по такому-то адресу в адресном пространстве этого ускорителя, и она переключает кадр. А в это время еще 7 ускорителей рендерят следующие кадры. 5. Мост к другой шине, например к PCI. Можно подключать старые устройства через него, если, конечно, есть драйвера. 6. И так далее. Думаю, принцип ясен. Максимальная параллельность. Максимальная масштабируемость. Никакой аппаратной защиты - мы делаем систему которая работает всегда, а не почти всегда: сбоев в операционной системе не может быть по определению. Необходимость в новых драйверах возникает редко - устройства могут меняться внутри, но программно они все те же. Выше я говорил про диапазон адресов устройств, зарезервированый под системные нужды. Например "несуществующее" устройство с адресом 2 отображает ГОЗУ в постраничном режиме (т.е. реализует виртуальную память), а устройство с адресом 3 хранит карту этого отображения (таблицы страниц). Для тех, кто не верит программной защите можно, например, взять всеми "любимый" Pentium (к тому времени он будет называться как-нибудь Intel Super Hyper Pentium Gold  ) и посадить его на нашу системную шину. Операционная система будет распознавать особый формат исполняемых файлов и запускать их на нем. Пожалуйста, ваши программы будут выполняться под полным контролем его аппаратной защиты и будут работать надежно. А наши программы - и надежно и быстро.  <span class='smalltext'>[ 409_1.gif ]</span> Падает тот, кто бежит; тот, кто лежит – уже не падает. | ||
| Наверх | | ||
| Переход на страницу 1 [2] 3 4 | |
Powered by e107 Forum System