Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Переносят со стека фреймов на стек данных и обратно. Для "повседневного программирования" они не требуются, поскольку на стеке фреймов хранятся не данные, а значения DEPTH. Так что это просто низкоуровневые слова для элементарных операций с таким стеком.
Ааа, точно, что-то я запамятовал.
[quote="Хищник"]Переносят со стека фреймов на стек данных и обратно. Для "повседневного программирования" они не требуются, поскольку на стеке фреймов хранятся не данные, а значения DEPTH. Так что это просто низкоуровневые слова для элементарных операций с таким стеком.[/quote]
Ааа, точно, что-то я запамятовал. :shuffle;
|
|
|
|
Добавлено: Ср фев 25, 2009 23:49 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
VoidVolker писал(а): А что собственно делают слова FRAME> и >FRAME? Чем они отличаются от FRAME{ и }FRAME?
Переносят со стека фреймов на стек данных и обратно. Для "повседневного программирования" они не требуются, поскольку на стеке фреймов хранятся не данные, а значения DEPTH. Так что это просто низкоуровневые слова для элементарных операций с таким стеком.
[quote="VoidVolker"]А что собственно делают слова FRAME> и >FRAME? Чем они отличаются от FRAME{ и }FRAME?[/quote]
Переносят со стека фреймов на стек данных и обратно. Для "повседневного программирования" они не требуются, поскольку на стеке фреймов хранятся не данные, а значения DEPTH. Так что это просто низкоуровневые слова для элементарных операций с таким стеком.
|
|
|
|
Добавлено: Ср фев 25, 2009 23:38 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
А что собственно делают слова FRAME> и >FRAME? Чем они отличаются от FRAME{ и }FRAME?
А что собственно делают слова [b]FRAME>[/b] и [b]>FRAME[/b]? Чем они отличаются от [b]FRAME{[/b] и [b]}FRAME[/b]?
|
|
|
|
Добавлено: Ср фев 25, 2009 23:02 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
in4 писал(а): А если для блока данных определить структуру/таблицу в куче и освободить ее после использования, так можно?
Можно, никто же не запрещает. Работа с памятью любого типа идет через WinAPI, Форт тут может предложить разве что обертку над стандартными функциями, которая ничего кардинально не улучшит, но создаст иллюзию "поддержки" чего-то там. В любом случае, работа с числами на стеке (более или менее удобная) - это одно, а создание дополнительных программных структур с соответствующей технологией работы с ними - совершенно другое.
[quote="in4"]А если для блока данных определить структуру/таблицу в куче и освободить ее после использования, так можно? [/quote]
Можно, никто же не запрещает. Работа с памятью любого типа идет через WinAPI, Форт тут может предложить разве что обертку над стандартными функциями, которая ничего кардинально не улучшит, но создаст иллюзию "поддержки" чего-то там. В любом случае, работа с числами на стеке (более или менее удобная) - это одно, а создание дополнительных программных структур с соответствующей технологией работы с ними - совершенно другое.
|
|
|
|
Добавлено: Вт янв 06, 2009 15:23 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
in4 писал(а): А если для блока данных определить структуру/таблицу в куче и освободить ее после использования, так можно? Или будет неудобно заводить несколько доп. переменных? Вроде иметь постоянно в доступном месте и цвет и координаты - удобно... Или все же такой вариант перегрузит словарь?
Если очень хочется локальные переменные именно в кварке - делаем самостоятельно. А вот мне например пока вполне достаточно фреймов и вот такой "дешевой альтернативы локалсам":
Код: : L1 LOCALSTACK LOCALDEPTH 1- -FTH ; : L2 LOCALSTACK LOCALDEPTH 2 - -FTH ; ... : LN LOCALSTACK LOCALDEPTH N - -FTH ;
[quote="in4"]А если для блока данных определить структуру/таблицу в куче и освободить ее после использования, так можно? Или будет неудобно заводить несколько доп. переменных? Вроде иметь постоянно в доступном месте и цвет и координаты - удобно... Или все же такой вариант перегрузит словарь?[/quote]
Если очень хочется локальные переменные именно в кварке - делаем самостоятельно. А вот мне например пока вполне достаточно фреймов и вот такой "дешевой альтернативы локалсам":
[code]: L1 LOCALSTACK LOCALDEPTH 1- -FTH ; : L2 LOCALSTACK LOCALDEPTH 2 - -FTH ; ... : LN LOCALSTACK LOCALDEPTH N - -FTH ;[/code]
|
|
|
|
Добавлено: Вт янв 06, 2009 12:49 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
А если для блока данных определить структуру/таблицу в куче и освободить ее после использования, так можно?
Или будет неудобно заводить несколько доп. переменных?
Вроде иметь постоянно в доступном месте и цвет и координаты - удобно...
Или все же такой вариант перегрузит словарь?
А если для блока данных определить структуру/таблицу в куче и освободить ее после использования, так можно?
Или будет неудобно заводить несколько доп. переменных?
Вроде иметь постоянно в доступном месте и цвет и координаты - удобно...
Или все же такой вариант перегрузит словарь?
|
|
|
|
Добавлено: Вт янв 06, 2009 04:53 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Да, так бывает. Но это не означает, что простые в реализации механизмы надо... забыть? Постеняться предложить?
Да, так бывает. Но это не означает, что простые в реализации механизмы надо... забыть? Постеняться предложить?
|
|
|
|
Добавлено: Вс янв 04, 2009 20:10 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Чем удобнее использование, тем труднее реализация
Чем удобнее использование, тем труднее реализация
|
|
|
|
Добавлено: Вс янв 04, 2009 20:05 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): У Хищника плохое настроение. Фрейм - тоже неплохое решение. А локальные переменные - как раз компромисс между стеком и более высокоуровневыми языками.
Ну так и получается "зачем бузина в огороде, есть стандартом давно определен дядька в Киеве?". Зачем искать компромисс в отсутствие конфликта? Локальные переменные относятся к другому классу механизмов, и не скажу, что они кардинально улучшают ситуацию. Да, оно "можно" (волшебное слово) и в Форте, только по шкале трудоемкость/эффект занимает далеко не лидирующие позиции.
[quote="вопрос"]У Хищника плохое настроение. Фрейм - тоже неплохое решение. А локальные переменные - как раз компромисс между стеком и более высокоуровневыми языками.[/quote]
Ну так и получается "зачем бузина в огороде, есть стандартом давно определен дядька в Киеве?". :D Зачем искать компромисс в отсутствие конфликта? Локальные переменные относятся к другому классу механизмов, и не скажу, что они кардинально улучшают ситуацию. Да, оно "можно" (волшебное слово) и в Форте, только по шкале трудоемкость/эффект занимает далеко не лидирующие позиции.
|
|
|
|
Добавлено: Вс янв 04, 2009 19:55 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
У Хищника плохое настроение. Фрейм - тоже неплохое решение. А локальные переменные - как раз компромисс между стеком и более высокоуровневыми языками.
У Хищника плохое настроение. Фрейм - тоже неплохое решение. А локальные переменные - как раз компромисс между стеком и более высокоуровневыми языками.
|
|
|
|
Добавлено: Вс янв 04, 2009 19:43 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): а так. Не изобретать самому, а посмотреть как уже сделано в различных форт-системах. На форт-системах свет клином не сошелся. mOleg писал(а): В том же СПФ, к примеру, В форке тоже оригинальный вариант, SwiftForth и друге буржуйские форты поддерживают локалсы. А то я всего этого не видел mOleg писал(а): Более того, есть даже некий стандарт на них.
Идущий лесом.
[quote="mOleg"]а так. Не изобретать самому, а посмотреть как уже сделано в различных форт-системах. [/quote] На [i]форт[/i]-системах свет клином не сошелся. [quote="mOleg"]В том же СПФ, к примеру, В форке тоже оригинальный вариант, SwiftForth и друге буржуйские форты поддерживают локалсы. [/quote] А то я всего этого не видел :)) [quote="mOleg"]Более того, есть даже некий стандарт на них.[/quote]
Идущий лесом.
|
|
|
|
Добавлено: Вс янв 04, 2009 18:53 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Я не знаю насчет всех других, но как вариант используется адресация параметров относительно стекового кадра, передаваемого, например, в ebp. Кроме того, нет проблем с именованием - имена локальных переменных точно так же помещаются в таблицу символов. А в Форте как? Помещать имена в общий словарь? Помещать в какую-то отдельную область памяти (какую? сколько ей места дать? что делать, если оно кончилось? как модифицировать поиск, чтобы сначала посмотреть локальные параметры?)? Или все-таки адресовать переданные параметры относительно вершины стека, пусть и с потенциальными проблемами устойчивости против целенаправленного слома?
а так. Не изобретать самому, а посмотреть как уже сделано в различных форт-системах.
В том же СПФ, к примеру,
В форке тоже оригинальный вариант,
SwiftForth и друге буржуйские форты поддерживают локалсы.
Более того, есть даже некий стандарт на них.
[quote="Хищник"]Я не знаю насчет всех других, но как вариант используется адресация параметров относительно стекового кадра, передаваемого, например, в ebp. Кроме того, нет проблем с именованием - имена локальных переменных точно так же помещаются в таблицу символов. А в Форте как? Помещать имена в общий словарь? Помещать в какую-то отдельную область памяти (какую? сколько ей места дать? что делать, если оно кончилось? как модифицировать поиск, чтобы сначала посмотреть локальные параметры?)? Или все-таки адресовать переданные параметры относительно вершины стека, пусть и с потенциальными проблемами устойчивости против целенаправленного слома?[/quote]
а так. Не изобретать самому, а посмотреть как уже сделано в различных форт-системах.
В том же СПФ, к примеру,
В форке тоже оригинальный вариант,
SwiftForth и друге буржуйские форты поддерживают локалсы.
Более того, есть даже некий стандарт на них.
|
|
|
|
Добавлено: Вс янв 04, 2009 18:40 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): именно, но там нет опасности запортить этот кадр. И нет дополнительных усилий для сохранения кадра. Поскольку есть ограничения на использование кадра, нет и опасности. О чем речь-то? Я не делаю "как в Си", я делаю "минимально по сложности, максимально по эффекту". вопрос писал(а): Как работают параметры? В смысле, что происходит, когда вызывается ARG0 ? Смотрится верхнее число со стека FrameStack, это Depth на момент вызова FRAME{ (т.е. обычно вход в слово, хотя можно изменить баланс стека, но запомнено будет все равно то, что есть). ARG0 положит на стек адрес вершины стека на момент вызова FRAME{, ARG1 = ARG0 - 4, ARG2 = ARG0 - 8 и т.д. вопрос писал(а): По крайней мере можно включить в вызов параметров предупреждение, что вершина стека сместилась дальше, чем вызываемый адрес.
Можно включить, а можно и отнестись как к данности. Я ориентировался в большой степени на слова для работы с графическими примитивами, когда в качестве параметров передается приличный список координат, размеров, цветов, стилей и тому подобного. Там все эти параметры остаются на стеке длительное время, практически на протяжении всего слова, удаляясь серией DROP в конце.
[quote="вопрос"]именно, но там нет опасности запортить этот кадр. И нет дополнительных усилий для сохранения кадра.[/quote] Поскольку есть ограничения на использование кадра, нет и опасности. О чем речь-то? Я не делаю "как в Си", я делаю "минимально по сложности, максимально по эффекту". [quote="вопрос"]Как работают параметры? В смысле, что происходит, когда вызывается ARG0 ?[/quote] Смотрится верхнее число со стека FrameStack, это Depth на момент вызова FRAME{ (т.е. обычно вход в слово, хотя можно изменить баланс стека, но запомнено будет все равно то, что есть). ARG0 положит на стек адрес вершины стека на момент вызова FRAME{, ARG1 = ARG0 - 4, ARG2 = ARG0 - 8 и т.д.
[quote="вопрос"]По крайней мере можно включить в вызов параметров предупреждение, что вершина стека сместилась дальше, чем вызываемый адрес.[/quote]
Можно включить, а можно и отнестись как к данности. Я ориентировался в большой степени на слова для работы с графическими примитивами, когда в качестве параметров передается приличный список координат, размеров, цветов, стилей и тому подобного. Там все эти параметры остаются на стеке длительное время, практически на протяжении всего слова, удаляясь серией DROP в конце.
|
|
|
|
Добавлено: Сб янв 03, 2009 23:27 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: Я не знаю насчет всех других, но как вариант используется адресация параметров относительно стекового кадра, передаваемого, например, в ebp. именно, но там нет опасности запортить этот кадр. И нет дополнительных усилий для сохранения кадра.
Как работают параметры? В смысле, что происходит, когда вызывается ARG0 ? По крайней мере можно включить в вызов параметров предупреждение, что вершина стека сместилась дальше, чем вызываемый адрес.
[quote]Я не знаю насчет всех других, но как вариант используется адресация параметров относительно стекового кадра, передаваемого, например, в ebp. [/quote] именно, но там нет опасности запортить этот кадр. И нет дополнительных усилий для сохранения кадра.
Как работают параметры? В смысле, что происходит, когда вызывается ARG0 ? По крайней мере можно включить в вызов параметров предупреждение, что вершина стека сместилась дальше, чем вызываемый адрес.
|
|
|
|
Добавлено: Сб янв 03, 2009 22:11 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Я не знаю насчет всех других, но как вариант используется адресация параметров относительно стекового кадра, передаваемого, например, в ebp. Кроме того, нет проблем с именованием - имена локальных переменных точно так же помещаются в таблицу символов. А в Форте как? Помещать имена в общий словарь? Помещать в какую-то отдельную область памяти (какую? сколько ей места дать? что делать, если оно кончилось? как модифицировать поиск, чтобы сначала посмотреть локальные параметры?)? Или все-таки адресовать переданные параметры относительно вершины стека, пусть и с потенциальными проблемами устойчивости против целенаправленного слома?
Я не знаю насчет всех других, но как вариант используется адресация параметров относительно стекового кадра, передаваемого, например, в ebp. Кроме того, нет проблем с именованием - имена локальных переменных точно так же помещаются в таблицу символов. А в Форте как? Помещать имена в общий словарь? Помещать в какую-то отдельную область памяти (какую? сколько ей места дать? что делать, если оно кончилось? как модифицировать поиск, чтобы сначала посмотреть локальные параметры?)? Или все-таки адресовать переданные параметры относительно вершины стека, пусть и с потенциальными проблемами устойчивости против целенаправленного слома?
|
|
|
|
Добавлено: Сб янв 03, 2009 21:39 |
|
|
|
|