Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 03:38

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 8  След.

Куда цеплять "драйвера"?
Создавать лексиконы наподобие Си-библиотек 44%  44%  [ 4 ]
Прятать внутрь интерпретатора 0%  0%  [ 0 ]
Усложнять интерпретатор 0%  0%  [ 0 ]
Использовать более одного интерпретатора 22%  22%  [ 2 ]
FORTH устроен совсем не так 33%  33%  [ 3 ]
Всего голосов : 9
Автор Сообщение
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Сб апр 12, 2014 20:42 
in4 писал(а):
Если цель не наукообразное запутывание собеседника, то термины короткие.
Ткнул наугад в книжку, которую собрался-таки наконец прочесть (объединил лексические единицы):
"Так как рабочий превращает свою-заработную-плату преимущественно в жизненные-средства, и притом главным-образом в необходимые-жизненные-средства, то спрос-капиталиста на рабочую-силу косвенно-является в-то-же-время спросом на-предметы-потребления,-входящие-в-потребление-рабочего-класса".
Слова-то короткие, но по одиночке не ходят... Кстати, в немецком их часто сливают физически. Благодаря этому даже длиннющие немецкие предложения-абзацы читаются гораздо легче. Например, если мы будем в приведенном предложении понимать слова не группами, а по отдельности - понять смысл будет гораздо труднее.
in4 писал(а):
Пример - передача параметра "тип открытия файла" - Read, Write, ReadWrite.
Пример неудачен. Т.к. операция открытия файла атомарная для ОС, то передавать как-то иначе, чем константой, не стоит.
in4 писал(а):
Напомните, пожалуйста!
Мур писал: "Пусть будет просто!". Следствие - "Не предполагайте!" Поэтому создание таблиц с параметрами на любой вкус не приветствуется. Надо открыть файл с некими флагами, что-то записать и закрыть - так и создавайте слово ПРИПРЯТАТЬ с нужными константами внутри. Когда-нибудь появится слово ПЕРЕПРЯТАТЬ, делающее что-то похожее, вот тогда и задумывайтесь о "наибольшем общем делителе".
in4 писал(а):
Если вы считаете выбор варианта "ставить IF-ы" технически оправданным....
А какое это имеет отношение к разговору?
in4 писал(а):
А вот это тоже очень интересный вопрос.
Дык, с него тему и начал...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Сб апр 12, 2014 23:45 
Не в сети

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

gudleifr писал(а):
in4 писал(а):
Пример - передача параметра "тип открытия файла" - Read, Write, ReadWrite.
Пример неудачен. Т.к. операция открытия файла атомарная для ОС, то передавать как-то иначе, чем константой, не стоит.
Но у нас же своя операционная система! И в ней можно сразу установить нужную операцию/набор операций!
И вообще-то пример о том, что сначала одно определенное значение по смыслуу передается как группа значений, из которой нужно выбирать - деревом проверок или таблицей. Главное,, что информация у нас была, а мы ее смешали с мусором(==неважными данными), а потом опять разделяем! И на эту последнюю операцию ресурсы тратим зря!

gudleifr писал(а):
Мур писал: "Пусть будет просто!". Следствие - "Не предполагайте!" Поэтому создание таблиц с параметрами на любой вкус не приветствуется. Надо открыть файл с некими флагами, что-то записать и закрыть - так и создавайте слово ПРИПРЯТАТЬ с нужными константами внутри. Когда-нибудь появится слово ПЕРЕПРЯТАТЬ, делающее что-то похожее, вот тогда и задумывайтесь о "наибольшем общем делителе".
У нас же речь идет об ОС. Причем ее проектируем. Поэтому можем попробовать сделать хорошо - у нас же не висит бремя совместимотсти! А для этого - собираем много данных и на их основании выбираем, как мы работу с ними будем организовывать.

