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

...
Google Search
Forth-FAQ Spy Grafic

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




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Nova Дневник разработчика
Автор Сообщение
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Всё-таки пора переходить на 64 бита.
А то у нас тут на форуме их нема. Только Кварк Хищника.
Мало товарисчи, мало :D

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

Меньший затык:
Надо написать обёртку на fastcall в винде.

Сейчас добавил в форт слова DW@ DW! DW,
От слов @ ! , сейчас ничем не отличаются. 32-бит всё-таки.
Просто задел на будущее.

Ввёл слово SSET-OUT т. е. убрать элемент из множества на стеке.
С такой операцией гораздо проще писать самоудаляторы библиотек.
Сообщение Добавлено: Вт окт 01, 2019 14:40
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Очередной виток идей для улучшения форта, поскольку реальной задачи у меня всё равно нет :(

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

1.1)
Очередной вариант оптимизатора. Ну вот люблю я их делать а после выкидывать на помойку)
Алгоритм:
Отслеживаем каждое слово, записываем все данные о нём в массив структур и компилируем/исполняем его. И так всё вплоть до слова ;
Это слово по сути является спусковым крючком.
Далее просматриваем весь массив элементов и ищем разрывы в коде между элементами. Так мы попробуем определить не-слова (числа, символы и пр.).
Если разрыв устранён, добавляем новые элементы в массив и идём дальше.
Если разрыв всё-таки есть, то пропускаем его и после вынесем в отдельный участок для модификаций.
Когда все разрывы будут обнаружены приступаем к самой мути: ищем в коде условные и безусловные переходы.
Начнём мы естест-но с таких слов, как IF ELSE REPEAT AGAIN UNLIL
После всё равно надо будет прошерстить весь код на поиск переходов. Все эти переходы вместе с метками будут занесены в массив.
Отлично, теперь у нас есть весь (или почти весь) код отражённый в массиве элементов.
К которому уже можно применять оптимизирующие правила.
Недостатки: Он тупо сложный и по этому для форта ненадёжный.
1) Попробуйте найти все переходы в нативе не прибегая к помощи дизассемблера, которого нет.
2) Что делать с компилирующими словами? Часть данных в структурах будет повторяться. Как вариант, пройтись по массиву и проверить код ещё раз на валидность.
3) Нестандартная адресация. К примеру, хранение адреса/смещения в ячейке. Как это вообще детектировать, чтобы после скорректировать?

Облегчённый вариант написанного выше.
Опять же всё суём в массив, тут же ликвидируем разрывы если есть, и при этом оптимизирующие правила применяем сразу.
Так проще и глобально мало что сломаешь. Но тоже-таки не совсем надёжно, зато приучит к хорошему программированию и простым словам :)
Сообщение Добавлено: Пн июл 15, 2019 16:31
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Накидал где-то за час новый транслятор файлов, который при возникновении ошибки спозиционирует её с точностью до последнего отранслированного слова.
Вывод то-бишь при ошибке:
Файл в котором воникла ошибка
Номер строки, на которой произошло исключение.
Слово породившее исключение.
Ну и собственно код исключения и пояснение к нему.

Это всё сделано с участием 3 высокоуровневых библиотек, 2 из которых можно выкинуть, если заморочиться и уменьшить тем самым понятность кода.

Ложка дёгдя тоже есть.
Транслятор работает построчно, с полным текстом файла в хипе и вызовом слова SPLIT
Проще говоря медленно. Это даже может быть заметно на большой цепочке файлов.
Сообщение Добавлено: Вс июн 30, 2019 23:43
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Ethereal писал(а):
Чтобы чикать списки не нужна их позиционная независимость. И списки могут быть сколь угодно разрывны. В чем тут проблема ?


