Бред про ОС
...Началось с того, что пришла мысль использовать при программировании некоторое квантование программы по времени выполнения, чтобы при выполнении программы исполнялся некоторый ее участок, затем некоторый участок другой программы и т.д., и при этом программист (или компилятор, если лень) мог бы четко планировать в каком месте программы произойдет переключение задач, чтобы например точно контроллировать некоторый внешний технологический процесс, не прерываясь в самый ответственный момент. Суть в том, чтобы программа состояла из таких явно выделенных фрагментов, а система при переключении не сохраняла бы никакой контекст - это была бы забота программиста (если программа того требует). Но наличие всяких там циклов и т.п. весь кайф обламывает. Разумеется все это можно устроить, если использовать заведомо доброкачественные программы.
Я вот подумал, подумал и придумал (мечтая о невытесняющей многозадачности в условиях возможного наличия нехороших программ) что аппаратных возможностей процессора недостаточно для создания надежной многозадачной ОС.
Так или иначе приходится вводить какую-либо защиту на программном уровне. Это влияет на быстродействие и делает систему... ну, громоздкой что ли.
И вот я подумал (пока в порядке бреда) а не будет ли жизнеспособной такая операционная система, где прикладные программы вообще не содержат исполняемого кода процессора. Что-то типа интерпретатора, только не как отдельный язык программирования (точнее - среда выполнения), а как единая многозадачная ОС (ностальгия по магиковскому бейсику).
Имеется конечный (но достаточный) набор команд (встроенный в ОС) и прикладная программа состоит исключительно из них (естественно, не в текстовом виде). При этом операционная система никогда не теряет контроля над процессором, а благодаря известному алгоритму выполнения каждой команды, она может оптимизировать паралельное выполнение программ при работе с ресурсами и т.п. Прикладная программа _в_принципе_ не может ничего нарушить.
Понятно, что вопрос упирается в быстродействие. И вся надежда на оптимизацию именно многозадачной работы.
А вот я и хочу спросить: насколько это безнадежно/перспективно ? (все таки достали уже эти GPFы на синем экране и так называемая многозадачность ("-А что такое многозадачность? -Подожди, сейчас дискету доформатирую и покажу."))
Я вот подумал, подумал и придумал (мечтая о невытесняющей многозадачности в условиях возможного наличия нехороших программ) что аппаратных возможностей процессора недостаточно для создания надежной многозадачной ОС.
Так или иначе приходится вводить какую-либо защиту на программном уровне. Это влияет на быстродействие и делает систему... ну, громоздкой что ли.
И вот я подумал (пока в порядке бреда) а не будет ли жизнеспособной такая операционная система, где прикладные программы вообще не содержат исполняемого кода процессора. Что-то типа интерпретатора, только не как отдельный язык программирования (точнее - среда выполнения), а как единая многозадачная ОС (ностальгия по магиковскому бейсику).
Имеется конечный (но достаточный) набор команд (встроенный в ОС) и прикладная программа состоит исключительно из них (естественно, не в текстовом виде). При этом операционная система никогда не теряет контроля над процессором, а благодаря известному алгоритму выполнения каждой команды, она может оптимизировать паралельное выполнение программ при работе с ресурсами и т.п. Прикладная программа _в_принципе_ не может ничего нарушить.
Понятно, что вопрос упирается в быстродействие. И вся надежда на оптимизацию именно многозадачной работы.
А вот я и хочу спросить: насколько это безнадежно/перспективно ? (все таки достали уже эти GPFы на синем экране и так называемая многозадачность ("-А что такое многозадачность? -Подожди, сейчас дискету доформатирую и покажу."))
Привет, Sanya DLR.
Почитай мой бред на смежную тему здесь:
http://osdev.ru/phpBB2/viewtopic.php?t=117
Что ты думаешь по этому поводу?
А насчёт ОС на виртуальной машине - очевидно, что камнем преткновения будет производительность. Во многих приложениях это критично. ;) Я думаю, более разумно было бы проверять программу на безопасность перед запуском, хотя это тоже приведёт к некоторым ограничениям...
Почитай мой бред на смежную тему здесь:
http://osdev.ru/phpBB2/viewtopic.php?t=117
Что ты думаешь по этому поводу?
А насчёт ОС на виртуальной машине - очевидно, что камнем преткновения будет производительность. Во многих приложениях это критично. ;) Я думаю, более разумно было бы проверять программу на безопасность перед запуском, хотя это тоже приведёт к некоторым ограничениям...
Цитата:
Originally posted by captain cobalt
Привет, Sanya DLR.
Почитай мой бред на смежную тему здесь:
http://osdev.ru/phpBB2/viewtopic.php?t=117
Что ты думаешь по этому поводу?
А насчёт ОС на виртуальной машине - очевидно, что камнем преткновения будет производительность. Во многих приложениях это критично. ;) Я думаю, более разумно было бы проверять программу на безопасность перед запуском, хотя это тоже приведёт к некоторым ограничениям...
Привет, Sanya DLR.
Почитай мой бред на смежную тему здесь:
http://osdev.ru/phpBB2/viewtopic.php?t=117
Что ты думаешь по этому поводу?
А насчёт ОС на виртуальной машине - очевидно, что камнем преткновения будет производительность. Во многих приложениях это критично. ;) Я думаю, более разумно было бы проверять программу на безопасность перед запуском, хотя это тоже приведёт к некоторым ограничениям...
По поводу таймеров (хотя вообще-то совсем по другому поводу) думаю, что всякая попытка использовать чужой софт несет в себе возможность того, что оный софт ничего не знает (или наоборот отлично знает) о правилах хорошего тона в системе и софт-таймер не сработает ни разу.
Насчет проверки программы на безопасность - всегда, как мне кажется, найдется способ ее обойти. И желание таковым воспользоваться... Тут можно говорить только об относительной безопасности (правда, я эту идею пока не развивал, так что не настаиваю), то есть по большому счету о никакой - вроде антивирусных программ, которые постоянно устаревают.
А насчет моей (как я наивно полагаю) идеи о интерпретаторе, так ведь все равно же ОС предоставляет какие-то свои функции прикладной программе, так почему бы не сделать так, чтобы программа пользовалась ТОЛЬКО вызовами ОС, полностью исключив простые команды процессора (ОС взамен предоставит комплексные команды на все случаи жизни).
И это не обязательно будет интерпретатор. Меня когда-то поразила идея установки программ в UNIX путем их компиляции, а почему бы не использовать что-то в этом роде на этапе запуска программы. Это означает, что код программы вроде как будет исполняться процессором, но не будет доступен для редактирования ни пользователю, ни самой программе - он вообще появится только после запуска, поэтому контроллируется системой (на этапе компиляции). Расходы на компиляцию, конечно. Но можно наверное как-то этот процесс упростить. Зато у операционной системы - абсолютный контроль над процессорным временем и вообще над всеми ресурсами.
Неужели нельзя обойтись без ассемблера в программировании?
Кстати, можно рассмотреть и такой вариант, когда исходный текст программы интеллектуально подменяется системой при компиляции таким образом, что скажем после каждой N-ой линейной команды (из расчета по тактам, например) делается вставочка с некоей программкой для нужд системы, а также перед каждым JMP'ом, LOOP'ом и т.п. Хотя тут надежность скорее всего не абсолютная.
Нет. Вся суть идеи именно в надежности и тут попущения недопустимы. Пусть, скажем, безопасные команды процессора будут допустимы, а потенциально опасные полностью исключены - в случае нужды используются системные конструкции (типа какого-нибудь FOR ... NEXT).
Кстати такая организация не требует наличия нескольких аппаратных уровней привилегий - работает-то всего одна программа - сама ОС.
И система всегда знает, что делает тот или иной участок ее же кода. А следовательно переключения между контекстами можно вообще избежать - система может чередовать команды разных задач как ей угодно (конечно в соответствии с требованиями самих задач), при этом подстраивая очередь так, чтобы очередная команда новой задачи могла выполняться вообще без влияния на результаты выполнения предыдущей задачи. А если это невозможно, система точно определит какую часть контекста надо сохранить.
Ещё одна витающая в воздухе идея заключается в том, чтобы сменить парадигму.
Все сколь-нибудь распространённые настольные ОС для ПЦ пропагандируют такую парадигму: есть ОС, и есть программы, которые выполняются под этой ОС. Программу запускают... И дальше она может делать всё что угодно! Если программа хорошая, она во всем слушается пользователя и выполняет все его приказы, спрашивает у пользователя, какой файл открыть, куда файл сохранить, и т. д. А если программа плохая, то она может, не спрашивая у пользователя, удалить все файлы, до которых сможет дотянуться, разослать свои копии по электронной почте друзьям пользователя и т. п.
Можно предложить другую парадигму: не программа решает, какие файлы открывать, удалять, и т.п.; а программе дают данные и приказывают их обработать. Программа при этом имеет доступ только к тем данным, которые ей передали, и не может нанести ущерб...
Существует несколько возможных путей дальнейшего развития этой идеи. Но она почему-то является не очень популярной среди разработчиков ОС. Хотя понятно, что в такой системе вирусов не могло бы быть по определению... При условии того, что сама система запрограммирована без ошибок. ;)
Все сколь-нибудь распространённые настольные ОС для ПЦ пропагандируют такую парадигму: есть ОС, и есть программы, которые выполняются под этой ОС. Программу запускают... И дальше она может делать всё что угодно! Если программа хорошая, она во всем слушается пользователя и выполняет все его приказы, спрашивает у пользователя, какой файл открыть, куда файл сохранить, и т. д. А если программа плохая, то она может, не спрашивая у пользователя, удалить все файлы, до которых сможет дотянуться, разослать свои копии по электронной почте друзьям пользователя и т. п.
Можно предложить другую парадигму: не программа решает, какие файлы открывать, удалять, и т.п.; а программе дают данные и приказывают их обработать. Программа при этом имеет доступ только к тем данным, которые ей передали, и не может нанести ущерб...
Существует несколько возможных путей дальнейшего развития этой идеи. Но она почему-то является не очень популярной среди разработчиков ОС. Хотя понятно, что в такой системе вирусов не могло бы быть по определению... При условии того, что сама система запрограммирована без ошибок. ;)
Если оставлять программам некоторые пути для пакостей, то почему бы не все - кому надо, тот и так сумеет обмануть систему (вопрос соотношения его мастерства и авторов системы), а так хоть появится возможность разгуляться программистам по железу. Но это только для игрушек сойдет. А реальность такова, что всякая маломальски открытая в мир система вскоре начнет спотыкаться на каждом шагу. Игрушка - она игрушка и есть, перезапустил - глядишь и заработала. Тогда для дела компами будут только гвозди забивать (да оно так и делается, кроме как в лабораторных условиях с кучей навесных защит). Кстати при некоторых операционках написано, что их нельзя использовать во вред: для создания ядерного оружия и т.п. Бомболюк выполнил недопустимую операцию...
Ну саму систему можно и под замок спрятать. Но проги-то всякие все равно хочется позапускать.
Мне все больше нравится идея многозадачности на основе одной наращиваемой задачи.
При запуске очередной программы система интеллектуально переплетет ее код с уже имеющимся и продолжит свое выполнение как единая программа.
И стандартные кирпичики программирования прошитые в ОС тут весьма кстати для оптимизации этого дела (плюс к надежности).
Программа сначала преобразуется из текстового формата в некоторый полуфабрикат - один раз при первичной компиляции с какого-нибудь языка. А каждый раз при запуске полуфабриката система его докомпилирует и вставляет в уже имеющийся на исполнении код. Возможно это будет не прямая вставка инструкций процессора, а что-то вроде списка (очереди) со ссылками - смотря что даст меньшие потери при запуске/выполнении.
Ну саму систему можно и под замок спрятать. Но проги-то всякие все равно хочется позапускать.
Мне все больше нравится идея многозадачности на основе одной наращиваемой задачи.
При запуске очередной программы система интеллектуально переплетет ее код с уже имеющимся и продолжит свое выполнение как единая программа.
И стандартные кирпичики программирования прошитые в ОС тут весьма кстати для оптимизации этого дела (плюс к надежности).
Программа сначала преобразуется из текстового формата в некоторый полуфабрикат - один раз при первичной компиляции с какого-нибудь языка. А каждый раз при запуске полуфабриката система его докомпилирует и вставляет в уже имеющийся на исполнении код. Возможно это будет не прямая вставка инструкций процессора, а что-то вроде списка (очереди) со ссылками - смотря что даст меньшие потери при запуске/выполнении.
та часть сообщения, где про предварителшьную компиляцию.... уж очень на технологию NET похожа...
Цитата:
Originally posted by amer
та часть сообщения, где про предварителшьную компиляцию.... уж очень на технологию NET похожа...
та часть сообщения, где про предварителшьную компиляцию.... уж очень на технологию NET похожа...
В поисковике набрал "технология NET" и почитал поверхностно. Понял пока мало, но не вижу прямой связи идей.
Я не говорю, что это ново. Просто одни создают технологии, а другие ими пользуются. Кому повезло больше?
[QUOTE=Sanya DLR]
И вот я подумал (пока в порядке бреда) а не будет ли жизнеспособной такая операционная система, где прикладные программы вообще не содержат исполняемого кода процессора. Что-то типа интерпретатора, только не как отдельный язык программирования (точнее - среда выполнения), а как единая многозадачная ОС (ностальгия по магиковскому бейсику).
Имеется конечный (но достаточный) набор команд (встроенный в ОС) и прикладная программа состоит исключительно из них (естественно, не в текстовом виде). При этом операционная система никогда не теряет контроля над процессором, а благодаря известному алгоритму выполнения каждой команды, она может оптимизировать паралельное выполнение программ при работе с ресурсами и т.п. Прикладная программа _в_принципе_ не может ничего нарушить.
[/QUOTE]
Наверное, нужно просто сказать Биллу, чтобы доработал платформу .NET :)
И вот я подумал (пока в порядке бреда) а не будет ли жизнеспособной такая операционная система, где прикладные программы вообще не содержат исполняемого кода процессора. Что-то типа интерпретатора, только не как отдельный язык программирования (точнее - среда выполнения), а как единая многозадачная ОС (ностальгия по магиковскому бейсику).
Имеется конечный (но достаточный) набор команд (встроенный в ОС) и прикладная программа состоит исключительно из них (естественно, не в текстовом виде). При этом операционная система никогда не теряет контроля над процессором, а благодаря известному алгоритму выполнения каждой команды, она может оптимизировать паралельное выполнение программ при работе с ресурсами и т.п. Прикладная программа _в_принципе_ не может ничего нарушить.
[/QUOTE]
Наверное, нужно просто сказать Биллу, чтобы доработал платформу .NET :)
[QUOTE=Sanya DLR]
...Мне все больше нравится идея многозадачности на основе одной наращиваемой задачи.
При запуске очередной программы система интеллектуально переплетет ее код с уже имеющимся и продолжит свое выполнение как единая программа...
[/QUOTE]
Такой интеллектуальный переплет будет немыслимо сложно реализовать, тебе не кажется? Это потребует анализа каждой команды, и даже не команды, а набора команд, для этого нужно будет выдвигать гипотезы о последствиях выполнения тех или иных последовательностей команд и доказывать их, т. е. нужна теория, прежде всего теория автоматов.
Вообще, имей в виду, что выполнение каждой команды сильно зависит от текущего контекста, т. е. состояния переменных и т. д. - анализ сильно усложняется и делается практически невозможным. Команда, организующая цикл от 1 до А, где А - переменная - количество итераций, как видим, зависит от значения переменной. А если эта переменная меняется внутри самого цикла? или возможен досрочный выход из цикла?
К тому же, нормальная вытесняющая мультизадачность имеет много преимуществ. Например, полная изоляция виртуального адресного пространства каждого процесса от других. Как ты хочешь реализовать подобные вещи, "вплетая" команды в единый поток и получая тем самым по сути одно адресное пространство? Как отделишь данные одной программы от данных другой?
Опишу более реальную альтернативу.
Современные ОС устроены так. Пользовательская прога не обращается напрямую к железу, например вирус не может обратиться к сетевой карте (чтобы распространить себя по сети) или жесткому диску, чтобы заразить другие файлы. Она обращается к функциям ядра, выполняющимся в более привилегированном режиме, чем пользовательская прога. Дело только в правах - нужно правильно настроить права доступа к ресурсам для каждой программы. В общем, это более-менее реализовано, скажем, в Виндах линейки NT / XP. Нужно только сильно расширить набор прав и давать права не пользователям, а программам (может, исполняемым модулям типа exe/dll?), к примеру дать антивирусу право обращаться к жесткому диску с целью модификации произвольных файлов, а некоей игрушке дать только право обращаться к своей ветке реестра, к своему каталогу для хранения и чтения данных, и только к некоторым устройствам. Тогда вирус, даже заразив игрушку, не сможет распространиться далее (по крайней мере из этой игрушки).
Попросту говоря, можно давать отдельное право на вызов каждой функции ядра, а также право на каждый файл, каталог, ветвь реестра и т. д.
А как будет в твоем случае? Откуда твоя "интеллектуальная" ОС узнает, вирус это или компилятор пишет какой-то код в исполнимый (или в твоем случае аналог исполнимого) файл? Троян обращается к сети или браузер?
Вижу только сложности и проблемы.
...Мне все больше нравится идея многозадачности на основе одной наращиваемой задачи.
При запуске очередной программы система интеллектуально переплетет ее код с уже имеющимся и продолжит свое выполнение как единая программа...
[/QUOTE]
Такой интеллектуальный переплет будет немыслимо сложно реализовать, тебе не кажется? Это потребует анализа каждой команды, и даже не команды, а набора команд, для этого нужно будет выдвигать гипотезы о последствиях выполнения тех или иных последовательностей команд и доказывать их, т. е. нужна теория, прежде всего теория автоматов.
Вообще, имей в виду, что выполнение каждой команды сильно зависит от текущего контекста, т. е. состояния переменных и т. д. - анализ сильно усложняется и делается практически невозможным. Команда, организующая цикл от 1 до А, где А - переменная - количество итераций, как видим, зависит от значения переменной. А если эта переменная меняется внутри самого цикла? или возможен досрочный выход из цикла?
К тому же, нормальная вытесняющая мультизадачность имеет много преимуществ. Например, полная изоляция виртуального адресного пространства каждого процесса от других. Как ты хочешь реализовать подобные вещи, "вплетая" команды в единый поток и получая тем самым по сути одно адресное пространство? Как отделишь данные одной программы от данных другой?
Опишу более реальную альтернативу.
Современные ОС устроены так. Пользовательская прога не обращается напрямую к железу, например вирус не может обратиться к сетевой карте (чтобы распространить себя по сети) или жесткому диску, чтобы заразить другие файлы. Она обращается к функциям ядра, выполняющимся в более привилегированном режиме, чем пользовательская прога. Дело только в правах - нужно правильно настроить права доступа к ресурсам для каждой программы. В общем, это более-менее реализовано, скажем, в Виндах линейки NT / XP. Нужно только сильно расширить набор прав и давать права не пользователям, а программам (может, исполняемым модулям типа exe/dll?), к примеру дать антивирусу право обращаться к жесткому диску с целью модификации произвольных файлов, а некоей игрушке дать только право обращаться к своей ветке реестра, к своему каталогу для хранения и чтения данных, и только к некоторым устройствам. Тогда вирус, даже заразив игрушку, не сможет распространиться далее (по крайней мере из этой игрушки).
Попросту говоря, можно давать отдельное право на вызов каждой функции ядра, а также право на каждый файл, каталог, ветвь реестра и т. д.
А как будет в твоем случае? Откуда твоя "интеллектуальная" ОС узнает, вирус это или компилятор пишет какой-то код в исполнимый (или в твоем случае аналог исполнимого) файл? Троян обращается к сети или браузер?
Вижу только сложности и проблемы.
[QUOTE=cheburator]Как отделишь данные одной программы от данных другой?[/QUOTE]
А зачем?
А зачем?
С Чебуратором я согласен. Нужно довать прова на программы. И даже есть идеи как все это будет работать. И как сделать так что-бы пользователь долго не вазился с настройками.
Но не так давно начял размышлять, как сделать чтобы игра шла отдельна. А музыка играла и не зависала.
Пришел к выводу, что для работы с мультимедиными устройствами. Нужно делать виртуальную прослойку. Пользовательская программа не должна работатьс устройствами на прямую а свои действия описывать по средством некоторого языка. Будь то как сделанно в OpenGl. Или как набор псевдо кодов. Которые должны либы инерпретироваться или компилироваться по ходу. Другими словами пользовательская программа создает псевдо код ядро его может интерпретировать илиже скомпилироать.
Хотя процессор позволяет выполнять код 3 уравня находясь в 0. Я немогу с уверенностью сказать, что этот код не будет захватывать процессорное время на долго. А следовательно это черевато потерей скорости обработки ввода вывода.
Вобщем получаем замкнутый круг. С одной стороны либы мы надеемся на коректность программы с другой стороны вобщем тоже.
Хотя вроде придумал. Можно сделать чтобы ОС вводила данные в заддонное место и сообщяла о зовершение ввода вывда. Но тогда это опятьже придется поручить ОС и воспользоваться некоторым обсрактым описанием. Но зато можно будет вынести как процесс 3 уровня.
Из всего выше сказанного. Либы мы доверяем пользовательским программам либы сами решаем проблемы недовая возможности пользовательской программе ни шагу сделать.
PS. Форум новые. А темы всплывают старые.
Но не так давно начял размышлять, как сделать чтобы игра шла отдельна. А музыка играла и не зависала.
Пришел к выводу, что для работы с мультимедиными устройствами. Нужно делать виртуальную прослойку. Пользовательская программа не должна работатьс устройствами на прямую а свои действия описывать по средством некоторого языка. Будь то как сделанно в OpenGl. Или как набор псевдо кодов. Которые должны либы инерпретироваться или компилироваться по ходу. Другими словами пользовательская программа создает псевдо код ядро его может интерпретировать илиже скомпилироать.
Хотя процессор позволяет выполнять код 3 уравня находясь в 0. Я немогу с уверенностью сказать, что этот код не будет захватывать процессорное время на долго. А следовательно это черевато потерей скорости обработки ввода вывода.
Вобщем получаем замкнутый круг. С одной стороны либы мы надеемся на коректность программы с другой стороны вобщем тоже.
Хотя вроде придумал. Можно сделать чтобы ОС вводила данные в заддонное место и сообщяла о зовершение ввода вывда. Но тогда это опятьже придется поручить ОС и воспользоваться некоторым обсрактым описанием. Но зато можно будет вынести как процесс 3 уровня.
Из всего выше сказанного. Либы мы доверяем пользовательским программам либы сами решаем проблемы недовая возможности пользовательской программе ни шагу сделать.
PS. Форум новые. А темы всплывают старые.
[QUOTE=Freeman]А зачем?[/QUOTE]
Хорошо, как программа будет обращаться к своим данным? не по адресу? по имени?
И как вместишь в одно адресное пространство (если оно у тебя 4-гигабайтное) кучу программ?
Хорошо, как программа будет обращаться к своим данным? не по адресу? по имени?
И как вместишь в одно адресное пространство (если оно у тебя 4-гигабайтное) кучу программ?
Чтобы пользователю легче было управляться с огромной кучей разных прав, можно, например, в дистрибутив ОС включать типовые наборы прав, скажем, для антивирусов, мультимедиа-программ, игрушек, средств разработки и т. д...
Можно предоставить пользователю самому группировать наборы прав в некие взаимосвязанные по смыслу пакеты. Т. е. типа одна большая галочка, которая включает сразу кучу взаимосвязанных по смыслу прав или выключает.
Или создавать готовые наборы прав.
В общем, дело фантазии.
Впрочем, мне кажется, эту тему надо выделить отдельно, иначе Sanya DLR обидится :)
Можно предоставить пользователю самому группировать наборы прав в некие взаимосвязанные по смыслу пакеты. Т. е. типа одна большая галочка, которая включает сразу кучу взаимосвязанных по смыслу прав или выключает.
Или создавать готовые наборы прав.
В общем, дело фантазии.
Впрочем, мне кажется, эту тему надо выделить отдельно, иначе Sanya DLR обидится :)
[QUOTE=cheburator]по имени?[/QUOTE]
Разумеется.
[QUOTE=cheburator]И как вместишь в одно адресное пространство (если оно у тебя 4-гигабайтное) кучу программ?[/QUOTE]
ОЗУ - не более чем кэш. Как оно будет организовано - вопрос проектирования этого кэша.
Разумеется.
[QUOTE=cheburator]И как вместишь в одно адресное пространство (если оно у тебя 4-гигабайтное) кучу программ?[/QUOTE]
ОЗУ - не более чем кэш. Как оно будет организовано - вопрос проектирования этого кэша.
[QUOTE=Freeman]
<Я>: По имени?
<Freeman>: Разумеется.
[/QUOTE]
А тебе не кажется, что искать размещение содержимого переменной по ее имени будет занимать достаточно значительное время при условии большого числа таких имен, каким бы оптимальным он ни был? А при условии частого обращения к переменным (а так оно и происходит) будет значительная потеря в быстродействии. Вместо одной команды mov eax, [esp+12] при извлечении локальной переменной ты будешь иметь продолжительные вызовы системных функций. Ну, если конечно будущая ОС не так критична к быстродействию...
И еще одно. Как ты гарантируешь, что если программа "А" создаст переменную "Х", и программа "Б" создаст такую же переменную, не возникнет конфликтов? Можно, конечно, идентифицировать не только по имени, но и по идентификатору программы. В таком случае не проще ли просто выделить отдельные адресные пространства?
...
В общем, без конкретизации вашей концепции возникает много вопросов, а так - сама идея конечно же интересная.
<Я>: По имени?
<Freeman>: Разумеется.
[/QUOTE]
А тебе не кажется, что искать размещение содержимого переменной по ее имени будет занимать достаточно значительное время при условии большого числа таких имен, каким бы оптимальным он ни был? А при условии частого обращения к переменным (а так оно и происходит) будет значительная потеря в быстродействии. Вместо одной команды mov eax, [esp+12] при извлечении локальной переменной ты будешь иметь продолжительные вызовы системных функций. Ну, если конечно будущая ОС не так критична к быстродействию...
И еще одно. Как ты гарантируешь, что если программа "А" создаст переменную "Х", и программа "Б" создаст такую же переменную, не возникнет конфликтов? Можно, конечно, идентифицировать не только по имени, но и по идентификатору программы. В таком случае не проще ли просто выделить отдельные адресные пространства?
...
В общем, без конкретизации вашей концепции возникает много вопросов, а так - сама идея конечно же интересная.
[QUOTE=cheburator]А тебе не кажется, что искать размещение содержимого переменной по ее имени будет занимать достаточно значительное время при условии большого числа таких имен, каким бы оптимальным он ни был?[/QUOTE]
Зависит от кривости рук при реализации. Программе совершенно необязательно обращаться к переменным по имени. Данные и переменные - несколько разные вещи, не считаешь? Когда под рукой несколько сотен метров ОЗУ, надо быть непроходимым болваном, чтобы при загрузке кода в память не разрешить имена в адреса для данного сеанса выполнения.
[QUOTE=cheburator]Можно, конечно, идентифицировать не только по имени, но и по идентификатору программы.[/QUOTE]
Не можно, а нужно. Почти так делает Java, например.
[QUOTE=cheburator]В таком случае не проще ли просто выделить отдельные адресные пространства?[/QUOTE]
Отделяй мух от котлет. Разработка программы на высокоуровневом ЯП - описание решения задачи в прикладных терминах. Как при выполнении кода поступит система - внутреннее дело самой системы.
Если системе, скажем, для поддержки унаследованных программ нужно разделение на адресные пространства - да пусть будет, жалко что ли? Но если такое разделение требуется для прикладной программы - приплыли, товарищи. Может, вирусы начнем искать? Или уязвимости?
Зависит от кривости рук при реализации. Программе совершенно необязательно обращаться к переменным по имени. Данные и переменные - несколько разные вещи, не считаешь? Когда под рукой несколько сотен метров ОЗУ, надо быть непроходимым болваном, чтобы при загрузке кода в память не разрешить имена в адреса для данного сеанса выполнения.
[QUOTE=cheburator]Можно, конечно, идентифицировать не только по имени, но и по идентификатору программы.[/QUOTE]
Не можно, а нужно. Почти так делает Java, например.
[QUOTE=cheburator]В таком случае не проще ли просто выделить отдельные адресные пространства?[/QUOTE]
Отделяй мух от котлет. Разработка программы на высокоуровневом ЯП - описание решения задачи в прикладных терминах. Как при выполнении кода поступит система - внутреннее дело самой системы.
Если системе, скажем, для поддержки унаследованных программ нужно разделение на адресные пространства - да пусть будет, жалко что ли? Но если такое разделение требуется для прикладной программы - приплыли, товарищи. Может, вирусы начнем искать? Или уязвимости?
[QUOTE=Freeman]Программе совершенно необязательно обращаться к переменным по имени. Когда под рукой несколько сотен метров ОЗУ, надо быть непроходимым болваном, чтобы при загрузке кода в память не разрешить имена в адреса для данного сеанса выполнения.[/QUOTE]
Сдаюсь :)
Ну, это и есть та конкретизация, про которую я писал выше.
Ну и как, есть серьезные планы по реализации или это только идея?
Сдаюсь :)
Ну, это и есть та конкретизация, про которую я писал выше.
Ну и как, есть серьезные планы по реализации или это только идея?
[QUOTE=cheburator]
Ну и как, есть серьезные планы по реализации или это только идея?[/QUOTE]
Есть.
Ну и как, есть серьезные планы по реализации или это только идея?[/QUOTE]
Есть.
Дадите на бета-тестирование? :)
[QUOTE=cheburator]Дадите на бета-тестирование? :)[/QUOTE]
Планы?
Планы?
[QUOTE=Freeman]Планы?[/QUOTE]
Продукт
Продукт
[QUOTE=cheburator]Продукт[/QUOTE]
Если ему суждено быть реализованым, рано или поздно появится в открытом доступе.
Если ему суждено быть реализованым, рано или поздно появится в открытом доступе.