gudleifr писал(а):
in4 писал(а):
Если вы считаете выбор варианта "ставить IF-ы" технически оправданным....
А какое это имеет отношение к разговору?
Попытался разделить 2 варианта - это один из них. Под деревом решений я имел в виду именно набор IF-ов. И мне казалось это очевдным, т.к. другие варианты из Броуди, по-моему, на дерево не похожи. Я оценил вариант усложнения дерева == набора IF-ов как неподходящий и вроде бы об этом сообщил и предложил вариант лучше. А тут вы пишите, что это технически оправданно. Поскольку я уже ошибался в своей уверенности, что понятно объяснил свою точку зрения - на всякий случай отрезал вариант, с которым я ничего обсуждать не буду ввиду его бесперспективности.

gudleifr писал(а):
in4 писал(а):
А вот это тоже очень интересный вопрос.
Дык, с него тему и начал...
Тут IMHO только пробовать надо и показывать код. И просить предложить лучший вариант.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вс апр 13, 2014 00:05 
in4 писал(а):
Но у нас же своя операционная система!
Тогда придется вспомнить, что такое файл. (А можно и без файлов...)
in4 писал(а):
Главное,, что информация у нас была, а мы ее смешали с мусором(==неважными данными), а потом опять разделяем! И на эту последнюю операцию ресурсы тратим зря!
То же, что и с деревьями... К чему это обсуждение правил хорошего тона в чисто техническом вопросе?
in4 писал(а):
У нас же речь идет об ОС.
О разрастании FORTH до ее размеров и функционала... Сложность, в данном случае не самоцель, а зло, которого хочется избежать...
in4 писал(а):
Попытался разделить 2 варианта - это один из них.
Да не было таких вариантов... (За исключением 1-го - бездумного наращивания лексиконов).
in4 писал(а):
Тут IMHO только пробовать надо и показывать код.
Да, в общем-то, примеров кода - дофига, а, вот, наоборот, его анализа - фигушки.

P.S. В традиции FORTH тоже дофига избыточных манипуляций с данными. Например, все условные переходы обрабатываются дважды: сначала условный JMP используется при вычислении условия ("пишем 0 или -1"), затем - уже в коде перехода (пишем в регистр адреса либо следующий, либо - перехода).


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вс апр 13, 2014 19:15 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июн 25, 2009 11:12
Сообщения: 412
Благодарил (а): 41 раз.
Поблагодарили: 8 раз.
in4 писал(а):
Пример - передача параметра "тип открытия файла" - Read, Write, ReadWrite. Перед передачей параметра уже известно, какой из 3-х алгоритмов использовать. Но мы эту информацию сразу не устанавливаем, а кодируем ее (раньше я сказал - пакуем, это здесь синонимы) и передаем как параметр.

И делаем так потому, что есть важное различие между алгоритмом (открытия файла) и параметром (который незначительно меняет алгоритм).
Алгоритм открытия файла, скажем, 100 команд, а от параметра зависят 10.

in4 писал(а):
Генерится код передачи параметра. В вызываемой функции мы выбираем этот параметр, затем делаем проверку (в лучшем случае одну - переход по таблице).

Это стоит копейки в машинном коде и во всех языках почти-машинного уровня. Только не в форте.

in4 писал(а):
В худшем - контроль параметра - 2 проверки на крайние значения и 2 проверки для выбора одной из 3х веток.

Посмотрите, что происходит с параметром mode в open1: http://www.tuhs.org/Archive/PDP-11/Trees/V7/usr/sys/sys/sys2.c

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

Зачем писать три алгоритма, если алгоритм открытия файла один?
Он ОДИН (1) и большой, с несколькими небольшими опциональными ветвями.

in4 писал(а):
Получается значительное сокращение кода, особенно по сравнению с худшим случаем.

