Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 5, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21 |
|
<< Предыдущая тема | Следующая тема >> |
| Заглядывая в туманное будущее - обсуждение | ||
| Переход на страницу 1 2 3 ... 13 [14] 15 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| den1 |
| ||
 ID пользователя #363 Зарегистрирован: Вторник 05.07.2005 16:47Местонахождение: Россия. Москва. Сообщений: 151 | captain cobalt написал(а) ... Вообще, я не против не-фон-Нейманов. Но на мой взгляд единственная альтернатива, достаточно радикальная, чтобы быть обоснованной, и в то же время весьма приятная для программирования, это РЕФАЛ-машина. Как насчёт? Вот попсовая статейка. 1. Ничего особо не знаю про ЯП РЕФАЛ, кроме утверждения о высокой эффективности при сочетании со специализированным процессором. Captain так хорошо объясняет, что потихоньку отучает пользоваться Google  . Прости уж , но поэтому прежде, чем знакомиться с РЕФАЛ вопрос к тебе. Интересно твоё мнение о соотношение РЕФАЛ и Оберон, если так вообще корректно спрашивать. captain cobalt написал(а) ... Вот такой небольшой блок из цитат captain/а. По большому счёту рантайм (Bluebottle - примечание den1) состоит из следующих частей: -- динамический компоновщик модулей -- распределитель памяти со сборщиком мусора -- шедулер активных объектов ... Также огромное количество вычислительных ресурсов тратится на проверки зависимости по данным и прочие накладные расходы суперскаляров. Если бы все эти вычислительные ресурсы были доступны программно, то распараллеливание команд можно было проводить во время компиляции, а (программные) проверки адресов вставлять только там где это необходимо. Высвободившиеся вычислительные ресурсы можно "использовать с пользой". ... (А пока рано думать о других процессорах.) ... den1 написал(а) ... Это будет очень скоро (вспомните недавнее заявление Intel (если не ошибаюсь) об автоматически распараллеливающем компиляторе) Кстати это вообще не проблема и соответствующая матчасть имеет возраст более 20 лет. По большому счёту нужно лишь искать максимальные потоки в графе потоков данных. Кстати похоже сейчас на практике в этом деле рулит компилятор VectorC. 2. Как бы то ни было, даже Оберон не полностью независим от аппаратуры. Давайте всё же хотя бы представим другие процессоры.Представим некий гипотетический процессор будущего. Для предположения устройства такого процессора применим принцип элиминации - исключения всего, без чего можно обойтись. С точки зрения единообразия и распараллеливания вычислений желательно достичь ситуации, когда добавление процессора в объединение таких процесоров для Сущности (ОС по старому ), которая функционирует на этих процессорах будет выглядеть только, как увеличение ресурса для вычислений. Попробую осторожно конкретизировать и пока, давайте говорить о достаточно реальных технологиях: исключим понятие cash памяти, как таковое. Будем считать, что вся память для каждого такого процессора физически интегрирована в микросхему процессора. И это энергонезависимая память, примерно, как nvSRAM. Пока не будем говорить о быстродействии... или размере памяти - будем считать их достаточными. Также нет никакой другой памяти, кроме указанной (нет НЖМД, Flash и тому подобного). (Я бы, кстати, добавил - единое адресное пространство, что предпочтительнее при прочих равных. Примем это.) captain cobalt написал(а) ... Когда здесь будут достигнуты адекватные результаты, возможно будет построить пресловутую RAM OS... , которая просто порвёт современные системы с виртуальной памятью и подкачкой. Допустим, что достигнуты. В этих условиях, просто логичнее было бы упрощать архитектуру каждого процессора... Повторю, исхдя из предположения, что мы можем добавлять процессоры в ОС сколько потребуется - много процессоров - очень много процессоров... Далее вопрос, (если не будет корректировок в сторону упрощения аппаратуры)... : Конечно, довольно специфический ..., но всё же вопрос, особенно к captain/у: Что это должна быть за система. Что за ЯП - пусть теоретический, подходит для неё лучше всего? | ||
