Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
Mihail писал(а): Зачем тебе эти тайны?
для того, чтобы было поменьше флуда
для того, чтобы не позориться, потому что пока все обсуждения выглядят очень примитивно.
[quote="Mihail"]Зачем тебе эти тайны?[/quote]
для того, чтобы было поменьше флуда
для того, чтобы не позориться, потому что пока все обсуждения выглядят очень примитивно.
|
|
|
|
Добавлено: Пн дек 22, 2008 14:03 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): на уровне, недоступном пользовательскому процессу, иначе невозможно обеспечить безопасность и устойчивость системы. Для безопасности существуют аппаратные средства защиты (достаточно закрыть область ядра для записи). К тому-же существует куча виртуальных форт-машин да и написать еще одну большого труда не составляет. mOleg писал(а): Но ядро должно быть статичным. Если машина принадлежит пользователю, он в праве делать с ней( и с ПО на ней) все, что хочет. Лично я хочу иметь прямой доступ к аппаратным средствам. В защищенном режиме я бы хотел иметь максимально возможную совместимость с Форт-системой работающей в ядре. mOleg писал(а): Виртуальная машина должна быть достаточно быстрой в любом случае. Да пусть хоть она вообще не работает. Как выглядела-бы прикладная программа, если-бы система работала? При использовании индексов вместо адресов нет смысле отказываться от плоской памяти. Поскольку работе программ работающих с индексами массивов данных, наличие стандартных средств ничем не мешает. mOleg писал(а): более подробно могу ответить только через личку
Зачем тебе эти тайны?
[quote="mOleg"]на уровне, недоступном пользовательскому процессу, иначе невозможно обеспечить безопасность и устойчивость системы. [/quote]
Для безопасности существуют аппаратные средства защиты (достаточно закрыть область ядра для записи). К тому-же существует куча виртуальных форт-машин да и написать еще одну большого труда не составляет.
[quote="mOleg"]Но ядро должно быть статичным. [/quote]
Если машина принадлежит пользователю, он в праве делать с ней( и с ПО на ней) все, что хочет. Лично я хочу иметь прямой доступ к аппаратным средствам. В защищенном режиме я бы хотел иметь максимально возможную совместимость с Форт-системой работающей в ядре.
[quote="mOleg"]Виртуальная машина должна быть достаточно быстрой в любом случае.[/quote]
Да пусть хоть она вообще не работает. Как выглядела-бы прикладная программа, если-бы система работала? При использовании индексов вместо адресов нет смысле отказываться от плоской памяти. Поскольку работе программ работающих с индексами массивов данных, наличие стандартных средств ничем не мешает.
[quote="mOleg"]более подробно могу ответить только через личку[/quote]
Зачем тебе эти тайны?
|
|
|
|
Добавлено: Пн дек 22, 2008 13:53 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Mihail, загляните пожалуйста в личку к себе!
Mihail писал(а): mOleg писал(а):Быстро такой режим будет работать только близко к железу. На данном этапе, о быстродействии следует думать в последнюю очередь и да и нет. Mihail писал(а): mOleg писал(а):Какие проблемы возникнут? (вопрос не праздный) Если дополнительный индекс требуется каждый раз при обращении к памяти, это усложняет программу. в смысле усложняет манипуляции на стеке данных? кстати, не все адреса будут двойные. Например, литералы, литеральные строки, данные внутри слова не потребуют двух чисел. Mihail писал(а): Как я понял, создание/удаление индексов происходит где-то не нижнем уровне. на уровне, недоступном пользовательскому процессу, иначе невозможно обеспечить безопасность и устойчивость системы. Mihail писал(а): Т.е. система себя не выражает, система ограничена по расширению (на уровне пользователя). нет, не ограничена. Но ядро должно быть статичным. А система это ядро(не обязательно одно) + множество пользовательских процессов, взаимодействующих между собой с помощью асинхронных сообщений, разделяемых блоков памяти, и слов из базового словаря, доступного всем пользовательским процессам. Mihail писал(а): Или в этом случае, тормоза такие большие, что ничего не продемонстрировать? а вот это надо выяснять! Виртуальная машина должна быть достаточно быстрой в любом случае. Mihail писал(а): Не вижу я никаких проблем ни с файлами ни с выделением дополнительной памяти. не видишь ты, я вижу Mihail писал(а): Что еще твоя система решает?
у меня нет системы, а есть набор увязанных между собой идей (в основном, но есть и неувязанные).
более подробно могу ответить только через личку
Mihail, загляните пожалуйста в личку к себе!
[quote="Mihail"]mOleg писал(а):Быстро такой режим будет работать только близко к железу. На данном этапе, о быстродействии следует думать в последнюю очередь[/quote] и да и нет.
[quote="Mihail"]mOleg писал(а):Какие проблемы возникнут? (вопрос не праздный) Если дополнительный индекс требуется каждый раз при обращении к памяти, это усложняет программу.[/quote] в смысле усложняет манипуляции на стеке данных? кстати, не все адреса будут двойные. Например, литералы, литеральные строки, данные внутри слова не потребуют двух чисел.
[quote="Mihail"]Как я понял, создание/удаление индексов происходит где-то не нижнем уровне.[/quote] на уровне, недоступном пользовательскому процессу, иначе невозможно обеспечить безопасность и устойчивость системы.
[quote="Mihail"]Т.е. система себя не выражает, система ограничена по расширению (на уровне пользователя).[/quote] нет, не ограничена. Но ядро должно быть статичным. А система это ядро(не обязательно одно) + множество пользовательских процессов, взаимодействующих между собой с помощью асинхронных сообщений, разделяемых блоков памяти, и слов из базового словаря, доступного всем пользовательским процессам.
[quote="Mihail"]Или в этом случае, тормоза такие большие, что ничего не продемонстрировать?[/quote] а вот это надо выяснять! Виртуальная машина должна быть достаточно быстрой в любом случае.
[quote="Mihail"]Не вижу я никаких проблем ни с файлами ни с выделением дополнительной памяти.[/quote] не видишь ты, я вижу ;)
[quote="Mihail"]Что еще твоя система решает?[/quote]
у меня нет системы, а есть набор увязанных между собой идей (в основном, но есть и неувязанные).
более подробно могу ответить только через личку
|
|
|
|
Добавлено: Сб дек 20, 2008 22:12 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Быстро такой режим будет работать только близко к железу. На данном этапе, о быстродействии следует думать в последнюю очередь. mOleg писал(а): Какие проблемы возникнут? (вопрос не праздный) Если дополнительный индекс требуется каждый раз при обращении к памяти, это усложняет программу. Тем-более с польской записью с манипуляцией на стеке. Как я понял, создание/удаление индексов происходит где-то не нижнем уровне. Т.е. система себя не выражает, система ограничена по расширению (на уровне пользователя). Вообще, не будь проблем, система давно-бы была реализована (в качестве приложения) с кучей примеров демонстрирующих как все замечательно. Или в этом случае, тормоза такие большие, что ничего не продемонстрировать? mOleg писал(а): Я лишь говорю, что очень органично такая адресация может вписаться в форт и убрать кучу проблем.
Не вижу я никаких проблем ни с файлами ни с выделением дополнительной памяти.
Что еще твоя система решает?
[quote="mOleg"]Быстро такой режим будет работать только близко к железу.[/quote]
На данном этапе, о быстродействии следует думать в последнюю очередь.
[quote="mOleg"]Какие проблемы возникнут? (вопрос не праздный) [/quote]
Если дополнительный индекс требуется каждый раз при обращении к памяти, это усложняет программу. Тем-более с польской записью с манипуляцией на стеке. Как я понял, создание/удаление индексов происходит где-то не нижнем уровне. Т.е. система себя не выражает, система ограничена по расширению (на уровне пользователя). Вообще, не будь проблем, система давно-бы была реализована (в качестве приложения) с кучей примеров демонстрирующих как все замечательно. Или в этом случае, тормоза такие большие, что ничего не продемонстрировать?
[quote="mOleg"]Я лишь говорю, что очень органично такая адресация может вписаться в форт и убрать кучу проблем. [/quote]
Не вижу я никаких проблем ни с файлами ни с выделением дополнительной памяти.
Что еще твоя система решает?
|
|
|
|
Добавлено: Сб дек 20, 2008 14:26 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
где-то была тут тема, что производительность - отчасти миф, можно порассуждать и отражать в память те регистры, к которым обращение реже, кроме того, насколько тормоза
(а постоянный вызов АPI не тормоза?) ведь такие тормоза есть в любой системе
где-то была тут тема, что производительность - отчасти миф, можно порассуждать и отражать в память те регистры, к которым обращение реже, кроме того, [u]насколько [/u] тормоза
(а постоянный вызов АPI не тормоза?) ведь такие тормоза есть в любой системе
|
|
|
|
Добавлено: Пт дек 19, 2008 23:11 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): Я думаю, это очень удачно, вместо того, чтобы мучиться с "укладыванием" ВМ в регистры, предусмотреть виртуальные регистры в памяти
и очень сильно потерять в скорости...
совсем уж тормоза-то не хочется иметь
[quote="вопрос"]Я думаю, это очень удачно, вместо того, чтобы мучиться с "укладыванием" ВМ в регистры, предусмотреть виртуальные регистры в памяти[/quote]
и очень сильно потерять в скорости...
совсем уж тормоза-то не хочется иметь
|
|
|
|
Добавлено: Пт дек 19, 2008 23:05 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: вы не правильно поняли. Регистры нужны для огранизации ФВМ. Те же указатели стеков, временные регистры, кеширующий вершину стека регистр. я рассужда. по аналогии с тем, как органищованы некоторые (может все) ассемблерные отладчики. Весь состав регистров копируется в некоторую структуру в памяти, (следует заметить, работа с которой безупречно отлажена и протестирована) и сами регистры свободны для других функций - например для вывода данных самого отладчика, потом всё кладётся обратно и делается следующий шаг ...
Я думаю, это очень удачно, вместо того, чтобы мучиться с "укладыванием" ВМ в регистры, предусмотреть виртуальные регистры в памяти
сама задача построения ВМ станет проще
[quote]вы не правильно поняли. Регистры нужны для огранизации ФВМ. Те же указатели стеков, временные регистры, кеширующий вершину стека регистр.[/quote] я рассужда. по аналогии с тем, как органищованы некоторые (может все) ассемблерные отладчики. Весь состав регистров копируется в некоторую структуру в памяти, (следует заметить, работа с которой безупречно отлажена и протестирована) и сами регистры свободны для других функций - например для вывода данных самого отладчика, потом всё кладётся обратно и делается следующий шаг ...
Я думаю, это очень удачно, вместо того, чтобы мучиться с "укладыванием" ВМ в регистры, предусмотреть виртуальные регистры в памяти
сама задача построения ВМ станет проще
|
|
|
|
Добавлено: Пт дек 19, 2008 22:57 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): фортеру ли это говорить, доп. стек, куда складывается содержание регистров перед использованием... или даже переменные с постоянными адресами...
вы не правильно поняли. Регистры нужны для огранизации ФВМ.
Те же указатели стеков, временные регистры, кеширующий вершину стека регистр.
[quote="вопрос"] фортеру ли это говорить, доп. стек, куда складывается содержание регистров перед использованием... или даже переменные с постоянными адресами...[/quote]
вы не правильно поняли. Регистры нужны для огранизации ФВМ.
Те же указатели стеков, временные регистры, кеширующий вершину стека регистр.
|
|
|
|
Добавлено: Пт дек 19, 2008 22:00 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: не совсем так. Быстро такой режим будет работать только близко к железу. Реализовать-то модель можно, но регистров проца не хватает 8( фортеру ли это говорить, доп. стек, куда складывается содержание регистров перед использованием... или даже переменные с постоянными адресами...
[quote]не совсем так. Быстро такой режим будет работать только близко к железу. Реализовать-то модель можно, но регистров проца не хватает 8([/quote] :) фортеру ли это говорить, доп. стек, куда складывается содержание регистров перед использованием... или даже переменные с постоянными адресами...
|
|
|
|
Добавлено: Пт дек 19, 2008 21:29 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Mihail писал(а): mOleg писал(а):представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам) В х86, в страничном режиме, поле старших разрядов и являются индексами. да, это я знаю. Но количество блоков ограничено в таком режиме, что не очень удачно. Mihail писал(а): mOleg писал(а):вероятно вы не поняли о чем речь, судя по вашему замечанию В принципе то я понимаю, чего ты хочешь (как мне кажется). Идея-то далеко не нова. А я и не утверждаю, что идея нова! Я лишь говорю, что очень органично такая адресация может вписаться в форт и убрать кучу проблем. Mihail писал(а): По моему, при попытки реализовать проблем возникает больше чем решается. Какие проблемы возникнут? (вопрос не праздный) Mihail писал(а): А главное, причем тут ОС? (тем более ядро ОС). На уровне пользователей это можно реализовать практически в рамках любой ОС.
не совсем так. Быстро такой режим будет работать только близко к железу. Реализовать-то модель можно, но регистров проца не хватает 8(
[quote="Mihail"]mOleg писал(а):представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам) В х86, в страничном режиме, поле старших разрядов и являются индексами.[/quote] да, это я знаю. Но количество блоков ограничено в таком режиме, что не очень удачно.
[quote="Mihail"]mOleg писал(а):вероятно вы не поняли о чем речь, судя по вашему замечанию В принципе то я понимаю, чего ты хочешь (как мне кажется). Идея-то далеко не нова.[/quote] А я и не утверждаю, что идея нова! Я лишь говорю, что очень органично такая адресация может вписаться в форт и убрать кучу проблем.
[quote="Mihail"] По моему, при попытки реализовать проблем возникает больше чем решается.[/quote] Какие проблемы возникнут? (вопрос не праздный)
[quote="Mihail"]А главное, причем тут ОС? (тем более ядро ОС). На уровне пользователей это можно реализовать практически в рамках любой ОС.[/quote]
не совсем так. Быстро такой режим будет работать только близко к железу. Реализовать-то модель можно, но регистров проца не хватает 8(
|
|
|
|
Добавлено: Пт дек 19, 2008 17:28 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам) В х86, в страничном режиме, поле старших разрядов и являются индексами. mOleg писал(а): вероятно вы не поняли о чем речь, судя по вашему замечанию
В принципе то я понимаю, чего ты хочешь (как мне кажется).
Идея-то далеко не нова. По моему, при попытки реализовать проблем возникает больше
чем решается. А главное, причем тут ОС? (тем более ядро ОС).
На уровне пользователей это можно реализовать практически в рамках любой ОС.
[quote="mOleg"]представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам)[/quote]
В х86, в страничном режиме, поле старших разрядов и являются индексами.
[quote="mOleg"]вероятно вы не поняли о чем речь, судя по вашему замечанию[/quote]
В принципе то я понимаю, чего ты хочешь (как мне кажется).
Идея-то далеко не нова. По моему, при попытки реализовать проблем возникает больше
чем решается. А главное, причем тут ОС? (тем более ядро ОС).
На уровне пользователей это можно реализовать практически в рамках любой ОС.
|
|
|
|
Добавлено: Пт дек 19, 2008 17:18 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Mihail писал(а): mOleg писал(а):Код: LEA EAX, [EDI] [EAX] MOV EAX, [EAX] Да надо-бы MOV EAX, [EDI] [EAX]
шанс исправить исходники СПФ
[quote="Mihail"]mOleg писал(а):Код: LEA EAX, [EDI] [EAX] MOV EAX, [EAX] Да надо-бы MOV EAX, [EDI] [EAX][/quote]
шанс исправить исходники СПФ ;)
|
|
|
|
Добавлено: Пт дек 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(очень быстрая и надежная ОС - все ядро в кэш помещается) и работать.
[quote="mOleg"]chess писал(а): mOleg писал(а):это как раз неудобно, потому что при изменении размера блока часто должно имениться расположение блока в памяти. То есть блок начинает по памяти "ездить" и это уже проблема, особенно для исполнимого кода.
Скажи как такое может понадобиться/получиться именно для исполнимого кода? По мне так без этого можно обойтись. Как вариант связка через Jmp-ы работает и ничего в этом извратного не вижу. Просто необходимости в этом нет.
еще как может. Потом, ведь речь не только о исполнимом коде, а и о данных. Ты сам говоришь сначала о том, что надо работать с файлами как с обычными словами, а потом сам говоришь, что не понимаешь для чего это нужно [/quote] Я говорил о словах-файлах с данными, а слова-файлы с исполнимым кодом в Форт-ОС не нужны. Форт-слова для замены файлов, да имеют код, который располагается в начале блока памяти и этот код должен модифицировать дескриптор этого слова-файла при уменьшении/увеличении размера слова-файла, когда он размазывается/разрывается по памяти. Код в начальном блоке при этом по размеру не меняется.[quote="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 указателю. замечу, что освобождается регистр, причем важный регистр! [/quote] Инструкции MOV EAX, FS: [EAX] не существует, надо сначала исполнить инструкцию LFS(загрузить из памяти полный указатель) и эту инструкцию никак не миновать, так что вариант с LEA EAX, [EDI] [EAX] проще. Что касается использования регистра EDI, то это не страшно, так регистров для форта хватает, а при переходе на 64-разряда их будет вообще с избытком. [quote="mOleg"]chess писал(а): mOleg писал(а):Или сделать нормальные dll в винде, чтобы код дллы не грузился несколько раз, и чтобы не настривались при загрузке адреса (ведь уже в сегментной модели памяти это лишнее). Места для DLL в ядре ОС не вижу, там они не нужны совсем, тоже самое касается приложений - все на основе словарных структур. Загрузку приложений лучше делать через компиляцию их исходников "на лету" - и это можно делать очень быстро.
тогда не надо говорить об ОС, это недоОС, просто очередная форт-система на голом железе, которых есть достаточно и так. [/quote]
Во-первых назовите хотя бы одну, которая тянет хотя-бы на недоФорт-ОС, с возможностью ее расширения.
Во-вторых речь идет о Форт-ОС, все остальное, заимствующее структуры существующих ОС(DLL, EXE, файлы) мне неинтересны. Это будет уже не ФортОС, а просто другая ОС, которых кстати как раз очень много разных. Проще просто
сделать форт-систему, например, под QNX(очень быстрая и надежная ОС - все ядро в кэш помещается) и работать.
|
|
|
|
Добавлено: Пт дек 19, 2008 17:15 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Код:
LEA EAX, [EDI] [EAX] MOV EAX, [EAX]
Да надо-бы
MOV EAX, [EDI] [EAX]
[quote="mOleg"]Код:
LEA EAX, [EDI] [EAX] MOV EAX, [EAX] [/quote]
Да надо-бы
MOV EAX, [EDI] [EAX]
|
|
|
|
Добавлено: Пт дек 19, 2008 16:53 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Mihail писал(а): mOleg писал(а):Надо только отказаться от плоской модели памяти, которая, имхо, дико неудобная, в пользу блочной памяти (то есть по сути хипа, хотя это и усложнит форт и приблизит его к лиспу с постскриптом). Чем тебе плоская память не блочная? Просто считай старшие разряды номером блока.
абсолютно ничем
такая память не может расти в размере.
вероятно вы не поняли о чем речь, судя по вашему замечанию.
а речь идет о том, чтобы представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам):
это позволяет менять размер любого блока, перемещать его, удалять и пр. без какого бы то ни было влияния на соседние блоки, и на логику работы программы. В таком случае можно одновременно компилировать несколько слов или даже не соблюдать порядок компилирования слов без особых проблем.
[quote="Mihail"]mOleg писал(а):Надо только отказаться от плоской модели памяти, которая, имхо, дико неудобная, в пользу блочной памяти (то есть по сути хипа, хотя это и усложнит форт и приблизит его к лиспу с постскриптом). Чем тебе плоская память не блочная? Просто считай старшие разряды номером блока.[/quote]
абсолютно ничем ;)
такая память не может расти в размере.
вероятно вы не поняли о чем речь, судя по вашему замечанию.
а речь идет о том, чтобы представлять память системы (всю) как ХИП, причем, адресовать блоки в хипе не по адресам а по индексам (номерам):
это позволяет менять размер любого блока, перемещать его, удалять и пр. без какого бы то ни было влияния на соседние блоки, и на логику работы программы. В таком случае можно одновременно компилировать несколько слов или даже не соблюдать порядок компилирования слов без особых проблем.
|
|
|
|
Добавлено: Пт дек 19, 2008 15:23 |
|
|
|
|