Не получается. Да ещё лишний "вызов функции из переменной".


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вс апр 13, 2014 19:51 
Дались вам эти файлы...
Если речь идет о сделанной по уму FORTH-OS, то, скорее всего, файлов там не будет.
Ведь, что такое файл - "атом общения с драйверами", "единица синхронизации" ОС, заточенных под процессы.
А FORTH имеет для этого дела свою "единицу синхронизации" - WORD.
Плюс, рудименты блоковой памяти, которую вполне можно приспособить для совместимой работы с дисковыми накопителями...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вс апр 13, 2014 22:02 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
in4 писал(а):
Главное,, что информация у нас была, а мы ее смешали с мусором(==неважными данными), а потом опять разделяем! И на эту последнюю операцию ресурсы тратим зря!
То же, что и с деревьями... К чему это обсуждение правил хорошего тона в чисто техническом вопросе?
Это широко распространенная практика Си-стиля. Передача параметров IMHO одна из частых операций и ее улучшение может улучшить код. Поэтому я счел важным обратить на это внимание. Если для вас очевидно, что лучше передавать значение, а не флаг, то я за вас(и себя) рад!

gudleifr писал(а):
В традиции FORTH тоже дофига избыточных манипуляций с данными. Например, все условные переходы обрабатываются дважды: сначала условный JMP используется при вычислении условия ("пишем 0 или -1"), затем - уже в коде перехода (пишем в регистр адреса либо следующий, либо - перехода).
Ответ - использование флагов процессора, как в ColorForth. И я собираюсь эти диалекты развивать.

dynamic-wind писал(а):
Это стоит копейки в машинном коде и во всех языках почти-машинного уровня.
Копейка рубль бережет. Там чуть длиннее, в другом месте - а потом операционка в ОЗУ не влазит! А это можно убрать при соответствующем проектировании. Заодно и скорость увеличится! А если такое убрать из часто выполняющегося цикла... ;)

dynamic-wind писал(а):
Посмотрите, что происходит с параметром mode в open1
Посмотрел. Используется как маска. К данному коду проблема, о которых говорилось, не относится.

gudleifr писал(а):
Если речь идет о сделанной по уму FORTH-OS, то, скорее всего, файлов там не будет.
Полностью согласен! :)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вс апр 13, 2014 22:50 
in4 писал(а):
Передача параметров IMHO одна из частых операций и ее улучшение может улучшить код.

in4 писал(а):
Ответ - использование флагов процессора, как в ColorForth.

Если обращать внимание на такую фигню, наверное, не стоит связываться с FORTH...
Нас должно волновать не улучшение кода, а улучшение языка, т.к. обычно задача перестает быть управляемой программистом задолго до того, как начнет вызывать проблемы у процессора.
А улучшать язык я вижу только один способ: "вносить под скобки" FORTH-системы конструкции, которые позволят упростить создание пользовательских языков...
Причем, не "в кодах" (любые коды будут местами избыточны, а местами - недостаточны), а "в потенции" - как набор общих решений и соглашений, облегчающих заимствование уже написанного кем-то кода...

Например, Вы упомянули "флаги, как в ColorForth". Я с его исходниками не знаком. Как мне понять, идет ли речь о вводе вариантов IF на все флаги, автоматической оптимизации компиляции, создании универсальных арифметическо-логических слов... наконец, годится ли это решение для всех видов шитого кода или нет... А, ведь, будь у нас необходимая терминологическая база, можно было бы практически "пальцем ткнуть".


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 14, 2014 00:42 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Что интересно, обсуждение Форт-ОС часто переходит в обсуждение файловой системы и драйверов. В то же время, файлы, сеть, драйверы устройств - это то, что к ОС имеет опосредованное отношение - т.е. они могут там присутствовать, но необходимость поддержки соответствующих устройств не делает обязательным использование ОС. А ОС как таковая занимается управлением ресурсами.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 14, 2014 11:06 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Нас должно волновать не улучшение кода, а улучшение языка, т.к. обычно задача перестает быть управляемой программистом задолго до того, как начнет вызывать проблемы у процессора.
Это как раз об улучшении языка! Использование флагов процессора, а не значения на стеке; разделение словаря и кода => имя слова представляет адрес, множественные точки входа в слово; оптимизация хвостовой рекурсии - это изменение языка!

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