| Наверх |
| ||
| captain cobalt |
| ||
 ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | den1 написал(а) ... Оберон - это простой и мощный императивный язык программирования.Ничего особо не знаю про ЯП РЕФАЛ, кроме утверждения о высокой эффективности при сочетании со специализированным процессором. Captain так хорошо объясняет, что потихоньку отучает пользоваться Google . Прости уж , но поэтому прежде, чем знакомиться с РЕФАЛ вопрос к тебе. Интересно твоё мнение о соотношение РЕФАЛ и Оберон, если так вообще корректно спрашиватьРефал - это простой и мощный функциональный язык программирования. Рефал (60-е гг.) старше чем Оберон (80-е гг.) Язык Оберон разработал Никлаус Вирт. Поставленная задача - разработать простой язык для программирования машин повсеместно распространённой фон-Неймановской архитектуры. Если Оберон запросто может выучить любой компетентный программист, прочитав один раз (или два) описание языка, то Рефал - это "не для слабаков". Хотя тоже очень просто. Рефал хорошо подходит для генерации/парсинга текстовых файлов - компиляторов, веб-программирования, и т. п. den1 написал(а) ... Плохо.исключим понятие cash памяти, как таковое. Будем считать, что вся память для каждого такого процессора физически интегрирована в микросхему процессора. И это энергонезависимая память, примерно, как nvSRAM. Пока не будем говорить о быстродействии... или размере памяти - будем считать их достаточными. Также нет никакой другой памяти, кроме указанной (нет НЖМД, Flash и тому подобного). Многоуровневая иерархия памяти используется в существующей аппаратуре потому что различные её уровни существенно отличаются друг от друга по скорости, объёму и цене за единицу объёма. Одноранговая иерархия представляется совершенно беспомощным решением. Только в тетрис играть. den1 написал(а) ... Напомню, речь шла о том, что компилятор должен автоматически оптимизировать перемещение данных между уровнями иерархии памяти.Допустим, что достигнуты. И вот для этого нужны языки, программы на которых поддаются автоматическому анализу. Не годятся языки в которых случайно или злоумышленно повредив машинный стек можно передать управление в любую точку машинного кода. den1 написал(а) ... Это называется "масштабируемость".В этих условиях, просто логичнее было бы упрощать архитектуру каждого процессора... Повторю, исхдя из предположения, что мы можем добавлять процессоры в ОС сколько потребуется - много процессоров - очень много процессоров... Здесь обязательно надо отметить тот факт, что масштабируемая система всегда несколько сложнее и дороже чем немасштабируемая такой же мощности. Но масштабируемая может эффективно извлекать пользу из дополнительных ресурсов, а немасштабируемая - не может. Короче говоря, масштабируемость - это усложнение. Обоснованное усложнение. den1 написал(а) ... Пожалуй, самое общее требование - программный код должен эффективно анализироваться автоматически.Конечно, довольно специфический ..., но всё же вопрос, особенно к captain/у: Что это должна быть за система. Что за ЯП - пусть теоретический, подходит для неё лучше всего?Язык должен предоставлять возможность и поощрять уменьшение зависимостей между отдельными частями кода. Безопасные языки - годятся. Функциональные языки - годятся. Низкоуровневые языки - не годятся. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| den1 |
| ||
| ID пользователя #363 Зарегистрирован: Вторник 05.07.2005 16:47Местонахождение: Россия. Москва. Сообщений: 151 | Вот отлично. Заждался твоего комментария. Capitan, большое спасибо за образовательную часть. Правда. captain cobalt написал(а) ... Намёк ясен Оберон - это простой и мощный императивный язык программирования. Рефал - это простой и мощный функциональный язык программирования. . Будем читать.captain cobalt написал(а) ... Что же так сразу и плохо den1 написал(а) ... Плохо.исключим понятие cash памяти, как таковое. Будем считать, что вся память для каждого такого процессора физически интегрирована в микросхему процессора. И это энергонезависимая память, примерно, как nvSRAM. Пока не будем говорить о быстродействии... или размере памяти - будем считать их достаточными. Также нет никакой другой памяти, кроме указанной (нет НЖМД, Flash и тому подобного). .captain cobalt написал(а) ... Многоуровневая иерархия памяти используется в существующей аппаратуре потому что различные её уровни существенно отличаются друг от друга по скорости, объёму и цене за единицу объёма. Это всё, конечно, хорошо, понятно и обыденно так сказать, но, не не пойми меня неправильно - это всё не аргумент. Давай всё же ненадолго представим, что мы можем позволить себе много высокоскоростной памяти... Вобщем я перефомулирую свой вопрос к тебе:При прочих равных, что за систему бы ты выбрал: 1. с одноуровневой организацией памяти, или 2. с многоуровневой организацией памяти ? captain cobalt написал(а) ... Одноранговая иерархия представляется совершенно беспомощным решением. Только в тетрис играть. Вот почему? Почему ты так считаешь ?Ясно, что исторически приходится учитывать (читай - усложнять системы) иерархию организации памяти оборудования. Но формально в начале кэш-память - была неким техническим ухищрением - добавлением. Возможно ошибаюсь, но впервые в IBM 704: магнитная лента - прототип hdd, магнитный барабан - оперативная память, а память на магнитных сердечниках - кэш-память. Теперь же ситуация выглядит так, что основная память выполняет ту работу, что правильнее было бы поручить кэш-памяти. Но кэш памяти для этого пока просто не хватает. То есть это всего лишь техническая проблема. Я же писал, что: den1 написал(а) ... Пока не будем говорить о быстродействии... или размере памяти - будем считать их достаточными. а ты отвечаешь, что: captain cobalt написал(а) ... её уровни существенно отличаются друг от друга по скорости, объёму. Вобщем, пожалуйста , объясни, что плохого в одноранговой иерархии организации памяти оборудования. Очень интересно не только твоё мнение, но и аргументация.captain cobalt написал(а) ... Возможно, ты пока не аргументируешь, чтобы я как раз напоролся на те вопросы, что задаю тебе сейчас, но если так надо для дела... den1 написал(а) ... Напомню, речь шла о том, что компилятор должен автоматически оптимизировать перемещение данных между уровнями иерархии памяти.Допустим, что достигнуты. . Согласись, там, где нет многоуровневой иерархии организации памяти - там не требуется вовсе усложнять компилятор для учёта такой иерархии. Нет расхода ресурсов и потерь времени на корректировки и учёт перемещения данных между уровнями, и прочих потерь с этим связанных.captain cobalt написал(а) ... Хорошо, хорошо - мы доёдем до этого, если я тебя сильно не достану И вот для этого нужны языки, программы на которых поддаются автоматическому анализу. Не годятся языки в которых случайно или злоумышленно повредив машинный стек можно передать управление в любую точку машинного кода. к тому времени. Однако, я не понял, как ты связал стек с многоуровневой организацией памяти, определяемой в первую очередь оборудованием. captain cobalt написал(а) ... Если бы я написал масштабируемость, получилось бы неоднозначно, нечётко. Я вобщем в курсе (а то люди подумают, что я совсем тёмный den1 написал(а) ... Это называется "масштабируемость".В этих условиях, просто логичнее было бы упрощать архитектуру каждого процессора... Повторю, исхдя из предположения, что мы можем добавлять процессоры в ОС сколько потребуется - много процессоров - очень много процессоров... ). Написал подробно, чтобы было понятно - о чём вообще речь идёт.captain cobalt написал(а) ... Не уверен, что подобное сравнение корректно. Масштабируемая - мощнее по определению - изначально мощнее. Когда немасштабируемая система достигает своего максимума - масштабируемая может быть расширена и нарастит мощность за счет такого расширения. Конечно, ты сказал скорее о соотношении - но смысл такого сравнения... Здесь обязательно надо отметить тот факт, что масштабируемая система всегда несколько сложнее и дороже чем немасштабируемая такой же мощности. Но масштабируемая может эффективно извлекать пользу из дополнительных ресурсов, а немасштабируемая - не может. Вообще говоря, на мой взгляд совершено не обязательно, что маштабируемая система всегда сложнее немасштабируемой такой же мощности. Пока это так лишь в силу технических причин. captain cobalt написал(а) ... Не уверен, что это так. Что зависимость линейная... До определённого момента, возможно усложнение, а, возможно, ... упрощение... С какой стороны смотреть. Что считать... Усложнение архитектуры составляющих компонентов, процессоров масштабируемой и немасштабируемой систем..., их операционных систем... Вобщем надо подумать ещё, над тем, что ты сказал Короче говоря, масштабируемость - это усложнение. Обоснованное усложнение. .captain cobalt написал(а) ... Вот здесь полностью согласен.den1 написал(а) ... Конечно, довольно специфический ..., но всё же вопрос, особенно к captain/у: Что это должна быть за система. Что за ЯП - пусть теоретический, подходит для неё лучше всего?Пожалуй, самое общее требование - программный код должен эффективно анализироваться автоматически. captain cobalt написал(а) ... Язык должен предоставлять возможность и поощрять уменьшение зависимостей между отдельными частями кода. Безопасные языки - годятся. Функциональные языки - годятся. Низкоуровневые языки - не годятся. Хм... так как ты, как-то сразу и довольно категорично отверг простую организацию памяти, не получается пока обсудить работу, соответствующей такой организации - системы... | ||
| Наверх |
| ||
| batu |
| ||
 ID пользователя #5 Зарегистрирован: Суббота 03.07.2004 22:20Местонахождение: Г Харьков Сообщений: 22 | Одноуровневой памяти никогда не будет. Всегда будет разница в объемах, в ценах или по другим праметрам (например размеру). Да и апетиты растут. Может появиться внешняя память общая для сети, или желание поработать в памяти простаивающего сейчас другого компьютера или компьютеров. Решение простое : надо что б управление памятью было скрыто от програмиста. Я уже говорил о диспетчере памяти как о составной части архитектуры машины (наравне с диспетчером процессоров). Это решение простое или сложное? С точки зрения архитектуры машины-сложное. С точки зрения програмиста значительно упрощает работу. Кэш памятью можно назвать самую скоростную память в архитектуре машины. И может быть даже регистры. Вопрос не в названиях, а в алгоритмах управления этой памятью. Я бы хотел иметь кэш с програмируемыми алгоритмами работы. Вряд ли существует один алгоритм эффективно работающий для всех случаев. | ||
