Forth http://fforum.winglion.ru/ |
|
Наработки от victor__v для СПФ http://fforum.winglion.ru/viewtopic.php?f=23&t=3105 |
Страница 3 из 6 |
Автор: | chess [ Вт мар 14, 2017 21:03 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Victor__v писал(а): А если взять идейно и сохранить внешнее сходство, перелопатив внутренности? Написать свою библиотеку на основе чужих идей это не значит перелопатить чужую. |
Автор: | loztcatz [ Вт мар 14, 2017 23:48 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
chess писал(а): Фортеры - одиночки. Ничего перелопачивать чужого не будут. Не вижу повода для гордости.chess писал(а): Рекурсия в реально производительных программах не используется поскольку тормозит программу. А игры в функц. программирование меня не интересуют. А еще их пишут на ассемблере И долго же вы будите абстрагироваться от реальности? Проще переделать готовое решение, а там видно будет подходит ли оно.Hishnik писал(а): Да где там чужие библиотеки-то? Тем более с интенсивным использованием рекурсии. Да их полно в свободном доступе.Hishnik писал(а): Лучше, если программа упадет из-за переполнения стека, поскольку ошибка с балансом стека - это существенно более вероятный сценарий. А какие-то мифические тысячи библиотек от сотен разработчиков - это только повод придумать для Форта еще один пункт для реализации. А почему мифические? Для разных ЯП уже создано множество разнообразных библиотек. Зачастую их можно использовать как образец.Hishnik писал(а): Динамические стеки, хэши в словаре, тэгированные данные, собственная файловая система, IDE... что еще? В итоге такого навороченного Форта не будет по объективным причинам (кто-то не сможет, а кто сможет - тому не нужно), и пойдет очередной виток "у нас нет подходящего Форта". Молоток должен оставаться молотком. Я вас правильно понял?Victor__v писал(а): Не так уж трудно создать массив и указатель Наличие динамического стека, хотя бы для отладочного режима, может упростить отладку приложения. Пусть компилятор решает нужен ли вообще стек в релизе, может и свободных регистров хватит
А касательно регистров тут уж надо думать сколькими стеками можно обойтись. Мой вариант edi - стек исключений и указатель на юзверей ebp - данные esp - адреса возвратов. Можно ещё один стек выделить, как в форке под адреса регистр esi . |
Автор: | Hishnik [ Ср мар 15, 2017 01:41 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
loztcatz писал(а): Да их полно в свободном доступе. Это давний вопрос - где библиотеки и как способствовать их появлению. Пока я не вижу проектов на Форте, для которых важным фактором их успеха было бы наличие библиотек в свободном доступе. А раз так, зачем этот "карго-культ" с библиотеками, open source, IDE и прочим? loztcatz писал(а): А почему мифические? Для разных ЯП уже создано множество разнообразных библиотек. Зачастую их можно использовать как образец. Это и есть карго-культ. Если построить хижину в виде аэропорта, на остров не начнут садиться самолеты. Фортом тоже не начнут пользоваться, если механически воспроизвести признаки успешных ЯП. loztcatz писал(а): Молоток должен оставаться молотком. Я вас правильно понял? Нет, с ним надо уже начать что-то делать. Если выяснится, что он может выступать в качестве и других инструментов, тогда уже и думать. loztcatz писал(а): Наличие динамического стека, хотя бы для отладочного режима, может упростить отладку приложения. Пусть компилятор решает нужен ли вообще стек в релизе, может и свободных регистров хватит Этого я не видел. А вред от программы, которая слишком уж старается обеспечить надежность - видел. Если есть ошибка, лучше закрыться с сообщением, чем стараться что-то там попробовать. Со стеком элементарный сценарий - до какого размера он будет расти? Если в цикле на миллиарды итераций забыть снять число со стека, динамическое изменение размера будет стараться выделить лишние гигабайты. Вот как бы мы отнеслись к программе, которая при ошибке в имени файла не выводила честное сообщение "файл не найден", а самостоятельно проводила поиск по всему диску, локальной сети и на всякий случай на сайте Microsoft в разделе с драйверами? Вместо доли секунды несколько минут. И с динамическим стеком будет то же самое. |
Автор: | chess [ Ср мар 15, 2017 10:27 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
loztcatz писал(а): chess писал(а): Фортеры - одиночки. Ничего перелопачивать чужого не будут. Не вижу повода для гордости. Гордость чаще бывает без повода. Фортеры работают в своей предметной области и как правило не являются проф. программистами. Знание предметной области позволяет писать нужное ПО с нуля с использованием только одной форт-системы и нескольких ей сопутствующих библиотек, ну и своих, которые появляются по мере эволюции работ в этой области. loztcatz писал(а): chess писал(а): Рекурсия в реально производительных программах не используется поскольку тормозит программу. А игры в функц. программирование меня не интересуют. А еще их пишут на ассемблере Еще как пишут! Оказывается часто производительность программ нужнее времени сидения за ассемблером. У меня для этих целей в форте есть встроенный ассемблер - для расшивки узких мест. loztcatz писал(а): И долго же вы будите абстрагироваться от реальности? Проще переделать готовое решение, а там видно будет подходит ли оно. Что-то вы тут, мягко говоря, недопонимаете. Наоборот, я специализируюсь в реальности - в своей предметной области. |
Автор: | mOleg [ Ср мар 15, 2017 18:28 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Цитата: Можно поподробнее? Я что-то не очень понял. все временные переменные функции винды хранят в стеке, и их бывает много. Я оставил для стека 128 (кажется) килобайт, и думал, что хватит на все, но практически сразу наткнулся, что для некоторых виндошных функций этого крайне недостаточно. |
Автор: | Victor__v [ Ср мар 15, 2017 20:12 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Цитата: Я оставил для стека 128 (кажется) килобайт, и думал, что хватит на все, но практически сразу наткнулся, что для некоторых виндошных функций этого крайне недостаточно. Где посмотреть в исходниках форка решение этой проблемы? |
Автор: | Hishnik [ Чт мар 16, 2017 01:55 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
mOleg писал(а): все временные переменные функции винды хранят в стеке, и их бывает много. Я оставил для стека 128 (кажется) килобайт, и думал, что хватит на все, но практически сразу наткнулся, что для некоторых виндошных функций этого крайне недостаточно. Ага, понятно теперь. Я у себя сделал стек Форта как раз отдельным, и к esp он не имеет отношения совсем, это просто область памяти, к тому же и адресуемая переменной. Поэтому его можно удобно контролировать и не давать вылезать за границы. Поскольку от кода на Форте я высокой производительности не ожидаю просто по методологическим соображениям (производительность обеспечивают ассемблерные вставки, OpenGL и внешние ускорители на FPGA), встраивание контроля полезнее. |
Автор: | mOleg [ Чт мар 16, 2017 04:23 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Victor__v писал(а): Где посмотреть в исходниках форка решение этой проблемы? у форка параметры виндошных функций в отличие от СПФа перед вызовом не переносятся на стек возвратов, поэтому стек данных и стек возвратов перед вызовом АПИ по сути меняются местами. Изначально стек данных, как в СПФе был расположен над стеком возвратов, после выявления проблемы их пришлось поменять местами. Я не помню, делал ли комментарий в коде по этому поводу. |
Автор: | Victor__v [ Пт мар 24, 2017 10:56 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
https://cloud.mail.ru/public/Lqke/6PXwYsXeR Что нового? Добавлен постфиксный ассемблер Дополнительно поддерживает две MMX-инструкции ( MOVQmm-[r] MOVQ[r]-mm) , а также инструкцию CRC32 Охват пока не полный, в процессе написания. Добавлена 2-я версия библиотеки для работы со строками на стеке возвратов Отличия от 1-й: часть вещей переписана на ассемблере (см.выше ), слова, которыми не разу не пользовался, удалены. Повышена наглядность исходников, надеюсь. Возможны некоторые недоработки 3 библиотеки для организации сопрограмм. Ждут проверки трудом. Стек возвратов, как стек потока-управления, экспериментальная наработка ( пример в ~er\str\str-r2.f ) Стековый манипулятор ( максимум 5 элементов) Создание функций на во время исполнения ( ~er\closure\fun.f ) на стеке возвратов. Является замыканием или нет? Надо откл оптимизатор, если используются ветвления и циклы |
Автор: | chess [ Пн мар 27, 2017 22:37 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Victor__v писал(а): Создание функций на во время исполнения ( ~er\closure\fun.f ) на стеке возвратов. Является замыканием или нет? Надо откл оптимизатор, если используются ветвления и циклы Трудно проверить что-ли? Вот пример проверки Код: : sqsum \ n1 n2 -- XT для (n1+n2)**2 LOG работы в консолиcl{ LITERAL LITERAL + DUP * } cl ; STARTLOG Код: 1 2 sqsum Ok ( 10188132 ) 3 4 sqsum Ok ( 10188132 10188164 ) SWAP Ok ( 10188164 10188132 ) EXECUTE Ok ( 10188164 9 ) SWAP Ok ( 9 10188164 ) EXECUTE Ok ( 9 49 ) PS. Замыкание, это слово мне кажется неудачным. Вкрапление, захват, закрытие(параметров) - точнее будет. |
Автор: | Victor__v [ Вт мар 28, 2017 09:38 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Цитата: Замыкание, это слово мне кажется неудачным Я просматривал литературу по этому поводу. Универсального определения замыкания нет. Тут и создание функций на лету, захват параметров, метод для сохранения результатов между вызовами функции (?), и поддержка переменных вышестоящей функций, даже если она уже отрубилась. У меня компиляция на лету с возможностью подстановки различных данных, за которые отвечает библиотека-донор ( ~er\str\str-r2.f ) Цитата: Трудно проверить что-ли? : TEST R:STR 400 " {un} {un} {s} ." R:COUNT STR>xt EXECUTE ; S" *" 10 20 TEST --> 200 S" + CELLS" 10 20 TEST --> 120 И? |
Автор: | chess [ Вт мар 28, 2017 10:31 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Victor__v писал(а): И? Похоже это не замыкание. Вы сделайте проверку как я показывал, а именно: сформируйте только ссылки(ХТ) на функции, созданные во время исполнения исходной функции с разными параметрами, а уже затем используйте EXECUTE для полученных ХТ. Параметры, которые были на этапе создания этих ХТ уже должны быть вставлены в исполняемые коды созданных функций. Код замыканий может быть потом использован многократно. |
Автор: | Victor__v [ Пн апр 03, 2017 20:38 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Интересно узнать мнение форумчан по поводу реализации стека исключений? Нужно ли оно вообще? Если да, то какие предложения будут по дизайну данного механизма? Catch Throw может быть недостаточно |
Автор: | mOleg [ Вт апр 04, 2017 03:48 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
А сейчас чем не стек исключений (в СПФ, например)? |
Автор: | Victor__v [ Вт апр 04, 2017 13:26 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Если мне не изменяет память в СПФ всё записывается в переменную, при новом catch зн из переменной в стек возвратов, а сама точка отката в переменную. Как-то не очень стек напоминает. Список скорее или цепочка. |
Страница 3 из 6 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |