Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
Ссылочку о трехстековой ВМстоит подшить сюда.
Ссылочку о [url=http://fforum.winglion.ru/viewtopic.php?t=2375]трехстековой ВМ[/url]стоит подшить сюда.
|
|
|
|
Добавлено: Сб янв 16, 2010 21:51 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): mOleg писал(а):(хотя интерпретатор ШК таки скушатет много времени). Это основной (исходно закладываемый) недостаток, причем практически никак не сглаживаемый возможной оптимизацией.
долго думал, и не соглашусь. Как раз есть место для оптимизации.
Можно код компилировать в пространство ядра, если, например, он по времени критичен.
Просто такой код нельзя будет править из пользовательского процесса, но и это обходимо.
[quote="chess"]mOleg писал(а):(хотя интерпретатор ШК таки скушатет много времени). Это основной (исходно закладываемый) недостаток, причем практически никак не сглаживаемый возможной оптимизацией.[/quote]
долго думал, и не соглашусь. Как раз есть место для оптимизации.
Можно код компилировать в пространство ядра, если, например, он по времени критичен.
Просто такой код нельзя будет править из пользовательского процесса, но и это обходимо.
|
|
|
|
Добавлено: Пн июн 02, 2008 22:26 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): А в этом случае не надо ли забыть о бинарной переносимости кода?
нет, не надо. Так как речь будет идти только о PFA частях, которые и так должны быть в коде описаны.
Под бинарной переносимостью кода я подразумевал именно ту часть, которая находится в пользовательском пространстве. Там не будет никаких завязок на ассемблерный код, и никаких завязок на адреса.
[quote="chess"]А в этом случае не надо ли забыть о бинарной переносимости кода?[/quote]
нет, не надо. Так как речь будет идти только о PFA частях, которые и так должны быть в коде описаны.
Под бинарной переносимостью кода я подразумевал именно ту часть, которая находится в пользовательском пространстве. Там не будет никаких завязок на ассемблерный код, и никаких завязок на адреса.
|
|
|
|
Добавлено: Чт май 08, 2008 11:58 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): я же привел пример, когда в таблице не ссылка находится а код, тогда получается быстрее:
MOV regg , # 'pfa JMP # 'pfa
А в этом случае не надо ли забыть о бинарной переносимости кода?
[quote="mOleg"]я же привел пример, когда в таблице не ссылка находится а код, тогда получается быстрее:
MOV regg , # 'pfa JMP # 'pfa [/quote]
А в этом случае не надо ли забыть о бинарной переносимости кода?
|
|
|
|
Добавлено: Чт май 08, 2008 11:39 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Тема интересна, но под несколько иным углом зрения.
Во встраиваемых системах, основанных на микроконтроллерах гарвардской архитектуры имеется несколько различных адресных пространств ( ОЗУ, флеш память команд, пространство ввода-вывода, флеш память во внешнем чипе, и тд), требующих различных методов доступа. Если озадачиться возможностью исполнять шитый код из различных адресных пространств, то потребуется иметь для каждой области свой собственный адресный интерпретатор ( возможно через векторное слово). На первый взгляд выглядит симпатично, но сложновато ( либо удваивать ячеки в стеке возвратов, либо выделять дополнительный стек под указатель на адресный интерпретатор) что ведет к потере производительности...
Возможно я чегото недопонимаю
Тема интересна, но под несколько иным углом зрения.
Во встраиваемых системах, основанных на микроконтроллерах гарвардской архитектуры имеется несколько различных адресных пространств ( ОЗУ, флеш память команд, пространство ввода-вывода, флеш память во внешнем чипе, и тд), требующих различных методов доступа. Если озадачиться возможностью исполнять шитый код из различных адресных пространств, то потребуется иметь для каждой области свой собственный адресный интерпретатор ( возможно через векторное слово). На первый взгляд выглядит симпатично, но сложновато ( либо удваивать ячеки в стеке возвратов, либо выделять дополнительный стек под указатель на адресный интерпретатор) что ведет к потере производительности...
Возможно я чегото недопонимаю
|
|
|
|
Добавлено: Чт май 08, 2008 09:41 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Mihail писал(а): вопрос писал(а):Если делать ОС на основе ФВМ, то вопрос о защищённости возникает сам собою. Чем недостаточны аппаратные средства защиты? они достаточны, но не везде одинаковые, сложнее предложенного механизма. Я же предлагаю механизм, который подойдет и дляя 16битного проца, и для 64 битного, необходимо лишь, чтобы процессор мог более-менее сложные методы адресации поддерживать. Mihail писал(а): mOleg писал(а):ну не знаю, вирусописателей в мире нет, например. Защита от вирусов в основном относится к файловой системе. До вирусов еще дожить надо. Я бы хотел увидеть вирус к своей ОС. сейчас создавать с нуля ОС и не предвидеть методов защиты бессмысленно. А вносить защиту поверх когда прижмет и сложнее, и глупее. Mihail писал(а): mOleg писал(а):Mihail писал(а):
Защищенная ВМ, мною давно реализована. описание в студию, пожалуйста.
Если кому надо пусть задает вопросы. Могу сказать, что CFA в моей машине содержит индекс к массиву ссылок на функции. о, так тут то же самое, но главное, разделены поля кода и данных Mihail писал(а): Интересной особенностью является то, что она сочетает в себе косвенный и подпрограммный шитый коды. Это обеспечивает совместимость с обоими видами форт-систем. Ресурсы (особенно память) используются весьма рационально. ничто не мешает в предложенном мною варианте использовать несколько видов ШК. Даже, я бы сказал логично в ядре пользовать заоптимизированный код типа СПФовского, а в пользовательском пространстве процесса, предложенный вариант TTC. Приятной особенностью данного подхода является переносимость бинарного кода, что тоже не маловажно, более того, даже пересборка ядра не должна приводить к перекомпиляции кода пользовательских приложений. Mihail писал(а): mOleg писал(а):моя ВМ получается полностью изолированной от реального процессора. Для изоляции relf достаточно организовать виртуальную память. да, так ведь то, что я описал и является частью менеджера памяти процесса. Mihail писал(а): Т.е. просто все функции работающие с адресами памяти, следует заменить на функции работающие с индексом в массиве.
об этом и речь, только я зашел со стороны организации ШК, а не со стороны уже существующей системы.
[quote="Mihail"]вопрос писал(а):Если делать ОС на основе ФВМ, то вопрос о защищённости возникает сам собою. Чем недостаточны аппаратные средства защиты?[/quote] они достаточны, но не везде одинаковые, сложнее предложенного механизма. Я же предлагаю механизм, который подойдет и дляя 16битного проца, и для 64 битного, необходимо лишь, чтобы процессор мог более-менее сложные методы адресации поддерживать.
[quote="Mihail"]mOleg писал(а):ну не знаю, вирусописателей в мире нет, например. Защита от вирусов в основном относится к файловой системе. До вирусов еще дожить надо. Я бы хотел увидеть вирус к своей ОС.[/quote] сейчас создавать с нуля ОС и не предвидеть методов защиты бессмысленно. А вносить защиту поверх когда прижмет и сложнее, и глупее.
[quote="Mihail"]mOleg писал(а):Mihail писал(а):
Защищенная ВМ, мною давно реализована. описание в студию, пожалуйста.
Если кому надо пусть задает вопросы. Могу сказать, что CFA в моей машине содержит индекс к массиву ссылок на функции.[/quote] о, так тут то же самое, но главное, разделены поля кода и данных[quote="Mihail"]Интересной особенностью является то, что она сочетает в себе косвенный и подпрограммный шитый коды. Это обеспечивает совместимость с обоими видами форт-систем. Ресурсы (особенно память) используются весьма рационально.[/quote] ничто не мешает в предложенном мною варианте использовать несколько видов ШК. Даже, я бы сказал логично в ядре пользовать заоптимизированный код типа СПФовского, а в пользовательском пространстве процесса, предложенный вариант TTC. Приятной особенностью данного подхода является переносимость бинарного кода, что тоже не маловажно, более того, даже пересборка ядра не должна приводить к перекомпиляции кода пользовательских приложений.
[quote="Mihail"]mOleg писал(а):моя ВМ получается полностью изолированной от реального процессора. Для изоляции relf достаточно организовать виртуальную память.[/quote] да, так ведь то, что я описал и является частью менеджера памяти процесса. [quote="Mihail"]Т.е. просто все функции работающие с адресами памяти, следует заменить на функции работающие с индексом в массиве.[/quote]
об этом и речь, только я зашел со стороны организации ШК, а не со стороны уже существующей системы.
|
|
|
|
Добавлено: Чт май 08, 2008 09:16 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): вопрос писал(а):Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество" Это относилось к другой ФВМ, а не к предложенной.
вообще, можно ряд слов компилировать в другую облась (за пределами пользовательского пространства), только тогда будет сложно поддерживать трюки с модификацией кода.
[quote="chess"]вопрос писал(а):Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество" Это относилось к другой ФВМ, а не к предложенной.[/quote]
вообще, можно ряд слов компилировать в другую облась (за пределами пользовательского пространства), только тогда будет сложно поддерживать трюки с модификацией кода.
|
|
|
|
Добавлено: Чт май 08, 2008 09:06 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): вопрос писал(а):Почему скушает - понимаю, но вот отчего "никак не сглаживаемый возможной оптимизацией" - не понимаю
mOleg писал(а):NEXT для такого типа ШК будет несколько более сложным: Код:
MOV index, [IP] ADD IP , # CELL MOV addr, [index*16+i_table+off_codebase] MOV temp, [index*16+i_table+off_vmcode] JMP temp
Тут просто нечего оптимизировать.
я же привел пример, когда в таблице не ссылка находится а код, тогда получается быстрее:
MOV regg , # 'pfa
JMP # 'pfa
только табличка будет подлиннее.
Такой подход хорош еще и тем, что можно штатно перехватывать подкачку кода из свопа, или блокировать выполнение кода, который не должен исполняться.
[quote="chess"]вопрос писал(а):Почему скушает - понимаю, но вот отчего "никак не сглаживаемый возможной оптимизацией" - не понимаю
mOleg писал(а):NEXT для такого типа ШК будет несколько более сложным: Код:
MOV index, [IP] ADD IP , # CELL MOV addr, [index*16+i_table+off_codebase] MOV temp, [index*16+i_table+off_vmcode] JMP temp
Тут просто нечего оптимизировать.[/quote]
я же привел пример, когда в таблице не ссылка находится а код, тогда получается быстрее:
MOV regg , # 'pfa
JMP # 'pfa
только табличка будет подлиннее.
Такой подход хорош еще и тем, что можно штатно перехватывать подкачку кода из свопа, или блокировать выполнение кода, который не должен исполняться.
|
|
|
|
Добавлено: Чт май 08, 2008 09:03 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Mihail писал(а): Могу сказать, что CFA в моей машине содержит индекс к массиву ссылок на функции.
Как и предполагалось ...
[quote="Mihail"] Могу сказать, что CFA в моей машине содержит индекс к массиву ссылок на функции. [/quote] Как и предполагалось ...
|
|
|
|
Добавлено: Вт май 06, 2008 21:21 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): Если делать ОС на основе ФВМ, то вопрос о защищённости возникает сам собою. Чем недостаточны аппаратные средства защиты? mOleg писал(а): ну не знаю, вирусописателей в мире нет, например. Защита от вирусов в основном относится к файловой системе. До вирусов еще дожить надо. Я бы хотел увидеть вирус к своей ОС. mOleg писал(а): Mihail писал(а): Защищенная ВМ, мною давно реализована.
описание в студию, пожалуйста. Если кому надо пусть задает вопросы. Могу сказать, что CFA в моей машине содержит индекс к массиву ссылок на функции. mOleg писал(а): Mihail писал(а): Сейчас я бы сделал на базе http://devbiol.zoo.uwo.ca/~kvt/relf-0.2.zipв чем ее преимущества? Главное, что она релизована, отлажена и многоим освоена. Интересной особенностью является то, что она сочетает в себе косвенный и подпрограммный шитый коды. Это обеспечивает совместимость с обоими видами форт-систем. Ресурсы (особенно память) используются весьма рационально. mOleg писал(а): моя ВМ получается полностью изолированной от реального процессора.
Для изоляции relf достаточно организовать виртуальную память.
Т.е. просто все функции работающие с адресами памяти, следует заменить на функции работающие с
индексом в массиве.
[quote="вопрос"]Если делать ОС на основе ФВМ, то вопрос о защищённости возникает сам собою.[/quote]
Чем недостаточны аппаратные средства защиты?
[quote="mOleg"]ну не знаю, вирусописателей в мире нет, например.[/quote]
Защита от вирусов в основном относится к файловой системе. До вирусов еще дожить надо. Я бы хотел увидеть вирус к своей ОС.
[quote="mOleg"]Mihail писал(а): Защищенная ВМ, мною давно реализована.
описание в студию, пожалуйста.[/quote]
Если кому надо пусть задает вопросы. Могу сказать, что CFA в моей машине содержит индекс к массиву ссылок на функции.
[quote="mOleg"]Mihail писал(а): Сейчас я бы сделал на базе http://devbiol.zoo.uwo.ca/~kvt/relf-0.2.zip
в чем ее преимущества? [/quote]
Главное, что она релизована, отлажена и многоим освоена. Интересной особенностью является то, что она сочетает в себе косвенный и подпрограммный шитый коды. Это обеспечивает совместимость с обоими видами форт-систем. Ресурсы (особенно память) используются весьма рационально.
[quote="mOleg"]моя ВМ получается полностью изолированной от реального процессора.[/quote]
Для изоляции relf достаточно организовать виртуальную память.
Т.е. просто все функции работающие с адресами памяти, следует заменить на функции работающие с
индексом в массиве.
|
|
|
|
Добавлено: Вт май 06, 2008 17:09 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): вопрос писал(а): Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество" Это относилось к другой ФВМ, а не к предложенной. Мне кажется, такой способ оптимизации непринципиален, для какой ВМ
[quote="chess"][quote="вопрос"]Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество"[/quote] Это относилось к другой ФВМ, а не к предложенной.[/quote] Мне [i]кажется[/i], такой способ оптимизации непринципиален, для какой ВМ
|
|
|
|
Добавлено: Вт май 06, 2008 11:24 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество"
Это относилось к другой ФВМ, а не к предложенной.
[quote="вопрос"]Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество"[/quote]
Это относилось к другой ФВМ, а не к предложенной.
|
|
|
|
Добавлено: Вт май 06, 2008 11:07 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): mOleg писал(а): NEXT для такого типа ШК будет несколько более сложным: Код: MOV index, [IP] ADD IP , # CELL MOV addr, [index*16+i_table+off_codebase] MOV temp, [index*16+i_table+off_vmcode] JMP temp Тут просто нечего оптимизировать.
Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество"
[quote="chess"] [quote="mOleg"]NEXT для такого типа ШК будет несколько более сложным: Код: MOV index, [IP] ADD IP , # CELL MOV addr, [index*16+i_table+off_codebase] MOV temp, [index*16+i_table+off_vmcode] JMP temp [/quote] Тут просто нечего оптимизировать.[/quote]
Я видимо что-то не так помню - была же тема, не успел поучаствовать - можно "сливать" слова (делать из нескольких одно), это не упростит NEXT , но уменьшит их "количество"
|
|
|
|
Добавлено: Вт май 06, 2008 10:10 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): Почему скушает - понимаю, но вот отчего "никак не сглаживаемый возможной оптимизацией" - не понимаю mOleg писал(а): NEXT для такого типа ШК будет несколько более сложным: Код:
MOV index, [IP] ADD IP , # CELL MOV addr, [index*16+i_table+off_codebase] MOV temp, [index*16+i_table+off_vmcode] JMP temp
Тут просто нечего оптимизировать.
[quote="вопрос"]Почему скушает - понимаю, но вот отчего "никак не сглаживаемый возможной оптимизацией" - не понимаю[/quote]
[quote="mOleg"]NEXT для такого типа ШК будет несколько более сложным: Код:
MOV index, [IP] ADD IP , # CELL MOV addr, [index*16+i_table+off_codebase] MOV temp, [index*16+i_table+off_vmcode] JMP temp [/quote]
Тут просто нечего оптимизировать.
|
|
|
|
Добавлено: Вт май 06, 2008 09:40 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): mOleg писал(а): (хотя интерпретатор ШК таки скушатет много времени). Это основной (исходно закладываемый) недостаток, причем практически никак не сглаживаемый возможной оптимизацией. Есть же и другие способы защиты ОС так впрямую не затрагивающие один из основных параметров ОС - быстродействие. Почему скушает - понимаю, но вот отчего "никак не сглаживаемый возможной оптимизацией" - не понимаю
[quote="chess"][quote="mOleg"](хотя интерпретатор ШК таки скушатет много времени). [/quote] Это основной (исходно закладываемый) недостаток, причем практически никак не сглаживаемый возможной оптимизацией. Есть же и другие способы защиты ОС так впрямую не затрагивающие один из основных параметров ОС - быстродействие.[/quote]Почему скушает - понимаю, но вот отчего "никак не сглаживаемый возможной оптимизацией" - не понимаю
|
|
|
|
Добавлено: Вт май 06, 2008 09:31 |
|
|
|
|