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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 255 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8, 9, 10 ... 17  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Пт дек 14, 2007 12:57 
Не в сети
Moderator
Moderator

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
Forthware писал(а):
Скорее всего надо исходить из семантики всех примитивов исходной системы и каким то образом, реализовать их аналоги в целевой. Теоретически это вроде бы возможно..


Наверное, при условии, что разработчики Форт ядра системы не дополнили систему
своим семантическим уровнем и стали его использовать внутри примитивов системы.
Придется его выявлять:)

Forthware писал(а):

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


Это уже процессорно-зависимая часть не должна иметь завязок с ядром.

Forthware писал(а):

Для переноса же любого кода, следует опуститься еще на уровень ниже, в нашем случае это машкод х86. Семантика всех комманд в нем однозначна. :)


Ограничим возможности кодогенератора выбранным вариантом машкода?
для генерации программы в отличный от принятого базис.


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

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Forthware писал(а):
Ну так ведь для программ соответствующих ANSI и сейчас не существует проблем переноса (на уровне исходников). Или я не прав?

Правы, а кому такая правда нужна. На это вы сами дальше и отвечаете.
Я уже говорил про сложность решения задач совместимости и как следствие аккумулирования форт-наработок в рамках сложившейся парадигмы форт-подхода и про отсутствие стимулов к ее решению.
Единственно что вижу я - это возможность убирать раннее связывания кода и переносить его на стадию работы back-end-части транслятора, которой сейчас просто нет. Можно работать с форт-текстом и без его прямого выражения в кодах аппаратной платформы(вплоть до стадии работы back-end-части транслятора). В свете именно этого я написал предыдущий пост касательно стандарта на Форт. Форт-система при этом конечно должна быть изменена, как в плане организации, так и в плане функционирования. Например, словари должны поддерживать создание, компиляцию токенов и без кода, компилировать их последовательности и т.д. - короче много там чего.

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


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

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Kopa писал(а):
Наверное, при условии, что разработчики Форт ядра системы не дополнили систему своим семантическим уровнем и стали его использовать внутри примитивов системы. Придется его выявлять
Да, скорее всего.
Kopa писал(а):
Это уже процессорно-зависимая часть не должна иметь завязок с ядром.
Так процессор как раз таки у нас один. :) Просто используем его по разному. То-есть, тот же машинный код, для разных систем на том же процессоре имет разную семантику, определяемую архитектурой системы. А вот определить семантику кода относительно форт машины даже зная ее архитектуру в общем случае невозможно. Подобная реализация была бы 100% дизассемблером из машинного кода х86 (созданного чем угодно, в том числе и другими языками) в исходный код Форта. :(
Kopa писал(а):
Ограничим возможности кодогенератора выбранным вариантом машкода?
А разве мы можем наложить какие либо ограничения на уже существующие исходники? В результате, некоторая часть из них не будет совместима с созданой системой. Такой результат можно считать удовлетворительным? :?

_________________
Am I evil? I'm man - yes I am! © James Hatefield


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

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
chess писал(а):
Правы, а кому такая правда нужна. На это вы сами дальше и отвечаете.
Извените, значит я не верно понял вашу мысль. :oops:
chess писал(а):
Единственно что вижу я - это возможность убирать раннее связывания кода и переносить его на стадию работы back-end-части транслятора, которой сейчас просто нет. Можно работать с форт-текстом и без его прямого выражения в кодах аппаратной платформы(вплоть до стадии работы back-end-части транслятора). В свете именно этого я написал предыдущий пост касательно стандарта на Форт. Форт-система при этом конечно должна быть изменена, как в плане организации, так и в плане функционирования. Например, словари должны поддерживать создание, компиляцию токенов и без кода, компилировать их последовательности и т.д. - короче много там чего.
Согласен. :) Только есть проблема - а останется ли реализация стандарта сематнического синтаксиса, или промежуточного кода, в разных системах полной и не расширенной? Если в одной реализации подобной архитектуры, к стандарту будет добавленно некое расширение (новые комманды), то все рухнет, и перенос программ с этой системы в другие, не содержащие точно такого же расширения, станет невозможным. То-есть расширять синтаксис семантического стандарта запрещено. В результате, в такой системе не может существовать ассемблер и прочие, аппаратно зависимые комманды (работающие непосредственно с регистрами CPU и т.д.).
А так в целом, это реально. Вот только действительно, кто за это возмется? Ведь надо создать стандарт и пополуяризировать его до такой степени чтобы появились его реализации. Не легкое это дело. :roll:

