Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 19:34

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Вопрос по созданию Форт ОС
Автор Сообщение
  Заголовок сообщения:   Ответить с цитатой
Mihail писал(а):
Зачем тебе эти тайны?

для того, чтобы было поменьше флуда
для того, чтобы не позориться, потому что пока все обсуждения выглядят очень примитивно.
Сообщение Добавлено: Пн дек 22, 2008 14:03
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
на уровне, недоступном пользовательскому процессу, иначе невозможно обеспечить безопасность и устойчивость системы.


Для безопасности существуют аппаратные средства защиты (достаточно закрыть область ядра для записи).
К тому-же существует куча виртуальных форт-машин да и написать еще одну большого труда не составляет.

mOleg писал(а):
Но ядро должно быть статичным.


Если машина принадлежит пользователю, он в праве делать с ней( и с ПО на ней) все, что хочет.
Лично я хочу иметь прямой доступ к аппаратным средствам. В защищенном режиме я бы хотел иметь
максимально возможную совместимость с Форт-системой работающей в ядре.

mOleg писал(а):
Виртуальная машина должна быть достаточно быстрой в любом случае.


Да пусть хоть она вообще не работает. Как выглядела-бы прикладная программа, если-бы система работала?
При использовании индексов вместо адресов нет смысле отказываться от плоской памяти.
Поскольку работе программ работающих с индексами массивов данных, наличие стандартных средств ничем не мешает.

mOleg писал(а):
более подробно могу ответить только через личку


Зачем тебе эти тайны?
Сообщение Добавлено: Пн дек 22, 2008 13:53
  Заголовок сообщения:   Ответить с цитатой
Mihail, загляните пожалуйста в личку к себе!

Mihail писал(а):
mOleg писал(а):Быстро такой режим будет работать только близко к железу.
На данном этапе, о быстродействии следует думать в последнюю очередь

и да и нет.

Mihail писал(а):
mOleg писал(а):Какие проблемы возникнут? (вопрос не праздный)
Если дополнительный индекс требуется каждый раз при обращении к памяти, это усложняет программу.

в смысле усложняет манипуляции на стеке данных?
кстати, не все адреса будут двойные. Например, литералы, литеральные строки, данные внутри слова не потребуют двух чисел.

Mihail писал(а):
Как я понял, создание/удаление индексов происходит где-то не нижнем уровне.

на уровне, недоступном пользовательскому процессу, иначе невозможно обеспечить безопасность и устойчивость системы.

Mihail писал(а):
Т.е. система себя не выражает, система ограничена по расширению (на уровне пользователя).

нет, не ограничена. Но ядро должно быть статичным.
А система это ядро(не обязательно одно) + множество пользовательских процессов, взаимодействующих между собой с помощью асинхронных сообщений, разделяемых блоков памяти, и слов из базового словаря, доступного всем пользовательским процессам.

Mihail писал(а):
Или в этом случае, тормоза такие большие, что ничего не продемонстрировать?

а вот это надо выяснять! Виртуальная машина должна быть достаточно быстрой в любом случае.

Mihail писал(а):
Не вижу я никаких проблем ни с файлами ни с выделением дополнительной памяти.

не видишь ты, я вижу ;)

Mihail писал(а):
Что еще твоя система решает?

у меня нет системы, а есть набор увязанных между собой идей (в основном, но есть и неувязанные).
более подробно могу ответить только через личку
Сообщение Добавлено: Сб дек 20, 2008 22:12
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
Быстро такой режим будет работать только близко к железу.


На данном этапе, о быстродействии следует думать в последнюю очередь.

mOleg писал(а):
Какие проблемы возникнут? (вопрос не праздный)


Если дополнительный индекс требуется каждый раз при обращении к памяти,
это усложняет программу. Тем-более с польской записью с манипуляцией на стеке.
Как я понял, создание/удаление индексов происходит где-то не нижнем уровне.
Т.е. система себя не выражает, система ограничена по расширению (на уровне пользователя).
Вообще, не будь проблем, система давно-бы была реализована (в качестве приложения)
с кучей примеров демонстрирующих как все замечательно. Или в этом случае, тормоза такие большие,
что ничего не продемонстрировать?

mOleg писал(а):
Я лишь говорю, что очень органично такая адресация может вписаться в форт и убрать кучу проблем.


Не вижу я никаких проблем ни с файлами ни с выделением дополнительной памяти.
Что еще твоя система решает?
Сообщение Добавлено: Сб дек 20, 2008 14:26
  Заголовок сообщения:   Ответить с цитатой
