А зачем ее выбросили в Win-64?

А что выбросили в Win64? Запретили процессору выполнять push и pop специальным магическим драйвером? Или запретили описывать стеки в виде массивов?

Параметры передаются в четырех регистрах. Изменение указателя стека происходит только в крайнем случае.

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

Дело даже не в том, что регистровые операции быстрее и при новых процессорах могут стать удобнее. Дело в том, что стековая арифметика Forth по барабану. Ему важен стек ввода - накопление вводимых параметров до ввода обрабатывающей их команды, а не DUP-ы и +-ы. Никто даже и не заметил, что вещественные операции были изъяты из стека и перенесены в собственный "вычислитель" (то, что он тоже оказался стеком, роли не играет). Также никто не заметил, что вершина стека переехала в отдельный регистр. Перехода к операциям ax=f(ax,dx) так же никто не заметит.

Вот возьмем команду +. Она по барабану, потому что стековая арифметика? Или она та самая команда, которой важно накопление вводимых параметров до ввода обрабатывающей их команды? Я вижу в процитированном явное противоречие. Так называемая "стековая арифметика" по сути ничем от "процедур" не отличается.


Что будет на стеке, если:
1) Вещественные числа хранятся на том же стеке, что и целые.
2) Вещественные числа хранятся на отдельном стеке (и этого изменения не заметили).

Ну, до тех пор, пока после этого не выполнят что-то, в имени чего нет ax, но что портит содержимое этого регистра. Тогда встанет вопрос о сохранении регистров и выяснится, что стек данных - удобный способ сохранения контекста вычислений при вызовах подпрограмм.

А что будет, если "1. 2. ... 28. + ... +"?
Просто Вы привыкли считать числа "естественным типом", а сложение "естественной процедурой". Когда дело касается более сложных операций, например, БД (у Мура есть пример записи "17 JOB EQUAL 3 DEPT EQUAL SENIORITY SORT LIST LIST"), нам очевидно, что операции проводятся над какими-то структурами, в стек не помещающимися. Если угодно, нам важно только, что не надо передавать параметры, т.к. они копятся в некой статической переменной (стеке) и эта переменная подобна стеку (т.е. не переполнится и не потрет ранее введенное).
В принципе эта статическая переменная может иметь любую удобную форму. Например, не помню, зачем, использовал этакого монстра:

Для "обычных" вычислений такого не требуется, но и на стеке свет клином не сошелся.
Взять тот же Tcl/Tk. Никто же не возражает, что вычисления там надо производить только а пределах одного, специально предназначенного оператора, а в SmallTalk числом считается только первое число, а последующие - суть параметры сообщений-операций...
Так что Forth, в котором числовые выражения не помещаются в стек, а обсчитываются где-то в специально предназначенном месте, вполне возможен. Работает же BrainFuck...

Ошибка будет - "исчерпание стека". Все числа лежат на стеке с плавающей точкой, а + работает с целочисленным. Поэтому если "Никто даже и не заметил, что вещественные операции были изъяты из стека и перенесены в собственный "вычислитель", то это только в том случае, если этот самый Никто с вещественными числами работать и не пытался.

В то время как из моих сообщений можно увидеть явно противоположное Я и обращаю внимание на то, что + является точно таким же словом, как и все остальные слова Форта. Он не имеет никакого приоритета, не имеет особенного формата словарной статьи и никак не распознается как "оператор". Поэтому фразу "накопление вводимых параметров до ввода обрабатывающей их команды, а не DUP-ы и +-ы." я и предлагаю переделать следующим образом. Представим, что обрабатывающая команда - это слово +. Тогда получается, что у нас есть "накопление вводимых параметров до ввода команды + , а не DUP-ы и +-ы. ". Если еще почистить текст, то останется, что Форту "важен +, а не +".

Ну вот она имеет форму стека данных. Как-то ведь надо эти параметры передавать. Для стека данных реализован набор слов, которые уже можно считать визитной карточкой Форта. Это не догма, а реализованный механизм. Реализованный потому, что без него все равно придется делать что-то "подобное стеку".




Это пример допустимой программы на Форте, где все слова работают исключительно с глобальными переменными. Есть даже набор таких "поражающих своей дуростью" кросс-компиляторов, у которых базовые слова Форта переопределены в новом словаре так, что + ничего не делает со стеком данных, зато пишет в образ памяти целевого процессора соответствующую команду. Т.е. модифицирует глобальные объекты, а не стек.