| Наверх |
| ||
| Vadim Ushakov |
| ||
 ID пользователя #409 Зарегистрирован: Четверг 18.08.2005 04:25Местонахождение: Красноярск Сообщений: 85 | Две недели сидел без инета, и вот он я - опять здесь! Благие намеренья наделать из этого обсуждения отдельных топиков пропали втуне, вот я, вместо того, чтобы открыть новую тему, пишу сюда. Собственно, у меня вопрос к Капитану. (В последнее время вообще все ему задают вопросы.  ) Я занимаюсь сейчас одним проектом, пишу некое подобие NT-ядра (хотя это скорее не ядро, а нечто среднее между HAL и Executive). Возможно, оно получилось похожим на NT из-за того, что потратил довольно много времени на изучение исходников ReactOS. Предполагается, что там будут такие вещи, как:1. Средства доступа к железу: функции ввода-вывода, поддержка SMP, интерфейс для работы с шинами PCI и ISA. 2. Многозадачность и многопоточность, диспетчер потоков, планировщик. 3. Средства управления физичесной и виртуальной памятью. Там НЕТ понятия процессов, третьего кольца защиты, и нет интерфейса к ядру через прерывания. Есть единое линейное адресное пространство - задачи переключаются просто загрузкой/восстановлением регистров, никакой аппаратной защиты. Все это пишется не как самоцель, а как платформа для реализации среды исполнения безопасного языка программирования. Идея "run-time на голом железе" все-таки как-то не укладывается у меня в голове. Да и возникают сомнения, что, например, механизм переключения потоков может быть эффективно реализован на Oberon. Все-равно придется писать на Си или ассемблере - так уж лучше я все архитектурно-зависимые части сразу напишу на Си. Чтобы потом не блуждать в трех соснах и сосредоточиться на реализации среды исполнения. А вопрос, собственно, такой: что Капитан (с его идеей максимальной простоты во всем) об этом думает? Так сказать, мне нужно получить одобрение авторитета в этой области. Или наоборот, неодобрение. Оба мнения будут одинаково ценны.Так же есть вопросы по реализации самой среды. Если я правильно понял, Bluebottle при исчерпании потоком стека, выделяет ему новый стек большего размера и безопасно - с перенастройкой всех внутристековых указателей - переносит данные в новый стек. Или же это происходит иначе? Я думал об использовании фрагментированного (сегментированного) стека. Стек состоит из отдельных областей, которые выделяются динамически и переключаются прозрачно для программы. Какой метод лучше? И еще, в любом случае нужно как-то отслеживать исчерпание стека. Аппаратная защита не обеспечивает надежности - даже если у нас есть охранная область размером 64KiB, ничто не мешает процедуре выделить под локальные переменные 128KiB и без спросу залезть в чужую область памяти. Значит, нужна защита программная. Как все это реализовано в Bluebottle? У меня есть наработки, но не хотелось бы изобретать велосипед. И вот уж поистине неразрешимый вопрос: а какой язык реализовывать-то? Oberon-2 хорош, но он не поддерживает многопоточность.  А Active Oberon... Я не могу внятно объяснить, чем он плох, но этот язык СПРОЕКТИРОВАН НЕПРАВИЛЬНО, он НЕДОДЕЛАН ДО КОНЦА. После изучения документации на Active Oberon остается чувство какой-то безнадежной недосказанности... Чисто интуитивное мнение, но это не тот язык с которым я связываю будущее развитие информатики.А другие кандидаты есть? Ада невероятно сложна и не поддерживает сборку мусора. C# и Java тоже не блещут простотой и имеют странности в семантике. Модула-2? Она тоже не поддерживае сборку мусора, насколько я знаю, но зато достаточно проста. Есть ли в ней поддержка многопоточности? Если есть, то легко ли заточить этот язык (не внося серьезных изменений в его семантику) под автоматическую сборку мусора? Я плохо знаком с Модула и у меня нет его спецификации, но если кто имеет опыт работы с ним, pls, поделитесь впечатлениями и идеями. Или реализовать функциональный язык? Мысль дикая, но кто сказал, что программисты будут вечно пользоваться императивными языками? Пойду погуглю что-нибудь о Рефале... Падает тот, кто бежит; тот, кто лежит – уже не падает. | ||