gudleifr писал(а):
набор общих решений и соглашений, облегчающих заимствование уже написанного кем-то кода...
К сожалению, часто это затруднительно. Разные стили трудновато красиво совместить в одной программе. Проще переработать. Например, если в одном из вариантов условия проверяют значение на стеке, а в другом - флаг процессора и при этом код с соответствующими оптимизациями(и трюками) для каждого стиля - к какому приводить? Уже столкнулся. Пока выбрал переработать в один стиль. Заимствовать получилось только идеи. Трюки не все получается перетаскивать.

Но, по идее, если работать на более высоком уровне, можно и совмещать. Но удобным будет, если объемлющая система будет иметь описание(метаописание) всех включаемых стилей и возможности взаимно конвертировать код и подстраиваться под нужный стиль(а это уже элементы ИИ ;) ). Локальная связность(стиль отдельных частей программы) сохранится. Кстати, тут придется использовать различные интерпретаторы.

И, кстати, соглашения еще нужно соблюдать! ;) А тут авторы Форт-программ даже рекомендациям Броуди не следуют. Не осилили? Привыкли по-старинке? Забыли?
Делать систему посложнее - с анализом кода и подсказками и постоянным обучением? Вообще-то уже пора! А в современном мире - единственная мера.

И нужно постараться выбрать интуитивно-понятные решения. Тогда просто узнав о них - им будут следовать. Думаю это и будет "общими решениями и соглашениями". Причем опираться хорошо бы на несколько стандартов. Мне, например, плоский интерфейс в варианте Микрософта кажется шагом назад по сравнению с объемными кнопками. Как догадаться, что сбоку еще что-то выезжает?! Подсказки должны быть хорошо видны! Не стОит заставлять пользователя решать ребус! Да и чуть раньше - чтоб узнать, на какие кнопки можно нажимать, стало нужным таскать над ними мышку! Или меню из двух пунктов, в котором не видно, какой выбран? Ой, это уже про юзабилити - но тоже важный момент. И такие моменты лучше рассматривать в комплексе. Тогда результат может взлететь.