Не исчерпание, а переполнение. Обычная реализация использует маленький стек сопроцессора.
Не совсем. Оно рассчитывает на "арифметический стек", а не на "просто стек". Если появится более удобная для арифметики модель вычисления, не использующая стек, Forth сможет использовать и ее. Самому Forth обобщенная операция сложения не нужна. Ему вполне достаточно частных случаев, типа CELL+. Например, в Fobos нет операции умножения, она просто не понадобилась.
(Самому яркому примеру обработки арифметики "при помощи специальных структур" столько же лет, сколько и Forth - т.н. "инфиксная арифметика").
Точнее, проклятием. Хорошая Forth-программа их содержать не должна.

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

Даже, в случае "нейронного компьютера" возможна Forth-работа. Никакой стек, понятно, не нужен. Текущее слово, очевидно, будет возбуждать исполняющий ансамбль, связанный с возбужденными предыдущими словами ансамблями-параметрами.

В случае чтения Win-потока сообщений (кто об чем, а я - все о Fobos), иметь стек данных смысла не имеет - параметры передаются в "слове" и могут грузиться по месту. Да и т.к. порядок сообщений не определен, накапливать введенную последовательность в честном стеке смысла маловато.

Если придираться, то насчет переполнения еще неизвестно Я не знаю, сколько чисел спрятано за двоеточием. А вот исчерпание для + точно будет.

?????

Это несложно. Допустим, литералы загружаются в специальный регистр LIT.



Если удобно - никто же не мешает такое написать и пользоваться. Синтаксический разбор и поиск в словаре от Форта, стека нет.



Хорошая и не содержит. Стек данных - это не сакральный смысл Форта, это просто компромисс, на который идут программисты. Для постфиксной записи не нужен разбор выражений, вот и все. Работать постфиксные слова могут с любыми объектами, пример с [ ] DECIMAL и HEX я уже приводил. Есть "пакет" слов, работающих со стеком данных. Этот пакет неоднократно описан в литературе, для него отработаны приемы программирования. Можно выкинуть, не проблема... зачем? Можно, в принципе, из базиса Шеффера или Пирса вытянуть всю арифметику, но опять же - зачем так себя ограничивать? Небольшие усилия ведут к получению заметного продвижения, так пусть живут.


Ух ты! А если в Форте на стек положить указатель на массив, он тоже перестанет быть стековым?

Именно. И изменение железа/ОС может легко с ним покончить.

Считать стандартом вещь, вся прелесть которой в том, она легко делается, это все равно, что велеть кирпичу следовать закону всеобщего тяготения - он это и сам "знает".

Если он без этого массива не сможет пользоваться стеком, то чисто стековым он будет вряд ли. Да и Вы опять опускаете тот факт, что Forth стековый не из-за "стека данных", а из-за "стека ввода".

Нет, это вряд ли. Стековая модель вычислений интересна не эффективностью реализации, а способностью представить любой алгоритм. Фиксированный набор регистров имеет существенно ограниченные возможности. Относительно свежий пример - .net + CLR. Мотивация Microsoft вполне однозначна - стековые вычисления можно реализовать везде. А вот регистровые - уже нет. Сколько регистров предусмотреть? 2, чтобы точно были на всех архитектурах, но при этом код должен еле тесниться? Или 32, чтобы попадать в небольшой процент совместимых с таким кодом процессоров? Стек таких проблем не создает. Можно попробовать или FIFO или deque, но тогда уже надо посмотреть на примеры реализации основных алгоритмов.

Для меня это не стандарт, а привычка К примеру, PICK требует доступа к произвольно глубоким ячейкам, а на форт-процессоре это дополнительная проблема. ROLL я вообще не делаю в принципе, у него кроме доступа куда попало вглубь предусмотрен сдвиг данных на стеке опять-таки до произвольной глубины. С учетом малой связности стековых слов с остальными частями Форта (да и вообще, как правило, малой связности отдельных частей форт-транслятора) слова носят рекомендательно-исторический характер.

Я не вижу смысла в замене одного термина на другой. Есть понятие "стек возвратов", есть "стек данных". Что такое "стек ввода"? Явно частное проявление функциональности стека данных. Со стека данные еще и выходят, а в процессе работы преобразуются. Вводом заведует входной поток, но далеко не факт, что он что-то положит на стек данных. Еще раз отмечу, что Форт как язык предлагает синтаксис, разделенный пробелами. Форт как вычислительная машина предлагает стек данных, отделенный от стека возвратов. Форт как компилятор предлагает связанный список, содержащий имена и соответствующий им код. Можно пытаться это ломать и универсализировать, но тогда поплывут многие алгоритмы, причем поплывут не из-за несовпадения синтаксиса, а из-за отсутствия принципиальной возможности этот синтаксис обеспечить.

Тогда это не Forth. (Только не "данных", а "ввода"). Зачем различать "стек данных" и "стек ввода"? Чтобы отличать "стековую машину" от "Forth-машины".

Что кладет HEX на стек данных?

Само себя. Вы опять путаете стеки.