Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Ср окт 18, 2017 09:35

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июл 25, 2015 14:24 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6076
Благодарил (а): 13 раз.
Поблагодарили: 96 раз.
in4 писал(а):
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?

Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.

in4 писал(а):
Чем лучше варианта - специальное слово для вызова планировщика многозадачности?

Тем, что никакого планировщика многозадачности не предполагается. Зачем нужен этот суррогат в современных многозадачных ОС?

in4 писал(а):
Гарвардская архитектура? Отказываемся от динамической компиляции?

Не понял утверждения.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июл 25, 2015 16:38 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4830
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
Hishnik писал(а):
Система должна быть стандартной постольку, поскольку это требуется в наших реалиях.

Hishnik писал(а):
Поэтому я предполагаю в своей работе игнорировать существование ANSI и не считать совместимость (или же антисовместимость) с ним аргументом за или против.

У меня заходят шарики за ролики от написанного 8)

?Таки что тогда понимать под стандартностью!
(просто мысли вслух:) практическое большинство форт-систем написано таким образом, чтобы соответствовать одному из двух возможных стандартов(или как из поточнее обозвать-то): 83 и 94. Все остальное пока что в практику не вошло по факту.
Использование стандарта помогает с одной стороны сделать ее более понятной для других пользователей, т.к. меньше надо учить нового, а с другой стороны упростить разработку (потому что сразу понятно что должно и как выглядеть).
Попытки подойти к стандарту отечественному (из того, в чем я таки маленько участвовал) не дали ощутимых результатов, увы. Причем, проблема на сколько я помню стала за мотивацией необходимости такого документа вообще (и в частностях).

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июл 25, 2015 21:43 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Hishnik писал(а):
in4 писал(а):
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?
Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.
Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT?
Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация.
Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше.
А как в ARM реализован АИ?

Hishnik писал(а):
Раздельные области памяти для кода, данных и стеков.
in4 писал(а):
Гарвардская архитектура? Отказываемся от динамической компиляции?
Не понял утверждения.
В "обычной" реализации Форта код и данные были в одной области - можно было компилировать теми же средствами, что и размещать данные. Ну и делать модификацию кода во время работы. И докомпилировать программу в процессе работы(то, что я имею ввиду под "динамической компиляцией").
В гарвардской архитектуре код и данные тоже разделены. Соответственно вопрос - такое разделение это следствие ориентирования на гарвардскую архитектуру в том числе?
Но разделение областей кода и данных приведет к некоторому усложнению компиляции (как минимум исходников - понадобится больше специализированных слов).

Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июл 25, 2015 22:23 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6076
Благодарил (а): 13 раз.
Поблагодарили: 96 раз.
in4 писал(а):
Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT?
Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация.
Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше.
А как в ARM реализован АИ?

Мы уже приняли решение писать на Си. Да, NEXT - это интересно, остроумно и т.д., но стоит написать так, как проще

Код:
void Step()
{
    void(*fword)();
    fword = (void(*)())ReadCode(pc);
    pc += sizeof(int);
    fword();
}

void Execute()
{
    int RdepthOnEntry = Rdepth;
    do
    {
        Step();
    }
    while (RdepthOnEntry <= Rdepth) ;
}


Я не вижу смысла при таком коде выделять NEXT.
in4 писал(а):
Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.
Разумеется, логическое. x86 не имеет физического разделения.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июл 25, 2015 22:26 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6076
Благодарил (а): 13 раз.
Поблагодарили: 96 раз.
mOleg писал(а):
У меня заходят шарики за ролики от написанного 8)

Отвечу, пожалуй, в свежую тему...


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Вс июл 26, 2015 01:12 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Hishnik писал(а):
in4 писал(а):
Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.

Разумеется, логическое. x86 не имеет физического разделения.
Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.

Как я понял, пишем на С и оптимизацией занимается компилятор?
"Ручная" кодогенерация не предусматривается, или возможны варианты?
Тут есть про борьбу с компиляторами: Семь видов интерпретаторов виртуальной машины. В поисках самого быстрого

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Вс июл 26, 2015 01:46 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6076
Благодарил (а): 13 раз.
Поблагодарили: 96 раз.
in4 писал(а):
Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.

А зачем? Чтобы точно не было компиляции? :) В x86 есть понятие алиаса - дескриптор сегмента данных, полностью совпадающего по адресу и размера с дескриптором кода. В fasm достаточно поставить writeable.

in4 писал(а):
Как я понял, пишем на С и оптимизацией занимается компилятор?
"Ручная" кодогенерация не предусматривается, или возможны варианты?

Это уж кто как захочет. Я не собираюсь - у меня для такого есть кварк.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Вт июл 28, 2015 03:15 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Хочу попробовать сделать несколько вариантов реализации ColorLessColorForth с разными ВМ и для разных архитектур(x86, ARM). Один из вариантов - надстройка над SPF.
Где их лучше разместить:
  • отдельным проектом
  • отдельными ветками в OpenForth
  • отдельной веткой в OpenForth
  • в общую кучу

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт дек 23, 2016 19:10 
В сети

Зарегистрирован: Чт янв 07, 2016 19:14
Сообщения: 341
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
А как насчёт реализации стека потока управления?
Отдельный стек?
Или всё же стек данных?
А может стек возвратов?
А может лучше под каждый вид свой стек? Для условий один, для циклов другой? Всё равно многим, в моём лице :D , требуются "нестандартные" структуры управления

_________________
Цель: написать форт-систему
Подцель: pe-формат, скрыть ненужные слова из целевого словаря FORTH, отладка


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

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


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

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


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

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