gudleifr писал(а):
Вы упомянули "флаги, как в ColorForth". Я с его исходниками не знаком.
Вот тут, тут и тут что-то есть.Если интересно, могу еще код показать, но не все рабочее и документация не обработана... :( Есть разобранный исходник компилятора colorForth Мура, но напрямую он мне не подходит - слишком подход радикальный. Я приблизил к традиционному, но в системе он пока не работает.
И одна из моих любимых статей Мура - 1%.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 14, 2014 12:12 
in4 писал(а):
Это как раз об улучшении языка! Использование флагов процессора, а не значения на стеке; разделение словаря и кода => имя слова представляет адрес, множественные точки входа в слово; оптимизация хвостовой рекурсии - это изменение языка!
Какое отношение к языку имеет оптимизация?!
Хорошо сказал Дейкстра:
Цитата:
В историческом плане этот последний аспект, т. е. возможность использования языков программирования в качестве средства общения с существующими автоматическими вычислителями, в течение долгого времени рассматривался как их наиболее важное свойство.
Эффективность, с которой существующие автоматические вычислители могли бы выполнять программы, записанные на конкретном языке, становилась главным критерием качества этого языка.
Как огорчительное следствие мы нередко обнаруживаем, что аномалии существующих вычислительных машин старательно воспроизводятся в языках программирования, причем это происходит в ущерб интеллектуальной управляемости программ, выражаемых на таком языке (как будто программирование и без этих аномалий не было уже достаточно трудным!).

in4 писал(а):
А про управляемость - это уже к среде разработки.
Среда разработки - это, с одной стороны, расширение языка некими, вроде бы полезными "нетекстовыми", "надлексическими" средствами, но, с другой, жуткое ограничение на работу, собственно, с языком. Мы разом отказываемся от формального описания языка (как описать "два раза дергани за пимпочку") и от возможности программ писать программы. (Да и в рамках поднятой темы, жесткое закрепление каких-то определенных способов написания FORTH и FORTH-программ совершенно нежелательно).
in4 писал(а):
Заимствовать получилось только идеи.
Речь и идет об идеях. Если, хотите о метакодировании.
in4 писал(а):
Кстати, тут придется использовать различные интерпретаторы.
Дык, а тема о чем?

in4 писал(а):
Разные стили трудновато красиво совместить в одной программе.
Об этом - и разговор. Чтобы разделением стилей на внутренние (реализуемые интерпретаторами) и внешние (реализуемые лексиконами) сократить число последних.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 14, 2014 18:24 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Какое отношение к языку имеет оптимизация?!
Использование оптимизация хвостовой рекурсии изменяет стиль программирования, и, можно сказать, язык.
Код:
: loop
  op1
  -if ; then  \ выход из цикла по флагу процессора Minus
  ifc op2 loop; then  \ переход на метку loop , такой цикл
  op3
  loop;  \ переход на метку loop , если флаг проца перенос; такой цикл

: entry
   op4
   loop;  \ переход на цикл loop

: erase  \ заполнение области 0-ми
  0
: fill
   ...  \ реализация fill
   ;  \ выход

: blank  \ заполнение области пробелами
  fill;  \ переход на слово fill
Вот примерно так выглядит.
Код:
if  который не снимает верхушку стека, неразрушающий, надо явно делать drop и использующий флаг проца
-if использующий не верхушку стека, а знаковый флаг проца
множественные точки входа  в слово определение через :  - просто адрес в коде
; множественный выход -  не прекращает компиляцию, а компилирует возврат
если ; стоит после ранее определенного слова  то компилируется переход на него ( оптимизация возврата для экономим ret-call и не заполняем стек возвратов), так реализуется оптимизация хвостовой рекурсии ;)
? - установка флагов знака и нуля по результатам тестирования литерала


gudleifr писал(а):
Среда разработки - это, с одной стороны, расширение языка некими, вроде бы полезными "нетекстовыми", "надлексическими" средствами, но, с другой, жуткое ограничение на работу, собственно, с языком. Мы разом отказываемся от формального описания языка (как описать "два раза дергани за пимпочку") и от возможности программ писать программы.
Возможности среды можно использовать как подсказки. Это не ограничение, а добавление еще одного инструмента, позволяющего быстрее решать задачи.

Хотя я также рассматриваю вариант среды как инструмента. Визуальное программирование только мышкой/пальцем. Но в результате генерируется такой же прекомпилированный код, как и после обычного редактора. Тут "прекомпилированный" означает особый нетекстовый формат хранения исходников, предназначенный для быстрой компиляции (частично скомпилированный) - это понятие Мура из colorForth.
Т.е. ограничения на генерацию исходников тоже нет. Входной язык тот же. Меняется только его внешнее представление и способ работы. Ну, (некоторые аналогии) можно программировать в HEX-кодах, на ассемблере и на Форте. Все порождает машинный код. Или как просмотр строк в текстовом и в HEX-виде. Или просмотр двухмерного массива в виде чисел, дампа памяти или картинки яркостей точек на экране. Просто другое внешнее представление(для просмотра и редактирования).

