Forth
http://fforum.winglion.ru/

поговорим о ТЗ
http://fforum.winglion.ru/viewtopic.php?f=55&t=3068
Страница 2 из 2

Автор:  Hishnik [ Сб июл 25, 2015 14:24 ]
Заголовок сообщения:  Re: поговорим о ТЗ

in4 писал(а):
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?

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

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

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

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

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

Автор:  mOleg [ Сб июл 25, 2015 16:38 ]
Заголовок сообщения:  Re: поговорим о ТЗ

Hishnik писал(а):
Система должна быть стандартной постольку, поскольку это требуется в наших реалиях.

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

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

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

Автор:  in4 [ Сб июл 25, 2015 21:43 ]
Заголовок сообщения:  Re: поговорим о ТЗ

Hishnik писал(а):
in4 писал(а):
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?
Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.
Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT?
Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация.
Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше.
А как в ARM реализован АИ?

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

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

Автор:  Hishnik [ Сб июл 25, 2015 22:23 ]
Заголовок сообщения:  Re: поговорим о ТЗ

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 не имеет физического разделения.

Автор:  Hishnik [ Сб июл 25, 2015 22:26 ]
Заголовок сообщения:  Re: поговорим о ТЗ

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

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

Автор:  in4 [ Вс июл 26, 2015 01:12 ]
Заголовок сообщения:  Re: поговорим о ТЗ

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

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

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

Автор:  Hishnik [ Вс июл 26, 2015 01:46 ]
Заголовок сообщения:  Re: поговорим о ТЗ

in4 писал(а):
Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.

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

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

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

Автор:  in4 [ Вт июл 28, 2015 03:15 ]
Заголовок сообщения:  Re: поговорим о ТЗ

Хочу попробовать сделать несколько вариантов реализации ColorLessColorForth с разными ВМ и для разных архитектур(x86, ARM). Один из вариантов - надстройка над SPF.
Где их лучше разместить:
  • отдельным проектом
  • отдельными ветками в OpenForth
  • отдельной веткой в OpenForth
  • в общую кучу

Автор:  Victor__v [ Пт дек 23, 2016 19:10 ]
Заголовок сообщения:  Re: поговорим о ТЗ

А как насчёт реализации стека потока управления?
Отдельный стек?
Или всё же стек данных?
А может стек возвратов?
А может лучше под каждый вид свой стек? Для условий один, для циклов другой? Всё равно многим, в моём лице :D , требуются "нестандартные" структуры управления

Страница 2 из 2 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/