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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 90 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 12:37 
Не в сети

Зарегистрирован: Ср сен 13, 2006 10:06
Сообщения: 636
Откуда: Омск
Благодарил (а): 0 раз.
Поблагодарили: 3 раз.
chess писал(а):
Да с файлами хотелось бы работать по-фортовски (поближе к массивам). Никаких тебе OPEN, CLOSE, READ, WRITE и т.д.

А если ставить файл как словарь в контекст (открывать), снятие с контекста (закрытие)? Про чтение/запись в голову ни чего пока не лезет интересного.

_________________
Меня нет, не будет и не было.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 13:05 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
chess писал(а):
Да с файлами хотелось бы работать по-фортовски (поближе к массивам). Никаких тебе OPEN, CLOSE, READ, WRITE и т.д. Тем более RAM становится резко больше и она имеет тенденцию становиться энергонезависимой.

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

вопрос писал(а):
Цитата:Да с файлами хотелось бы работать по-фортовски (поближе к массивам). Никаких тебе OPEN, CLOSE, READ, WRITE и т.д. а как?
файл меняет размер, потому такие слова, массив - нет (как правило)

это проблема выбранной модели памяти. Возьмите хип - там можно изменять размер блоков.
Хотя, хип, например виндошный тут не совсем подходит. Обращение к памяти должно быть основано на паре: номер_блока,смещение.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 13:06 
Не в сети
Аватара пользователя

Зарегистрирован: Вт мар 20, 2007 23:39
Сообщения: 1261
Благодарил (а): 3 раз.
Поблагодарили: 19 раз.
Pretorian писал(а):
А если ставить файл как словарь в контекст (открывать), снятие с контекста (закрытие)? Про чтение/запись в голову ни чего пока не лезет интересного.

А может сделать специальный сервер, который будет "разруливать" все эти файловые чтение/запись?

_________________
Cтоимость сопровождения программного обеспечения пропорциональна квадрату творческих способностей программиста.
Роберт Д. Блисc


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 13:06 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Pretorian писал(а):
chess писал(а):
Да с файлами хотелось бы работать по-фортовски (поближе к массивам). Никаких тебе OPEN, CLOSE, READ, WRITE и т.д.

А если ставить файл как словарь в контекст (открывать), снятие с контекста (закрытие)? Про чтение/запись в голову ни чего пока не лезет интересного.

не, зачем, слово и есть хранилище данных. Просто нельзя слова адресовать напрямую. То есть нужно только волевое усилие по отказу от плоской памяти.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 13:50 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
mOleg писал(а):
это проблема выбранной модели памяти. Возьмите хип - там можно изменять размер блоков.

Эту возможность дает существующая ОС, а не только аппаратная платформа, на которой она установлена.
Оперативная память на аппаратном уровне пока "реализуется по плоской модели" для любой платформы(процессора).
При плоской модели(естественной) любой непрерывный кусок памяти задается парой (Addr Len) - это удобно и не приводит к расточительности при расходовании памяти под блоки данных любого размера. И обмен блоками данных между
форт-словами(процедурами/процессами) получается простой передачей тех же пар (Addr Len). И вообще при построении кодовой базы ОС нужно использовать средства максимально приближенные к железу, чтобы потом, полученный запас по быстродействию, просадить на более абстрактные вещи. Поэтому плоскую модель памяти нужно оставить.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 14:08 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
chess писал(а):
mOleg писал(а):это проблема выбранной модели памяти. Возьмите хип - там можно изменять размер блоков.
Эту возможность дает существующая ОС, а не только аппаратная платформа, на которой она установлена.
Оперативная память на аппаратном уровне пока "реализуется по плоской модели" для любой платформы(процессора).

аппаратная модель памяти тут играет роль не сильно. Кстати, сейчас все больше гарвард встречается, но и оригинальный ix86 так же работает с более сложной, чем плоская, моделью памяти. Собственно плоская память - самое дибильное, что можно придумать, поэтому и используется.

chess писал(а):
При плоской модели(естественной) любой непрерывный кусок памяти задается парой (Addr Len) - это удобно и не приводит к расточительности при расходовании памяти под блоки данных любого размера.

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

chess писал(а):
И обмен блоками данных между форт-словами(процедурами/процессами) получается простой передачей тех же пар (Addr Len).

так ведь я не спорю насчет обмена. Впрочем, это долгий разговор, так как это вопрос концепций.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 15:08 
Не в сети
Аватара пользователя

Зарегистрирован: Вс май 07, 2006 11:38
Сообщения: 279
Откуда: Slavyansk, Ukraine
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
ОФТОП
Кстати об адреналине и создании операционок - весьма поучительный фильм "Как Майкрософт заполучил DOS" (2000) TVRip:
http://rapidshare.com/files/44743094/Ka ... .part1.rar
http://rapidshare.com/files/44743060/Ka ... .part2.rar

_________________
Банзай!


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 15:11 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
mOleg писал(а):
аппаратная модель памяти тут играет роль не сильно. Кстати, сейчас все больше гарвард встречается, но и оригинальный ix86 так же работает с более сложной, чем плоская, моделью памяти. Собственно плоская память - самое дибильное, что можно придумать, поэтому и используется.

Гарвард - для защита кодовой базы ОС и любой программы - хорошее решение, но эта архитектура не массовая и ее
рассматривать здесь не надо, кроме того гарвард, как правило, аппаратно можно реконфигурировать под фон Неймана - это
во-первых, а во-вторых чем Гарвард плох для форта, даже конструкции типа векторов и CREATE DOES>
можно сделать с использованием памяти данных, закрытой от программ пользователей.
А оборотная сторона "дебильности" плоской модели - ее простота в использовании.
История развития Ix86 это вообще отдельная песня, главное здесь, что поддерживает плоскую модель.
mOleg писал(а):
это как раз неудобно, потому что при изменении размера блока часто должно имениться расположение блока в памяти. То есть блок начинает по памяти "ездить" и это уже проблема, особенно для исполнимого кода.
Я уже писал как быть с массивами переменного объема - просто пересылать не (Addr Len), а ( Addr Len ) дескриптора
массива, который представляет набор пар (Addr Len) отдельных непрерывных кусков массива.
Пересылка кодового массива - это зачем, ну а если все-же надо, то чем это будет отличаться от
пересылки ( Addr Len ) дескриптора такого массива - в итоге этот кодовый массив все-равно на своем месте останется,
а при накачке его дополнительным кодом через JMP-ы свяжем старый код с новыми кусками(Profit такое уже делал).
И "файлы" это такие-же массивы данных.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 16:20 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
chess писал(а):
А оборотная сторона "дебильности" плоской модели - ее простота в использовании.

видимая простота!
в реальности приводящая к большому количеству неудобностей.
Например, можно посмотреть как сделаны USER переменные в СПФ и помечтать о том, чтобы использовать сегментный регистр для адресации этой области.
Или сделать нормальные dll в винде, чтобы код дллы не грузился несколько раз, и чтобы не настривались при загрузке адреса (ведь уже в сегментной модели памяти это лишнее).

chess писал(а):
JMP-ы свяжем старый код с новыми кусками(Profit такое уже делал). И "файлы" это такие-же массивы данных.

и вот такие вот извраты вместо использования нормальной модели памяти...

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 17:08 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
chess писал(а):
во-вторых чем Гарвард плох для форта, даже конструкции типа векторов и CREATE DOES>
можно сделать с использованием памяти данных, закрытой от программ пользователей.

Гарвард (и даже SuperHarvard) - наиболее естественное решение для форт-процессора.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 17:23 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Хищник писал(а):
Гарвард (и даже SuperHarvard) - наиболее естественное решение для форт-процессора.

для форт-процессора возможно,
но для форт системы не обязательно.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 18:04 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
mOleg писал(а):
это как раз неудобно, потому что при изменении размера блока часто должно имениться расположение блока в памяти. То есть блок начинает по памяти "ездить" и это уже проблема, особенно для исполнимого кода.

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

mOleg писал(а):
Например, можно посмотреть как сделаны USER переменные в СПФ и помечтать о том, чтобы использовать сегментный регистр для адресации этой области.

Ну разделена память для потоков с помощью регистра EDI, вроде нормально все, что, можно сделать лучше/проще что-ли?

mOleg писал(а):
Или сделать нормальные dll в винде, чтобы код дллы не грузился несколько раз, и чтобы не настривались при загрузке адреса (ведь уже в сегментной модели памяти это лишнее).

Места для DLL в ядре ОС не вижу, там они не нужны совсем, тоже самое касается приложений - все на основе словарных структур.
Загрузку приложений лучше делать через компиляцию их исходников "на лету" - и это можно делать очень быстро.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт дек 18, 2008 20:58 
Не в сети

Зарегистрирован: Ср сен 13, 2006 10:06
Сообщения: 636
Откуда: Омск
Благодарил (а): 0 раз.
Поблагодарили: 3 раз.
chess писал(а):
А оборотная сторона "дебильности" плоской модели - ее простота в использовании.

Да, но она нужна для миникомпьютеров без распаралеривания (фиг выговоришь) где и не нужно особых наворотов. Дешево и сердито. Не разворачивать в том же мультимедийном центре полноценную ОС. Да и не виновата плоская модель, что мы ее переросли в персональных компах, да и давно ли пересматривали эти модели? Раз, два и обчелся вариантов.

_________________
Меня нет, не будет и не было.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт дек 19, 2008 12:12 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
mOleg писал(а):
Надо только отказаться от плоской модели памяти, которая, имхо, дико неудобная, в пользу блочной памяти (то есть по сути хипа, хотя это и усложнит форт и приблизит его к лиспу с постскриптом).


Чем тебе плоская память не блочная? Просто считай старшие разряды номером блока.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт дек 19, 2008 15:17 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
chess писал(а):
mOleg писал(а):это как раз неудобно, потому что при изменении размера блока часто должно имениться расположение блока в памяти. То есть блок начинает по памяти "ездить" и это уже проблема, особенно для исполнимого кода.

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

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

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 указателю.
замечу, что освобождается регистр, причем важный регистр!

chess писал(а):
mOleg писал(а):Или сделать нормальные dll в винде, чтобы код дллы не грузился несколько раз, и чтобы не настривались при загрузке адреса (ведь уже в сегментной модели памяти это лишнее).
Места для DLL в ядре ОС не вижу, там они не нужны совсем, тоже самое касается приложений - все на основе словарных структур.
Загрузку приложений лучше делать через компиляцию их исходников "на лету" - и это можно делать очень быстро.

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 90 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

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


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

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