где-то была тут тема, что производительность - отчасти миф, можно порассуждать и отражать в память те регистры, к которым обращение реже, кроме того, насколько тормоза
(а постоянный вызов АPI не тормоза?) ведь такие тормоза есть в любой системе
Сообщение Добавлено: Пт дек 19, 2008 23:11
  Заголовок сообщения:   Ответить с цитатой
вопрос писал(а):
Я думаю, это очень удачно, вместо того, чтобы мучиться с "укладыванием" ВМ в регистры, предусмотреть виртуальные регистры в памяти

и очень сильно потерять в скорости...
совсем уж тормоза-то не хочется иметь
Сообщение Добавлено: Пт дек 19, 2008 23:05
  Заголовок сообщения:   Ответить с цитатой
Цитата:
вы не правильно поняли. Регистры нужны для огранизации ФВМ.
Те же указатели стеков, временные регистры, кеширующий вершину стека регистр.
я рассужда. по аналогии с тем, как органищованы некоторые (может все) ассемблерные отладчики. Весь состав регистров копируется в некоторую структуру в памяти, (следует заметить, работа с которой безупречно отлажена и протестирована) и сами регистры свободны для других функций - например для вывода данных самого отладчика, потом всё кладётся обратно и делается следующий шаг ...
Я думаю, это очень удачно, вместо того, чтобы мучиться с "укладыванием" ВМ в регистры, предусмотреть виртуальные регистры в памяти

сама задача построения ВМ станет проще
Сообщение Добавлено: Пт дек 19, 2008 22:57
  Заголовок сообщения:   Ответить с цитатой
вопрос писал(а):
фортеру ли это говорить, доп. стек, куда складывается содержание регистров перед использованием... или даже переменные с постоянными адресами...

вы не правильно поняли. Регистры нужны для огранизации ФВМ.
Те же указатели стеков, временные регистры, кеширующий вершину стека регистр.
Сообщение Добавлено: Пт дек 19, 2008 22:00
  Заголовок сообщения:   Ответить с цитатой
Цитата:
не совсем так. Быстро такой режим будет работать только близко к железу. Реализовать-то модель можно, но регистров проца не хватает 8(
:) фортеру ли это говорить, доп. стек, куда складывается содержание регистров перед использованием... или даже переменные с постоянными адресами...
Сообщение Добавлено: Пт дек 19, 2008 21:29
  Заголовок сообщения:   Ответить с цитатой
Mihail писал(а):
mOleg писал(а):представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам)
В х86, в страничном режиме, поле старших разрядов и являются индексами.

да, это я знаю. Но количество блоков ограничено в таком режиме, что не очень удачно.

Mihail писал(а):
mOleg писал(а):вероятно вы не поняли о чем речь, судя по вашему замечанию
В принципе то я понимаю, чего ты хочешь (как мне кажется).
Идея-то далеко не нова.

А я и не утверждаю, что идея нова! Я лишь говорю, что очень органично такая адресация может вписаться в форт и убрать кучу проблем.

Mihail писал(а):
По моему, при попытки реализовать проблем возникает больше чем решается.

Какие проблемы возникнут? (вопрос не праздный)

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

не совсем так. Быстро такой режим будет работать только близко к железу. Реализовать-то модель можно, но регистров проца не хватает 8(
Сообщение Добавлено: Пт дек 19, 2008 17:28
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам)


В х86, в страничном режиме, поле старших разрядов и являются индексами.

mOleg писал(а):
вероятно вы не поняли о чем речь, судя по вашему замечанию


В принципе то я понимаю, чего ты хочешь (как мне кажется).
Идея-то далеко не нова. По моему, при попытки реализовать проблем возникает больше
чем решается. А главное, причем тут ОС? (тем более ядро ОС).
На уровне пользователей это можно реализовать практически в рамках любой ОС.
Сообщение Добавлено: Пт дек 19, 2008 17:18
  Заголовок сообщения:   Ответить с цитатой
Mihail писал(а):
mOleg писал(а):Код:
LEA EAX, [EDI] [EAX]
MOV EAX, [EAX]
Да надо-бы
MOV EAX, [EDI] [EAX]