gudleifr писал(а):
(Да и в рамках поднятой темы, жесткое закрепление каких-то определенных способов написания FORTH и FORTH-программ совершенно нежелательно).
Согласен.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 14, 2014 19:01 
in4 писал(а):
Вот примерно так выглядит.
Это хорошо (хотя и бесполезно), пока программа очень маленькая. (Бесполезно, потому, что в 0,0....01% случаев, где это хоть на что-то влияет, проще переписать на языке ассемблера). Плюс, написать слово, которое может делать подобную фигню, вполне можно и средствами стандартного FORTH... Пока задача проста, мы имеем 1000 и 1 приятный и полезный способ оптимизировать ее очевидное решение. Но стоит ли это хоть что-то в случае, если задача сложная и мы не знаем ее решения?
(Например, тормоза, связанные с вызовом Erase обычно вызываются не тем, что его плохо реализовали, а в том, что эта операция практически всегда избыточна. Тоже можно сказать и о большинстве случаев "анализа флага процессора": на одну проверку "больше/меньше" приходится огромное количество логических вычислений, которые, как Вы правильно заметили, проще заменить адресной арифметикой).
in4 писал(а):
Визуальное программирование только мышкой/пальцем.
Туда же. Т.е. когда решение есть, почему не обвесить его "свистелками и перделками"?
in4 писал(а):
Но в результате генерируется такой же прекомпилированный код...
Компилятор FORTH работает в один проход. Т.е. написать что-то, что будет компилироваться намного дольше, чем занимает отпускание кнопки "Компилировать", программист не может в принципе...

Т.е. все, что Вы предлагаете относится исключительно к превращению FORTH в язык высокого уровня в худшем понимании этого слова - включением в язык полезных фигулек на все случаи жизни. Благодаря этому возможности создавать при помощи FORTH проблемно-ориентированного языка резко сокращаются.
Например, Мур радовался, что "если не надо" можно и VARIABLE в словарь не включать, а Вы требуете включения в стандарт одного из способов создавать слова со срощенными хвостами...

P.S. Мур немного хитрит. Он столкнулся с трудной задачей. Придумал для нее язык. Написал его на FORTH, причем не постеснялся "поправить, как удобнее" сам интерпретатор... Но из этого никак не следует, что ColorForth будет удобен еще кому-нибудь...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 14, 2014 20:42 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
когда решение есть, почему не обвесить его "свистелками и перделками"?
А если решение(тут - (визуальная)система) и состоит из кода, навешанного на свистелки? ;) А уже к системе добавляется как необязательная часть работа с исходным текстом? ;)
Могу рассказать, как выглядит. Начал было реализовывать, но инструмент выбрал не очень удобный(хотел потренироваться в его использовании). Так что вернулся к одному из текстовых вариантов. Но он тоже промежуточный - просто чтоб инструмент был и можно было на реальном примере стиль вырабатывать. Нашел интересные решения , ну, мне понравились. Одно из них - разделение интерпретаторов исполнения и компиляции и их связь как сопрограмм. Каждый получился проще, переключение - словами. Флаг STATE заменил сменой интерпретатора. Кстати, вызов сопрограмм получился очень просто - как обычных слов. Ни специального описания(как у Ноздрунова), ни особых методов кодирования. Просто вызов слова! И получил взаимно-рекурсивные слова. По-моему, преимущество - не добавляя новых механизмов расширять возможности.

gudleifr писал(а):
Вы предлагаете относится исключительно к превращению FORTH в язык высокого уровня в худшем понимании этого слова - включением в язык полезных фигулек на все случаи жизни.
Не в язык. В среду. В голом языке, кажется, осталось всего 7 операций для раскрутки и что-то из внутренностей - интерпретаторы и работа со словарями. Сейчас как раз чищу(но можно и эти слова засунуть в словарь - код-то уже есть, осталось добавить в словарь имена==адреса). Остальное - навесные элементы, докомпилирующиеся при необходимости. Мур даже компилятор выбрасывает. Я тоже хочу так попробовать и посмотреть, что выйдет.

gudleifr писал(а):
Благодаря этому возможности создавать при помощи FORTH проблемно-ориентированного языка резко сокращаются.
Почему? Причин не вижу. Вроде все возможности остались, даже добавились новые. Их можно не использовать, если религия не позволяет.

gudleifr писал(а):
Вы требуете включения в стандарт одного из способов создавать слова со срощенными хвостами...
Ну, это colorForth. От меня только вариант реализации, другой вариант синтаксиса(чуть упрощающий ввод исходников). Раз стандарта ОС нет, пусть будет такой. Не понравится, можно будет снова переделать! :)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 14, 2014 21:38 
in4 писал(а):
А если решение(тут - (визуальная)система) и состоит из кода, навешанного на свистелки?
Значит, ничего интересного тут нет...
in4 писал(а):
Кстати, вызов сопрограмм получился очень просто - как обычных слов. Ни специального описания(как у Ноздрунова), ни особых методов кодирования. Просто вызов слова! И получил взаимно-рекурсивные слова.
Надеюсь, что, на самом деле, в вашем решении нет ни сопрограмм (т.к. это означает двойной проход по тексту), ни рекурсий (т.к. тогда вызовы будут зазря забивать стек возвратов)... В остальном же, за исключением замены одного IF в самом некритическом месте интерпретатора на геморрой с заменой каждого словаря на пару, это ничего не меняет... Входной язык не меняется.
in4 писал(а):
Их можно не использовать, если религия не позволяет.
Религия не позволяет создавать возможности, которые можно не использовать.
in4 писал(а):
Раз стандарта ОС нет, пусть будет такой.
Какой?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 15, 2014 10:15 
Не в сети

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

gudleifr писал(а):
рекурсий (т.к. тогда вызовы будут зазря забивать стек возвратов)
Оптимизация хвостовой рекурсии - когда последовательность call + ret в конце слова заменяется на jmp в то место, куда был call . Состояние стека возвратов не меняется. Сначала происходит переход на вызываемое слово, а его ret возвращает управление туда, откуда было вызвано вызывающее слово! Если при этом было обращение к самому этому слову(вызывающему), то получается цикл вместо рекурсии. Если не понятно, могу картинок нарисовать.
in4 писал(а):
Оптимизаций там всего-ничего!
Самая главная, вокруг чего все построено - оптимизация хвостовой рекурсии - при генерации выхода проверяется последняя команда - если она вызов подпрограммы, то ее код заменяется на переход. Адрес остается тем же.
Но на этом построен весь стиль программирования. Он отличается от традиционного.
in4 писал(а):
Еще фрагмент - отличие MachineForth от традиционного из журнала Forthwrite июнь 2000, автор John Tasgal.

Еще пример изменения в стиле программирования.

Оптимизация хвостовой рекурсии
В любом определении завершающее действие слова перед точной с запятой и сама точка с запятой может быть всегда скомпилировано в единственный возврат.
word1 ... lastword ;
Т.к. ничего не случается между возвратом в lastword и возвратом по ;, возврат в lastword излишний.

Более сложный пример - это рекурсивный вызов в конце цикла WHILE. Если мы имеем серию вложенных вызовов, тогда последняя команда в каждом случае - это возврат. При работе это дает "; ; ; ; ;", а именно - последовательность возвратов.
Дело в том, что когда эти вызовы раскручиваются, все, что случается, это выполнение последовательности возвратов, один за другим. Ничего не выполняется между ними. Единственный необходимый возврат - это первый, размещенный в стеке возвратов (и последний выполняющийся).

Удаление этих излишних возвратов известно как оптимизация хвостовой рекурсии. Большинство компиляторов MachineForth-а (и также ColorForth-а) имеют оптимизатор хвостовой рекурсии.

Сейчас используется два синтаксиса, чтобы показать необходимость проведения этой оптимизации.
- специальный токен "-;" (тире + точка с запятой)
- "умная точка с запятой", которая включает распознавание образца lastword ; .

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

Это действительно очень необычный и элегантный подход к проблеме.

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

_________________
With best wishes, in4.


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

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


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

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


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

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