Вот смотрите при хранении слов. структур в позиционно-независимо возникнет задача получить LFA словаря для навигации.
Если пространство непрерывно не вопрос. Адрес начала пространства + смещение до словаря. Делов-то.
А вот если при необходимости память будет выделяться и связываться в список, то фишка "адрес+смещение" не прокатит.
Ведь возникает вопрос: относительно какой части словарного пространства эта фишка должна работать. По сути надо будет организовывать поиск, чего не хочется.
Сообщение Добавлено: Сб июн 29, 2019 21:48
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
Думаю сделать пространство словарных структур позиционно-независимым насколько это возможно.
Это позволит убрать пространство слов. структур в случае нужды или хорошенько его почикать.
Чтобы чикать списки не нужна их позиционная независимость. И списки могут быть сколь угодно разрывны. В чем тут проблема ?
Обходишь списки и пересшиваешь их, выкидывая все элементы списков, которые не лежат в диапазоне адресов основного кодофайла программы. Словари, которые не определены в этом диапазоне чикаешь полностью из списка словарей. В итоге временные словари удалены. После забываешь про память где они лежали. Главное, чтобы код на который они ссылались остался в кодофайле.
Сообщение Добавлено: Сб июн 29, 2019 20:45
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Думаю сделать пространство словарных структур позиционно-независимым насколько это возможно.
Это позволит убрать пространство слов. структур в случае нужды или хорошенько его почикать.

Для этого нужно, чтобы все хранящиеся указатели там (кроме CFA) превратились в смещения до требуемых данных
То бишь поля NFA LFA LLFA должны хранить смещения.

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

Варианты:
1) забить болт и сделать пространство слов. структур непрерывным, выделив ему память в куче.
Сложности:
1.1 временные словари. придётся специально для них заморичиться и написать FREE-WORDLIST (сейчас делается FREE THROW ), который будет учитывать дополнительное наличие памяти для слов. структур, которую надо будет удалить.

2) Сделать список словарных пространств. В этом случае обнаружение и компиляция LFA словаря потребует поиска в реальном времени, ибо смещения до словарей будут по сути ненадёжны.

Общая сложность. Где разместить это словарное пространство, учитывая что его можно будет безболезненно удалить?
Логично, что в конце пространства кода, а при старте форт-системы перенести её куда-нибудь и переписать указатель.

Что-то вроде:
Код:
HERE CELL+ HERE @ \ указатель на пространство и его размер, записанные в конце пространства данных
DUP ALLOCATE THROW
>R R@ SWAP MOVE
R> CURRENT @ L>wordFA @ !
Сообщение Добавлено: Чт июн 27, 2019 13:59
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Распишу состояние Новы на сегодня, чтобы бiло :)

Параметрических слов почти не осталось:
Исключения: CREATE USER-CREATE ,слова-обёртки ( WINAPI Cdecl: и пр. ).
Переменные и векторы больше не параметрические слова.
Для доступа к данным/адресу с пом. TO или FROM на этапе компиляции/интерпретации допрашивается структура слова и выдаётся её дополнительный CFA и адрес хранения данных хранящийся там же рядом.

У некоторых слов появились альтернативные режимы.
Во первых, это все слова по управлению памятью DP HERE C, W, , ALLOT S, используя перед ними слово ALT: компиляция будет идти не в пространство кода, а в пространство данных. Добавив ещё один ALT:
Т.е.
ALT: ALT: HERE
Можно манипулировать пространством словарных структур.

Расположение пространств:
Словарные структуры
Данные
Код

Если пространства начинают залезать друг на друга, то слово CONTROL-CDW выделит новые участки для пространств. У каждого словаря может быть свой обработчик контроля пространств. При определении словаря внутри другого, обработчик наследуется (копируется в новый словарь).
Слово CONTROL-CDW участвует в INTERPRET и SHEADER(std)
Этот механизм по умолчанию не даёт 100% гарантии, что данные, код и слов. структуры не пересекутся. Поскольку он не контролирует операции, а только отслеживает изменения.