| Наверх | | ||
| den1 |
| ||
| ID пользователя #363 Зарегистрирован: Вторник 05.07.2005 16:47Местонахождение: Россия. Москва. Сообщений: 151 | batu написал(а) ... Одноуровневой памяти никогда не будет. Всегда будет разница в объемах, в ценах или по другим праметрам (например размеру). Да и апетиты растут. Да что же вы так прицепились к стоимости и объёмам... ... . К лешему стоимость, туда же и объём. Вобщем мне есть, что сказать. Продолжу эту часть в Аппаратной основе ОС-21. | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
  ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | Vadim Ushakov написал(а) ... Я занимаюсь сейчас одним проектом, пишу некое подобие NT-ядра (хотя это скорее не ядро, а нечто среднее между HAL и Executive). Адрес? Греби и улыбайся! | ||
| Наверх |
| ||
| Vadim Ushakov |
| ||
| ID пользователя #409 Зарегистрирован: Четверг 18.08.2005 04:25Местонахождение: Красноярск Сообщений: 85 | Roman I Khimov написал(а) ... У меня на жестком диске. Адрес? Пока показывать особо нечего. Опознает SMP, настраивает APIC, обрабатывает ISR и DPC, рисует на экране консоль встроенного отладчика. Вот собственно, и все. Даже потоки не переключает. Учитывая мою прирожденную лень, обещаю выложить в инет недельки через три-четыре. Падает тот, кто бежит; тот, кто лежит – уже не падает. | ||
| Наверх | | ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | Vadim Ushakov написал(а) ... У меня на жестком диске На самом деле мне более интересны мысли по рантайму. Греби и улыбайся! | ||
| Наверх |
| ||
| Chizh |
| ||
 ID пользователя #90 Зарегистрирован: Понедельник 13.09.2004 18:42Сообщений: 170 | captain cobalt написал(а) ... Язык Оберон разработал Никлаус Вирт. Поставленная задача - разработать простой язык для программирования машин повсеместно распространённой фон-Неймановской архитектуры. Что по сути - HLA. captain cobalt написал(а) ... Язык должен предоставлять возможность и поощрять уменьшение зависимостей между отдельными частями кода. Безопасные языки - годятся. Функциональные языки - годятся. Низкоуровневые языки - не годятся. Тут уж извиняйте, языки без сайд-эффектов бывают только функциональными. | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 ... 13 [14] 15 | |
Powered by e107 Forum System