Да и не имеет особого отношения к уже существующим исходникам, поскольку некоторая часть из них не будут с ним совместима. Это перспектива на будущее. Не больше.

_________________
Am I evil? I'm man - yes I am! © James Hatefield


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

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

Платформа х86 тоже постоянно меняется, но совместимость со старыми версиями остается.
Точно также будет и с виртуальной машиной. Она будет усложняться конечно, но совместимость со старыми версиями останется.
Наоборот конечно нет. Но это же нормально. Нельзя заложить виртуальную машину на века. С практикой приходят новые идеи.
С ассемблером аппаратной платформы все просто - написанное на нем разрешается в код на этапе back-enda(и становится его расширением).
Сама back-end-часть платформо-зависима и может быть написана на чем угодно.
Forthware писал(а):
А так в целом, это реально. Вот только действительно, кто за это возмется? Ведь надо создать стандарт и пополуяризировать его до такой степени чтобы появились его реализации. Не легкое это дело.

Много языков основано на концепции VM, но только форт обладает такой "яркой индивидульностью". За ошибки всегда кто-то должен заплатить.
Forthware писал(а):
Да и не имеет особого отношения к уже существующим исходникам, поскольку некоторая часть из них не будут с ним совместима. Это перспектива на будущее. Не больше.

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

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


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

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
chess писал(а):
Она будет усложняться конечно, но совместимость со старыми версиями останется.
Это понятно, проблема в другом - усложнять каждый может по своему, откуда уверенность что эти расширения в разных реализациях останутся совместимы между собой? Ну вот, например, если провести аналогию, то стандартной была ANSI94, а потом она усовершенствовалась в лице SPF, и, скажем Win32Froth. И то и другое развитие осталось совместимо со старой ANSI, но между собой они уже не совместимы. То же может случится и VM, если стандарт не будет развиваться быстрее потребонстей и желаний реализаторов. :(
Кстати, в х86 такие моменты тоже проскакивали, это и 3DNow!, и 64 битное расширение. ;) Правда там необходимость совместимости настолько велика что подобное скорее исключение чем правило.
chess писал(а):
С ассемблером аппаратной платформы все просто - написанное на нем разрешается в код на этапе back-enda(и становится его расширением). Сама back-end-часть платформо-зависима и может быть написана на чем угодно.
То-есть, при разных реализациях целевого компилятора мы не можем обеспечить совместимость ассемблерного кода. Хотя это в любом случае невозможно. :weep;
chess писал(а):
Если в существующих форт-системах появится возможность реального позднего связывания кода, а оно нужно ведь не только для совместимости(вспомните хотя бы о тормозном характере форт-кода), то это не такое уже далекое будущее.
Хммм... Вот тут у меня по ходу появилась мысля. А что если за промежуточный код взять, например, Си? Обычный Си, ну скажем с какой нибудь узаконеной стандартом библиотекой содержащей структуры данных соответствующие структуре VM (стеки, распределение памяти, возможно словари), но никакого кода. Как считаете? И ассемблер там можно вложить, и стандарт вполне достаточен, в том плане что никто пожалуй не начнет его хаотически расширять. Тогда форт превратится в транслятор исходников нужного синтаксиса в исходники С, которые уже бэкэндом откомпилятся в исполняемый код. По моему над этим можно подумать. :shuffle; :D

_________________
Am I evil? I'm man - yes I am! © James Hatefield


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

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
chess
Например, результат работы такого Фортового "фронт энда":
Код:
// стек данных (это должно быть стандартным в либе):
int* DS;
int DP;

// примитивы (каждый форт может создавать свои по желанию):
void DUP () { DS[DP-1]=DS[DP--] };
void DROP () { DP++ };
void MUL () { DS[DP+1]*=DS[DP++] };

// определение высокого уровня (тоже генерятся фортом):
void SQR ()
{
   DUP();
   MUL();
};

И "бэкэнд" уже готовый есть, причем в большом ассортименте! :D


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

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

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


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

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
chess писал(а):
а мне СИ не по душе.
Ну, можно и друго существующий язык. :roll: Или все таки специальный синтаксис лучше? Как считаешь?

Кстати, с С есть проблемка, называется EVALUATE. ;)

_________________
Am I evil? I'm man - yes I am! © James Hatefield


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

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

Кстати, да.
Похоже все-таки не все так просто. :( Ну мне пора уходить из И-нета.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт дек 14, 2007 23:02 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Forthware писал(а):
Не факт. Слова созданные с помощью VARIABLE возвращают адрес в AS. С индексами тоже можно работать прямо в нем.

Получается заметание проблемы под ковер. Сейчас достаточно одного-единственного варианта литерала. А тут придется придумывать два - кладущий литерал на стек данных и на стек адресов.


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

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Хищник писал(а):
Сейчас достаточно одного-единственного варианта литерала. А тут придется придумывать два - кладущий литерал на стек данных и на стек адресов.
Дык есть уже - ALITERAL. В моем "расширении" определен. Что касается ввода числа с терминала, то я предпочитаю считать все введенные числа именно числами, поэтому ввод адреса будет вроде:
3788287 >A
Это тем более не существенно потому что в числовом виде вручную адреса практически никогда не вводятся. ;)

Кстати, по теме адресного стека. Посмотрел я на несколько исходников. Вцелом, около 80% текста остается без изменений! :shock: Так получается, например с последовательностями типа: VAR1 @ + VAR2 !
Они одинаково верны для обеих архитектур. Изменения в осоновном приходится делать там, где с адресами выполняются какие либо операции, а также стековые перетасовки когда адреса лежат в перемешку с данными. В первом случае (обычно, но не всегда) код усложняется (добавляются слова), во втором (тоже обычно) код упрощается (выкидываются лишние слова).
Вцелом, похоже, в плане синтаксиса, особого улучшения нет. :roll:

ЗЫ Относитльено скорости моего расширения. Прогнал я на нем samples\bench\bench.f (переделаный разумеется), получилось приблизительно в 4 раза медленнее чем в оригинале. Это где-то на уровне реализации с косвенным шитым кодом, которые многих устраивают ;) Так что можно реально использовать! :D Правда не совсем понятно зачем. :?

_________________
Am I evil? I'm man - yes I am! © James Hatefield


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Для x86 это вполне может рассматриваться как вариант... хотя и придется учитывать изменения в некоторых типовых алгоритмах.Просто не совсем понятно, зачем, потому что какое-то кардинальное улучшение безопасности кода в целом тут вряд ли получится. Ну перестал программист забывать @ после имени переменной (транслятор заругался), но вдруг после @ на стек помещается еще один адрес? И ладно бы теги были, тогда проверка типов в рантайме позволяла бы выявить такую забывчивость. А то ведь VAR1 VAR2 + сложит не содержимое переменных (@ забыли), и не их адреса (исходя из сделанного предложения, они автоматически ушли на другой стек!), а... два числа на стеке, которые там остались от прошлых действий! Никакой безопасности кода.

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


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

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Транслятор должен работать с именами, имена должны иметь типы, точка. Интерпретатор должен работать с безымянным стеком.

_________________
понимаю некоторую бестолковость некоторых вопросов


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

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
ОТ Где можно взять документацию по Кварку? А то он совсем не ANSI и много своего имеет.
Извените если плохо искал. :roll:

_________________
Am I evil? I'm man - yes I am! © James Hatefield


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

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


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

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


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

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