Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
KPG писал(а): Расширение семантики локальных переменных ForthOS Local Variables (google translate) ...
Немного сбивает с толку. Это как chess делает в теме viewtopic.php?f=2&t=3141&view=unread#unreadТак что ль? Впечатление складывается такое
[quote="KPG"] Расширение семантики локальных переменных ForthOS Local Variables (google translate) ... [/quote] Немного сбивает с толку. Это как chess делает в теме http://fforum.winglion.ru/viewtopic.php?f=2&t=3141&view=unread#unread Так что ль? Впечатление складывается такое
|
|
|
|
Добавлено: Вт май 22, 2018 20:35 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Расширение семантики локальных переменных ForthOS Local Variables(google translate) Код: Введение ForthOS намеренно отходит от направления ANSI Forth в реализации «локальных переменных». В ForthOS правильнее назвать объект «локальными константами». Примеры, вероятно, самый простой способ понять объект. Локальные константы
: sum+1 { a1 a2 } a1 a2 + { sum } sum 1+ ;
Скобки указывают ячейки в стеке. Каждая ячейка выталкивается из стека, и ее значение становится доступным как именованный аргумент. Объем таких имен находится в конце функции. Как видно из примера, можно добавлять последовательные имена, поскольку идентифицируются дальнейшие константные значения. Возвращаемые значения (с соблюдением форматирования стека)
: sum+1 { a1 a2 - result } a1 a2 + { sum } sum 1+ ;
Это определение очень похоже на предыдущее, за исключением того, что в исходном определении локальных значений добавлен «результат». «result» не является идентификатором в области действия функции, однако ForthOS записывает, что эта функция приняла два аргумента и возвращает одно значение. При выходе из функции, если стек не изменился ожидаемым образом, выдается исключение. Переменные форматы возврата
: возможно { val - val 'T | F } val 0> if val 1+ true else false then ;
В этом варианте «val 'T | F» указывает на то, что функция возвращает один или два аргумента. Фактические значения не применяются. P.S. В SPF4, наверное, такой синтаксис не обработается.
Расширение семантики локальных переменных [url=http://www.forthos.org/lvars.html]ForthOS Local Variables[/url] (google translate) [code] Введение ForthOS намеренно отходит от направления ANSI Forth в реализации «локальных переменных». В ForthOS правильнее назвать объект «локальными константами». Примеры, вероятно, самый простой способ понять объект. Локальные константы
: sum+1 { a1 a2 } a1 a2 + { sum } sum 1+ ;
Скобки указывают ячейки в стеке. Каждая ячейка выталкивается из стека, и ее значение становится доступным как именованный аргумент. Объем таких имен находится в конце функции. Как видно из примера, можно добавлять последовательные имена, поскольку идентифицируются дальнейшие константные значения. Возвращаемые значения (с соблюдением форматирования стека)
: sum+1 { a1 a2 - result } a1 a2 + { sum } sum 1+ ;
Это определение очень похоже на предыдущее, за исключением того, что в исходном определении локальных значений добавлен «результат». «result» не является идентификатором в области действия функции, однако ForthOS записывает, что эта функция приняла два аргумента и возвращает одно значение. При выходе из функции, если стек не изменился ожидаемым образом, выдается исключение. Переменные форматы возврата
: возможно { val - val 'T | F } val 0> if val 1+ true else false then ;
В этом варианте «val 'T | F» указывает на то, что функция возвращает один или два аргумента. Фактические значения не применяются. [/code]
P.S. В SPF4, наверное, такой синтаксис не обработается.
|
|
|
|
Добавлено: Вт май 22, 2018 09:25 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Victor__v писал(а): А потоконезависимость. Ну, мало ли. Вместо user укажете variable Сейчас можно легко обеспечивать многозадачность, что в целом резко снижает актуальность потоков. К тому же не вполне понятно, как локальные объявления могут быть зависимыми от этого дела. User внутри локального объявления все равно user, а variable все равно variable. Victor__v писал(а): Значит >R 2>R 2R> плохо, бектрекинг плохо Использование стека возвратов не по назначению - это хак. Бектрекинг тут ни при чем, поскольку представляет собой алгоритмический подход, независимо от используемого языка. Плох не сам подход как таковой, а его неподходящее применение.
[quote="Victor__v"]А потоконезависимость. Ну, мало ли. Вместо user укажете variable [/quote] Сейчас можно легко обеспечивать многозадачность, что в целом резко снижает актуальность потоков. К тому же не вполне понятно, как локальные объявления могут быть зависимыми от этого дела. User внутри локального объявления все равно user, а variable все равно variable.
[quote="Victor__v"]Значит >R 2>R 2R> плохо, бектрекинг плохо[/quote] Использование стека возвратов не по назначению - это хак. Бектрекинг тут ни при чем, поскольку представляет собой алгоритмический подход, независимо от используемого языка. Плох не сам подход как таковой, а его неподходящее применение.
|
|
|
|
Добавлено: Ср окт 12, 2016 03:12 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Граничность то и подразумевает, что поместить можно всё что угодно А переносимость... Скорее моё специфическое требование. Чем меньше в коде вызовов, тем легче провести целевую компиляцию. Займусь этим как-нибудь, когда не в лом будет. Именно это и подразумевалось. А потоконезависимость. Ну, мало ли. Вместо user укажете variable Цитата: А вот стек возвратов предназначен просто для другого Да, предназначен. Но большая часть стека просто пустует. Непорядок. Цитата: помещать туда данные методологически некрасиво Значит >R 2>R 2R> плохо, бектрекинг плохо. Си отстой а разработчики Winapi переворачиваются в гробу от данной некрасивости
Граничность то и подразумевает, что поместить можно всё что угодно А переносимость... Скорее моё специфическое требование. Чем меньше в коде вызовов, тем легче провести целевую компиляцию. Займусь этим как-нибудь, когда не в лом будет. Именно это и подразумевалось. А потоконезависимость. Ну, мало ли. Вместо user укажете variable :D
[quote]А вот стек возвратов предназначен просто для другого[/quote] Да, предназначен. Но большая часть стека просто пустует. Непорядок. [quote]помещать туда данные методологически некрасиво[/quote] Значит >R 2>R 2R> плохо, бектрекинг плохо. Си отстой а разработчики Winapi переворачиваются в гробу от данной некрасивости :hey;
|
|
|
|
Добавлено: Вт окт 11, 2016 20:03 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Victor__v писал(а): Граничен для всех случаев? Да Немного не понял, что подразумевается под граничностью? Victor__v писал(а): Переносим из одного места в другое? Нет Почему не переносим? Локальные объявления можно написать где угодно. Victor__v писал(а): Доп.расходы? Имеются, тот же jmp строить ( +15 доп.тактов) Да это уже не имеет особого значения. Тут же сработает обычное статическое предсказание перехода, и 15 тактов не будет. Victor__v писал(а): Потоконезависимо? Так же, как и другие слова Форта. А вот стек возвратов предназначен просто для другого, и помещать туда данные методологически некрасиво.
[quote="Victor__v"]Граничен для всех случаев? Да[/quote] Немного не понял, что подразумевается под граничностью?
[quote="Victor__v"]Переносим из одного места в другое? Нет[/quote] Почему не переносим? Локальные объявления можно написать где угодно.
[quote="Victor__v"]Доп.расходы? Имеются, тот же jmp строить ( +15 доп.тактов)[/quote] Да это уже не имеет особого значения. Тут же сработает обычное статическое предсказание перехода, и 15 тактов не будет.
[quote="Victor__v"]Потоконезависимо? [/quote] Так же, как и другие слова Форта.
А вот стек возвратов предназначен просто для другого, и помещать туда данные методологически некрасиво.
|
|
|
|
Добавлено: Вт окт 11, 2016 18:31 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Есть такое. Смотрел эту ветку когда-то. Тогда для меня это вообще была магия форта, непонятная и необъяснимая... А сейчас... Разберёмся немножко. Разрыв определения и определение лок.переменных, нужных слов и т.д. Граничен для всех случаев? Да Гибок при написании? Да Переносим из одного места в другое? Нет Доп.расходы? Имеются, тот же jmp строить ( +15 доп.тактов) Потоконезависимо? Надо учитывать отдельно Использование стека возвратов Граничен для всех случаев? Нет Гибок при написании? без понятия Переносим из одного места в другое? Да Доп.расходы? Имеются, вызов лямбды ( call кажется 30 тактов) , можно обойти, но лень Потоконезависимо? да Локальные слова можно определять и на стеке возвратов. Я так код лямбд на стек переносил
Есть такое. Смотрел эту ветку когда-то. Тогда для меня это вообще была магия форта, непонятная и необъяснимая... А сейчас... Разберёмся немножко. Разрыв определения и определение лок.переменных, нужных слов и т.д. Граничен для всех случаев? Да Гибок при написании? Да Переносим из одного места в другое? Нет Доп.расходы? Имеются, тот же jmp строить ( +15 доп.тактов) Потоконезависимо? Надо учитывать отдельно
Использование стека возвратов Граничен для всех случаев? Нет Гибок при написании? без понятия Переносим из одного места в другое? Да Доп.расходы? Имеются, вызов лямбды ( call кажется 30 тактов) , можно обойти, но лень :) Потоконезависимо? да
Локальные слова можно определять и на стеке возвратов. Я так код лямбд на стек переносил
|
|
|
|
Добавлено: Вт окт 11, 2016 16:18 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
viewtopic.php?f=23&t=2942 - вот здесь пример. Стек возвратов - это хорошо (а на самом деле не очень-то и хорошо), но ведь есть и другие переменные и даже локальные слова, которые в формат целочисленных ячеек не вписываются.
http://fforum.winglion.ru/viewtopic.php?f=23&t=2942 - вот здесь пример. Стек возвратов - это хорошо (а на самом деле не очень-то и хорошо), но ведь есть и другие переменные и даже локальные слова, которые в формат целочисленных ячеек не вписываются.
|
|
|
|
Добавлено: Вт окт 11, 2016 02:15 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Лучше всё ж стек возвратов под локалки. Сразу код на очистку вставить. Организовать доступ и всё. Переопределить слова для организации циклов и операций со стеком возвратов. или мониторим операции со стеком при компиляции слова. И всё, радуемся жизни Однако, проблемы с оптимизацией. Возникала пару раз ситуация, когда надо уже значения локализировать, но один-два параметра тут же нужны. Нужна какая-то карта удаления-локализации. Что-то вроде ->LOC: DLDL , где D означает что значение нужно на стеке и оно там сохраняется, а L просто удаляется со стека. В данном случае всё просто: скомпилим DROP и NIP А как быть в других случаях? А если значений принимается больше?
Лучше всё ж стек возвратов под локалки. Сразу код на очистку вставить. Организовать доступ и всё. Переопределить слова для организации циклов и операций со стеком возвратов. или мониторим операции со стеком при компиляции слова. И всё, радуемся жизни :) Однако, проблемы с оптимизацией. Возникала пару раз ситуация, когда надо уже значения локализировать, но один-два параметра тут же нужны. Нужна какая-то карта удаления-локализации. Что-то вроде ->LOC: DLDL , где D означает что значение нужно на стеке и оно там сохраняется, а L просто удаляется со стека. В данном случае всё просто: скомпилим DROP и NIP А как быть в других случаях? А если значений принимается больше?
|
|
|
|
Добавлено: Пн окт 10, 2016 21:00 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Mihail писал(а): Контролировать выход за отведенный размер стека можно с помощью контрольного значения на этом стеке. Это же просто заплатка, проблема остается.
[quote="Mihail"]Контролировать выход за отведенный размер стека можно с помощью контрольного значения на этом стеке.[/quote] Это же просто заплатка, проблема остается.
|
|
|
|
Добавлено: Ср дек 26, 2012 01:39 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Есть смутное ощущение, что не стоит. Это же все полезет через мультиплексор в timing critical nets. Локальные переменные видятся полезными для разгрузки мозгов программиста, а не для каких-то критичных секций кода. Для форт-процессора можно их реализовать и программно. Опять же не будет фрагментирования накристальной памяти, которая всегда в дефиците.
Есть смутное ощущение, что не стоит. Это же все полезет через мультиплексор в timing critical nets. Локальные переменные видятся полезными для разгрузки мозгов программиста, а не для каких-то критичных секций кода. Для форт-процессора можно их реализовать и программно. Опять же не будет фрагментирования накристальной памяти, которая всегда в дефиците.
|
|
|
|
Добавлено: Вт дек 25, 2012 23:37 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Вот, думаю, имеет ли смысл делать аппаратную поддержку локальных переменных в форт-процессоре?Или же ему хватит простых доп-регистров?
Вот, думаю, имеет ли смысл делать аппаратную поддержку локальных переменных в форт-процессоре?Или же ему хватит простых доп-регистров?
|
|
|
|
Добавлено: Вт дек 25, 2012 22:46 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
mOleg писал(а): что будет после переполнения возможного-то? Если ничего не предпринимать ошибка, может оказаться незаметной. Но переполнение/исчерпание стека - ошибка в любом случае. Контролировать выход за отведенный размер стека можно с помощью контрольного значения на этом стеке. Код: 777777 >L \ Критическая область . . . L> 777777 <> ABORT" выход за отведенный размер L стека"
[quote="mOleg"]что будет после переполнения возможного-то?[/quote] Если ничего не предпринимать ошибка, может оказаться незаметной. Но переполнение/исчерпание стека - ошибка в любом случае. Контролировать выход за отведенный размер стека можно с помощью контрольного значения на этом стеке.
[code] 777777 >L \ Критическая область . . . L> 777777 <> ABORT" выход за отведенный размер L стека" [/code]
|
|
|
|
Добавлено: Вт дек 25, 2012 18:17 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
WingLion писал(а): смешной вопрос, почему для них юзается стек возвратов, а не стек данных, например? Или, проще, для них свой стек организовать? Стек данных более подвижен. Если его использовать, то появление на его вершине результата требовало-бы веселых телодвижений для удаления стекового кадра. В этом смысле стек возвратов более стабилен - кроме некоторых особых слов, стек параметров в пределах одного слова остается неподвижным. Поэтому мы можем в начале слова выделить на нем кадр, а в конце его-же удалить практически с гарантией того, что ничего лишнего не зацепим.
[quote="WingLion"]смешной вопрос, почему для них юзается стек возвратов, а не стек данных, например? Или, проще, для них свой стек организовать?[/quote] Стек данных более подвижен. Если его использовать, то появление на его вершине результата требовало-бы веселых телодвижений для удаления стекового кадра. В этом смысле стек возвратов более стабилен - кроме некоторых особых слов, стек параметров в пределах одного слова остается неподвижным. Поэтому мы можем в начале слова выделить на нем кадр, а в конце его-же удалить практически с гарантией того, что ничего лишнего не зацепим.
|
|
|
|
Добавлено: Вт дек 25, 2012 18:01 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Mihail писал(а): Я предлагаю, разместить эти стеки внутри циклических буферов. без грабель впереди\позади жить не интересно? и что будет после переполнения возможного-то? что же до переписывания механизма исключений, то я таки не очень такому решению рад, потому что оно тоже достаточно опасно.
[quote="Mihail"]Я предлагаю, разместить эти стеки внутри циклических буферов.[/quote] без грабель впереди\позади жить не интересно? и что будет после переполнения возможного-то?
что же до переписывания механизма исключений, то я таки не очень такому решению рад, потому что оно тоже достаточно опасно.
|
|
|
|
Добавлено: Вт дек 25, 2012 17:34 |
|
|
|
|
|
Заголовок сообщения: |
Re: Локальные переменные |
|
|
Mihail писал(а): Я предлагаю, разместить эти стеки внутри циклических буферов. и кто-то на рекурсии с ними вляпается
[quote="Mihail"]Я предлагаю, разместить эти стеки внутри циклических буферов.[/quote] и кто-то на рекурсии с ними вляпается
|
|
|
|
Добавлено: Вт дек 25, 2012 17:33 |
|
|
|
|