шанс исправить исходники СПФ ;)
Сообщение Добавлено: Пт дек 19, 2008 17:15
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
chess писал(а):
mOleg писал(а):это как раз неудобно, потому что при изменении размера блока часто должно имениться расположение блока в памяти. То есть блок начинает по памяти "ездить" и это уже проблема, особенно для исполнимого кода.

Скажи как такое может понадобиться/получиться именно для исполнимого кода? По мне так без этого можно обойтись.
Как вариант связка через Jmp-ы работает и ничего в этом извратного не вижу. Просто необходимости в этом нет.

еще как может. Потом, ведь речь не только о исполнимом коде, а и о данных.
Ты сам говоришь сначала о том, что надо работать с файлами как с обычными словами, а потом сам говоришь, что не понимаешь для чего это нужно

Я говорил о словах-файлах с данными, а слова-файлы с исполнимым кодом в Форт-ОС не нужны. Форт-слова для замены файлов, да имеют код, который располагается в начале блока памяти и этот код должен модифицировать дескриптор этого слова-файла при уменьшении/увеличении размера слова-файла, когда он размазывается/разрывается по памяти. Код в начальном блоке при этом по размеру не меняется.
mOleg писал(а):
chess писал(а):
mOleg писал(а):Например, можно посмотреть как сделаны USER переменные в СПФ и помечтать о том, чтобы использовать сегментный регистр для адресации этой области.
Ну разделена память для потоков с помощью регистра EDI, вроде нормально все, что, можно сделать лучше/проще что-ли?

Код:

POP EAX
MOV EAX, [EAX]
LEA EAX, [EDI] [EAX]
MOV EAX, [EAX]


а могло быть и так:
Код:

POP EAX
MOV EAX, [EAX]
MOV EAX, FS: [EAX]

либо еще проще, если смещение будет в коде прямо, а не по IP указателю.
замечу, что освобождается регистр, причем важный регистр!

Инструкции MOV EAX, FS: [EAX] не существует, надо сначала исполнить инструкцию LFS(загрузить из памяти полный указатель) и эту инструкцию никак не миновать, так что вариант с LEA EAX, [EDI] [EAX] проще.
Что касается использования регистра EDI, то это не страшно, так регистров для форта хватает, а при переходе на
64-разряда их будет вообще с избытком.
mOleg писал(а):
chess писал(а):
mOleg писал(а):Или сделать нормальные dll в винде, чтобы код дллы не грузился несколько раз, и чтобы не настривались при загрузке адреса (ведь уже в сегментной модели памяти это лишнее).
Места для DLL в ядре ОС не вижу, там они не нужны совсем, тоже самое касается приложений - все на основе словарных структур.
Загрузку приложений лучше делать через компиляцию их исходников "на лету" - и это можно делать очень быстро.

тогда не надо говорить об ОС, это недоОС, просто очередная форт-система на голом железе, которых есть достаточно и так.

Во-первых назовите хотя бы одну, которая тянет хотя-бы на недоФорт-ОС, с возможностью ее расширения.
Во-вторых речь идет о Форт-ОС, все остальное, заимствующее структуры существующих ОС(DLL, EXE, файлы) мне неинтересны. Это будет уже не ФортОС, а просто другая ОС, которых кстати как раз очень много разных. Проще просто
сделать форт-систему, например, под QNX(очень быстрая и надежная ОС - все ядро в кэш помещается) и работать.
Сообщение Добавлено: Пт дек 19, 2008 17:15
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
Код:

LEA EAX, [EDI] [EAX]
MOV EAX, [EAX]


Да надо-бы

MOV EAX, [EDI] [EAX]
Сообщение Добавлено: Пт дек 19, 2008 16:53
  Заголовок сообщения:   Ответить с цитатой
Mihail писал(а):
mOleg писал(а):Надо только отказаться от плоской модели памяти, которая, имхо, дико неудобная, в пользу блочной памяти (то есть по сути хипа, хотя это и усложнит форт и приблизит его к лиспу с постскриптом).
Чем тебе плоская память не блочная? Просто считай старшие разряды номером блока.

абсолютно ничем ;)
такая память не может расти в размере.
вероятно вы не поняли о чем речь, судя по вашему замечанию.
а речь идет о том, чтобы представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам):
это позволяет менять размер любого блока, перемещать его, удалять и пр. без какого бы то ни было влияния на соседние блоки, и на логику работы программы. В таком случае можно одновременно компилировать несколько слов или даже не соблюдать порядок компилирования слов без особых проблем.
Сообщение Добавлено: Пт дек 19, 2008 15:23

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB