Где-то на форуме есть мое сообщение wm_paint hell Вызовов функций, конечно, достаточно, но жутко неудобно. Должен быть прозрачный интерфейс программиста, который допускал бы и самое высокоуровневое задание интерфейсных компонентов (нечто вроде tcl/tk), и безболезненное "опускание" до уровня системных вызовов. Самое главное - я не должен постоянно вспоминать, что и в каком порядке надо вызывать для получения результата.

Двойной точности почти всегда хватает. Есть еще внутреннее представление сопроцессора, 80-битное число. Считать же лучше именно на стеке, жестко контролируя глубину в compile-time. Стек с плавающей точкой в памяти - жуткая по производительности вещь, лучше уж завести отдельный набор слов для него.

Слышал, но не разбирался.


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


Это как? Откудова компилер может знать, что я там собрался на стек класть?


Это я уже заметил. Только что делать, ежели, скажем, надо вычислить нечто рекурсивное?

Что-то навроде этого:
button .generate -text "Создать" -command { тут команды }


Все правильно. Именно потому я и писал, что главное - обеспечить нормальную возможность делать то, что требуется в каждой конкретной задаче. А еще бывают попытки привлечь людей к пользованию транслятором или библиотекой, аргументированные именно количеством определений, которые там имеются.

Не знаю Но было бы хорошо. Самый простой способ - не контролировать вообще, заранее предупреждая о том, что ячеек на стеке сопроцессора мало.

Мне сильно кажется, что попытка обеспечить компромисс очень негативно скажется на вычислениях, которым рекурсия не нужна. Это все равно что контролировать глубину стека в каждом слове. Надежность повышается, да, но появляется масса дополнительных проверок, причем и в тех местах, где программист мог бы отладить код и "вручную". Сопроцессор и его стековая организация хороши именно там, где надо обеспечить интенсивные вычисления при минимальном числе обращений в память. Расширяемый в память стек заставит производить постоянные проверки "а не превысили ли мы объем аппаратного стека?". Лучше уж завести дополнительный словарь для рекурсивных вычислений, переопределив там базовые операции с плавающей точкой - F@ F! F+ F- и т.д. В этом словаре можно будет работать, когда требуется рекурсия (или иные алгоритмы, требовательные к объему стека).

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

например, есть операция сложения
+ ( n1 n2 --> n1+n2) - так она работает по первому варианту
STACK-OFF + ( n1, n2 --> n1, n2, n1+n2 ) - так она работает по второму варианту (исходные параметры со стека не убираются)
здесь STACK-OFF слово-префикс, которое выбирает для слова + новое поле кода в словарной статье слова +.

Вопрос, конечно, интересный (с)...

прежде чем добавлять навороты в Форт, надо бы четко определиться, а что же хочется от этого Форта?

Универсальный язык на все случаи жизни? - Боюсь, что такого сделать не удастся. Хотя, пофантазировать никто не мешает.

Вот, например, списочек добавлений, которые я был бы не прочь добавить в "Свой Форт":

А в чём это должно выражаться?


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


Не очень понял, для чего это нужно, к тому же, я думаю, это будет весьма геморроидально. Ещё дедушка Броуди писал, что злоупотребление словами, сканирующими входной поток, ведёт к потере гибкости, и лично я с ним в этом согласен. А в случае

легче и понятнее написать 2dup + .


Хочется, чтобы было легче программировать, и желательно, чтобы работало побыстрее.


С формальной точки зрения все языки программирования универсальны. Конечно, идеального языка не бывает, с другой стороны, всегда есть пространство для роста.


1. Ретрофорт (а значит, и мой форт) и так 32-битный. Насчёт доступа ко всей памяти - винда не пущает, но и того, что есть, более чем достаточно.
5. Для чего?
2, 3, 4, 6. Это всё вопросы к библиотекам, надо просто потратить некоторое время и изучить те средства, которые для этого предлагает windows. К языку это имеет мало отношения. Меня больше интересуют выразительные средства, такие, как ООП, массивы, перегрузка слов и т. п.

Тут входной поток не сканируется, просто в код вставляется другая операция сложения-без удаления исходных параметров. А вот использование 2dup замедляет скорость исполнения итак крайне медленную. Пример приведен от балды - без малейшего смысла. Обычное + сложение затрачивает время на удаление параметров со стека, а 2dup их опять предвосстанавливает - 2 раза делается лишняя работа. В этом тормоза Форта. И такие тормоза в Форте на каждом шагу.

А каким образом тогда это делается?

Мне хватает, хотя у меня довольно критичная ко времени область. Дело в том, что верхушка стека фактически всегда лежит в кэше процессора, так что обращений к памяти при этом не происходит. Если уж гнаться за производительностью программы, то не ценой производительности программиста и потери читаемости. Как известно, 10% кода исполняются 90% времени, так эти 10% можно и вручную оптимизировать.

В Форте это тоже, всё вопросы к библиотекам.

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

Эх, лучше бы при разработке новых х86 не инструкции добавляли, а стек сопроцессора увеличили хотя бы в 10 раз.

НЕТ, лучше бы поделали несколько аппаратных стеков с 1 тактом на push и pop

Точно, а ещё лучше все эти миллиарды транзисторов разместили бы в форме 1024 форт-процессоров.

1024 - мало - 10²⁴!

п.с. доктор, выпишите мне таблеток от жадности, и побольше ПОБОЛЬШЕ!

Тогда, вместе с"Мой Форт" должен быть еще и "Мой проц" и "Мой комп"



В данном случае, главный смысл в том, что придумать все на все случаи - нереально, поэтому, стоит подумать, как сделать механизм дополнений простым и прозрачным.

Обвешать Форт либами, как новогоднюю елку игрушками можно, но надо еще сделать и так, чтобы "при навешивании новых елка не кололась и старые игрушки не падали и не разбивались"


Ну, можно посчитать, что это моя личная блажь - (Надо по работе).


Однако, если язык не научить мяукать и махать хвостом, то он кошкой никогда и не станет