Другие слова с альтернативными режимами кода:
Обычные словари. К примеру, FORTH засунет себя в контекст, а ALT: FORTH положит свой LFA на стек данных. Удобно для использования словарных итераторов, да и код выглядит более эстетичней.
Слова для поиска слов. SFIND SFIND-IN-VOC ' ['] вместо флагов и токена возвращают lfa слова в случае успеха.
TEMP-WORDLIST при альтернативном режиме возьмёт со стека кол-во байт для выделения памяти под словарь.
Сообщение Добавлено: Чт июн 20, 2019 17:54
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
QT у меня завести не получилось. Он постоянно чего-то требовал :))
В итоге забил на него.
С IUP всё пошло легче. Особенно когда нашёл примеры на кошерном Си
Сообщение Добавлено: Чт июн 20, 2019 13:26
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
Я просто беру готовый и работающий код и пытаюсь его портировать (успех близок
А вот использовать QT.DLL и иже с ними, это неспортивно

Ну, в принципе, сформированная позиция, имеющая право на жизнь. Я-то как раз упомянул, что Форт в качестве "наездника" на Qt.dll вполне годится, но при расхождении во взглядах на этот принципиальный вопрос получаются просто независимые направления. Что в целом хорошо уже потому, что два направления больше, чем одно :)
Сообщение Добавлено: Чт июн 20, 2019 13:18
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Повторюсь ещё раз.
Я не разбираюсь в виндяшном гуе и не хочу насиловать себе мозг им. Есть QT, GTK и пр. Лучш ими заняться, танцев с бубнами меньше.
Я просто беру готовый и работающий код и пытаюсь его портировать (успех близок :))
А вот использовать QT.DLL и иже с ними, это неспортивно :D
Сообщение Добавлено: Чт июн 20, 2019 13:09
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
По замечанию Ethereal решил добавить Гуй то бишь портировать winlib от ~yz.

Мне это уже довольно давно активно не нравилось, причем не в тактическом смысле, а в смысле устаревшей архитектуры.

Что такое GUI в Windows, известно уже давно. С приходом Windows началось переползание с процедурного ДОС-программирования на программирование, управляемое событиями, что вызывало недовольство программистов, привыкших в ДОС управлять программой "строчками сверху вниз". Т.е. поставили INPUT - ввелось число, подставляем его в формулу, печатаем и т.д. А в Windows пришлось раскидывать функциональность по трем местам: сначала сама функция, потом надо придумать элемент управления, который будет ее вызывать и назначить ему генерируемое сообщение, а в завершение вставить в обработчик проверку на это сообщение с вызовом функции. И надо сказать, все довольно-таки рутинно, зато можно запутаться, особенно если логика программы создается и модифицируется на лету.

Собственно, среда Delphi и подобные ей средства визуального проектирования и стали реакцией на эту рутину. Генерация сообщения и его обработка уже автоматизированы в движке программы, остается вписать в сгенерированный шаблон "сюда мы попадем, если нажмут вот эту кнопку" только логику. Это, наподобие динозавров, прошло свой круг эволюции, от восторгов возможностью рисования интерфейса, до некоторой усталости от "мышизма" с отловом нужных координат. Поэтому во многих книгах по визуальному программированию упоминают, что виджеты можно создавать и динамически, начиная с чистого окна программы. Собственно, если можно делать в рантайме CreateWindowEx, то можно вызывать и конструкторы виджетов с существенно более широкими функциями.

В целом, имея в программе интерпретатор (и компилятор, конечно, куда же без него), можно избавиться от необходимости заранее устанавливать все возможные связи между виджетами и программными объектами (я не имею в виду чисто object, а вообще все компоненты программы, реализуемые разработчиком). На практике невозможно без отдельного, заранее добавленного виджета, установить значение переменной X. Но в Форте-то возможно! Поэтому если в GUI-программу добавляется интерпретатор, то GUI может получиться гораздо интереснее, причем без необходимости заранее перечислять все, что там может в интерфейсе произойти.

Собственно, вот здесь я уже про это рассказывал.
http://fforum.winglion.ru/viewtopic.php?f=23&t=3165&start=32
Код:
0 BUTTON.SHOW
100 100 75 25 0 BUTTON.RECT
" +" 0 BUTTON.TEXT
" +" 0 BUTTON.ACTION


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

В современном ПО вполне существуют аналогичные подходы, к примеру Tcl/Tk, где на Tcl можно в рантайме управлять виджетами программы. Вообще, заявляемое назначение Tcl довольно близко пересекается с сильными сторонами Форта, только Форт получается ближе к низкому уровню и потому предоставляет больше возможностей глубокой переработки архитектуры.

Так что, на мой взгляд, движок WinGUI надо прятать, поскольку что-то там улучшать или модифицировать ни к чему. Повторение на Форте того, что в 90-е годы делали для С++ и Object Pascal, вообще малоперспективно - от этого будут воротить нос просто из-за крайне малой базы кода, примеров и реализованных проектов, что является неким показателем того, что основные баги отловлены и можно рассчитывать на поддержку.
Сообщение Добавлено: Чт июн 20, 2019 12:52
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
У Жиловца много чего намешано в библиотеках. Навскидку треть можно выкинуть из-за ненужности в конце. Зато там нет ООП :), как к примеру, в библиотеках ~nn
Я пытался портировать его реализацию ООП, поверх которого есть ГУЙ, но что-то не сраслось :(

А касательно родного ГУЯ вообще на винде. На мой взгляд это порождение :dmad; Сотоны.
Лучше IUP тогда использовать, там хотя бы по-человечески всё сделано.

Лично мне самому разбираться с Гуем на винде не сильно улыбается
Сообщение Добавлено: Чт июн 20, 2019 09:37
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
По замечанию Ethereal решил добавить Гуй то бишь портировать winlib от ~yz.
Удивительно насколько разные подходы. У меня сплошой минимализм. Я гуй прикрутил добавив в Форт только два слова. Слово
Код:
; A defining word used in the form:
;     KERNEL32: cccc
; Creates a word cccc, which executes cccc function of KERNEL32.DLL and
; returns the return value of this function data on stack. It there is
; no function with a given name cccc in kernel32.dll the created word
; will terminate a program.

в 9 слов шитого кода и 19 команд ассемблера. И примитивное слово
Код:
      ENTRY   3, 'GUI', GUI
; Future application created by SAVE will be GUI-application.
      DD   $+4
      mov   byte [_SUBSYSTEM], 2
      NEXT$

А все остальное вытягиваю за этот хвостик прямо в прикладной программе. Вот так :
Через это буду тянуть :
Код:
KERNEL32: GetProcAddress
KERNEL32: LoadLibraryA

Для динамического импорта определяю два вспомогательных слова
Код:
: API: <BUILDS ' BYE , DOES> @ CALL ;
: (API:)
  ( hDll pfa -- )
  DUP NFA COUNT 1F AND HERE 2DUP + >R SWAP CMOVE R 1- 80 TOGGLE 0 R> C!
  HERE ROT GetProcAddress DUP 0= IF -1 BYE THEN SWAP CELL+ !
;

Определяю имена функций которые заимпортирую, чтобы они стали словами Форта
Код:
API: CreateWindowExA
API: DefWindowProcA
API: DispatchMessageA
API: GetMessageA
API: LoadCursorA
API: LoadIconA
API: PostQuitMessage
API: RegisterClassA
API: ShowWindow
API: TranslateMessage
API: UpdateWindow

И теперь слово которым импортирую
Код:
: IMPORT
  " USER32" 1+ LoadLibraryA
  DUP ' CreateWindowExA  (API:)
  DUP ' DefWindowProcA   (API:)
  DUP ' DispatchMessageA (API:)
  DUP ' GetMessageA      (API:)
  DUP ' LoadCursorA      (API:)
  DUP ' LoadIconA        (API:)
  DUP ' PostQuitMessage  (API:)
  DUP ' RegisterClassA   (API:)
  DUP ' ShowWindow       (API:)
  DUP ' TranslateMessage (API:)
      ' UpdateWindow     (API:)
; IMPORT
Главное слово программы начинаю с импорта :
Код:
: MAIN IMPORT
...
И сохраняю программу как гуевую
Код:
' MAIN CFA ' (MAIN) ! GUI SAVE .\Window.exe BYE
Все примитивно просто и не скажу, что это удобно, хотя просто шапка с динамическим импортом копипастится из программы в программу и это не сложно, только список импортируемых функций поправляю. Но главное - бац, бац и готово, собрали из камней и веток и уже гуим. А у тебя другой подход - ты целую либу портируешь с какими-то временными словарями, итераторы какие-то, я так не умею. И даже не знаю что такое итераторы. Нет, определенно хочу твой Форт (после того как будет готов пример создания простейшего окна) заценить, вот как будет в сравнений твой подход с моим из камней и веток, насколько велика будет разница в удобстве программирования ? Просто удобнее или пропасть как удобнее ?

P.S. Вот как в итоге после камней и веток у меня простейшее окно выглядит :
Код:
CALL: WndProc
  ( lParam wParam Msg hWnd -- ... n )
  OVER
  CASE
    WM_DESTROY OF 0 PostQuitMessage ( DROP ) 0 ENDOF
    >R DefWindowProcA R>
  ENDCASE
;
: MAIN IMPORT
  IDI_APPLICATION 0 LoadIconA WindowClass hIcon !
  IDC_ARROW 0 LoadCursorA WindowClass hCursor !
  WindowClass RegisterClassA DROP
  0 400000 0 0 CW_USEDEFAULT DUP 2DUP WS_OVERLAPPEDWINDOW
  " Window Application" 1+ WindowClass lpszClassName @ 0
  CreateWindowExA SW_SHOWNORMAL OVER ShowWindow DROP UpdateWindow DROP
  BEGIN
    0 0 0 msg GetMessageA
  WHILE
    msg TranslateMessage DROP
    msg DispatchMessageA DROP
  REPEAT
  0 BYE
;
Т.е. поначалу камни и ветки, а в итоге все приличненько. Ну не Qt конечно, все через нативные виндозные API-функции, что словами Форта стали, но то, что надо.
Сообщение Добавлено: Чт июн 20, 2019 06:15
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Потихоньку причёсываю новую версию.
По замечанию Ethereal решил добавить Гуй то бишь портировать winlib от ~yz.


Вначале всё шло хорошо. Добавлял слова для совместимости. Пришлось тотально переписать одно слово в модуле ~yz отвечающем за подгрузку виндяшных констант.
Но самый ужас меня посетил, когда я увидел в основном файле (winlib.f) слово generate-names
Это слово перебирает слова внутри временного словаря и на их основе создаёт другие слова.
Вот только перебор там никак не оформлен. Как же хорошо, что у меня есть итераторы :D
Более того у ~yz несколько странное решение относительно локальных переменных. В файле они подгружаются, а в этом слове не участвуют, а оно, слово это, сложноватое.
Ну я переписал его с локальными переменными.
Бр-р, результат небо и земля по понятности.

Однако процесс портирования у меня застопорился. Скомпилированный код отказывался искать виндяшные константы.
Путём медитации нашёл виновника. Это моя реализация слова COMPARE. Это слово у меня не стандартное - тупо работает: строки равны или нет. А вот реализация ~yz по ходу-таки требовала доп. фишек оговорённых в стандарте Ну, мне не жалко. Я переписал это слово.

Вот только при этом умудрился закрыть почти все портируемые файлы :lol: . Результат не заставил себя ждать :))
У меня слова порождаемые generate-names начали компилироваться с флагами появившимися хрен его знает откуда. А их в реализации нет :hey;
Завтра буду лазить по файлам ~yz искать свои косячки.
Самое главное, если флаги подавить, то код работает. Только откуда эти флаги взялись блин.
Сообщение Добавлено: Ср июн 12, 2019 00:38
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Можно было бы определить наготово слово GUI и сделать два варианта сохранения - консольный
S" Proga.exe" SAVE
и гуевый
GUI S" Proga.exe" SAVE
Просто когда гуй отлаживаешь очень удобно сделать вот так
( GUI ) S" Proga.exe" SAVE
и вываливать отладочную информацию в консоль. А как отладил скобки убрать и все.
Я в своем Win-32 говнофорте именно так сделал. Одно из действительно удобных вещей там.
P.S. Но ресурсы мой говнофорт пришпандоривает :D
Сообщение Добавлено: Пн май 27, 2019 10:47

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


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