вот

BEGIN
...
...

BEGIN
...
...
[ SWAP ]

UNTIL
...
UNTIL

в общем это возможно только в том случае, если форт хранит адреса переходов при компиляции на основном стеке
получается прыжок - первый UNTIL (внутренний) - к первому BEGIN
внешний UNTIL - ко второму BEGIN

Можно конечно, но зачем так извращаться?

По АНСИ, законна в том случае, если control flow stack = data stack. Т.е. практически всегда.

может в некоторых версиях такой код и будет работать, но в любом случае это плохая практика. имхо, форт не для этого

А потому хак, полагающийся на особенность реализации ;)

делать так не стоит, т.к. часто на вершине стека данных еще лежит и контрольное значение, т.е. нужно минимум 2SWAP . В любом случае такая вещь будет непереносимой (на что можно бы наплевать) и непонятной, что хуже. Правильнее бы придумать более удачное имя и подправить синтаксис.
Т.е. что-то типа:
: ANOTHER SWAP ; IMMEDIATE
ну и дальше пользоваться им, тогда, кстати, и портировать будет несколько проще.

В отдельной, системозависимой библиотеке следует завести слово

И тогда:


Аналогичную задачу решает
http://spf.cvs.sourceforge.net/viewvc/s ... iew=markup

Самое интересное что явно можно без этаких извращений обойтись
просто написав код по другому.
По моему такими вещами заниматься не только бессмыслено но и вредно.

А может быть он обфускатор кода на Форте пишет?

ответ на тему топика:
НЕЗАКОННО - ВАС ПОСОДЮТ!

Я пытался придумать ещё несколько простых приёмов оптимизации в рамках того небольшого эксперимента...
Возникла вот такая идея, кое в каких случаях она очень помогла бы.
Но если эту идею считают вредной, то, видимо, она не так хороша

да, я уже понял, разве только в редких случаях

Как раз, когда идею считают вредной - она самая хорошая Вот, из ОЧЕНЬ старого (почему-то вспомнилось в тему) :

История Мела, Настоящего Программиста

Я читал в одной статье, что Настоящие Программисты пишут на ФОРТРАНе. Может сейчас так оно и есть, в эту эру упадка, легкого пива, ручных калькуляторов и "дружественного" софта, но в Старые Добрые Времена, когда слово "софт" звучало забавно, и Настоящие Компьютеры были сделаны из магнитных барабанов и вакуумных трубок, Настоящие Программисты писали в машинных кодах. Не на ФОРТРАНе. Не на РАТФОРе. Даже не на языке ассемблера. Машинный код. Чистые, неприкрытые, непонятные шестнадцатеричные числа.

Уже выросло целое поколение программистов, не помнящих этого славного прошлого, и я считаю своим долгом описать, настолько хорошо, насколько смогу, несмотря на разницу в возрасте, как пишет код Настоящий Программист. Я буду называть его Мел, потому что именно так его и звали.

Я впервые встретил Мела, когда пришел работать в Роял МакБи Компьютер Корпорейшн, ныне несуществующее подразделение компании по изготовлению пишущих машинок. Эта фирма сделала LGP-30, маленький, дешевый (по тем временам) компьютер на магнитных барабанах и только-только приступила к разработке RPC-4000, гораздо более совершенного, большего, лучшего, более быстрого компьютера на... магнитных барабанах. Магнитые сердечники были слишком дорогими, и все равно уже сходили на нет. (Вот почему вы ничего не слышали ни про эту компанию, ни про этот компьютер.)

Меня наняли написать компилятор ФОРТРАНа. Мел не любил компиляторы.

"Если программа не может модифицировать свой собственный код,"- говорил он,-"то что в ней может быть хорошего?".

Мел написал в шестнадцатеричных числах самую популярную программу компании. Она работала на LGP-30 и играла в "блэк джэк" с потенциальными покупателями на компьютерных выставках. Эффект был всегда впечатляющий, павильон с LGP-30 был все время забит, а продавцы из IBM стояли неподалеку, переговариваясь. Помогало это или нет продаже компьютеров - этот вопрос мы никогда не обсуждали.

Задачей Мела было переписать программу, игравшую в "блэк джэк", для RPC-4000. (Портировать? Что значит это слово?) На новом компьютере схема адресации была один плюс один, то есть каждая машинная инструкция, кроме кода операции и адреса необходимого операнда, содержала еще один адрес, который указывал где на вращающемся барабане находилась следующая инструкция. Говоря современным языком, каждая инструкция сопровождалась GO TO! Положите *это* в трубку Паскаля и закурите.

Мел любил RPC-4000, потому что он мог оптимизировать свой код: то есть расположить инструкции на барабане таким образом, чтобы когда одна инструкция заканчивала свою работу, вторая находилась как раз под "считывающей головкой" и была готова для немедленного исполнения. Существовала программа, которая умела так делать, "оптимизирующий ассемблер", но Мел отказывался ее использовать.

"Ты никогда не знаешь, где она что расположит." - объяснял он - "И тебе придется использовать отдельные константы."

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

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

Мел также никогда не писал циклов для задержек, даже когда упрямый Флексорайтер для корректной работы требовал задержку между выводом символов. Он просто располагал инструкции на барабане таким образом, чтобы каждая следующая была как раз *после* считывающей головки, когда была нужна; барабан должен был совершить еще один полный оборот, чтобы найти следующую инструкцию. Он придумал незабываемое название этой процедуре. Хотя "оптимальный" - это абсолютный термин, как "уникальный", в разговорной речи его часто делают относительным: "недостаточно оптимальный", или "менее оптимальный", или "не очень оптимальный". Мел называл расположение инструкций для максимальной задержки "наиболее пессимальным".

После того, как он закончил писать программу, играющую в "блэк джэк" и запустил ее ("Даже инициализатор соптимизирован", сказал он гордо), он получил Служебную Записку от отдела продаж. Программа использовала элегантный (соптимизированный) генератор случайных чисел для перемешивания "карт" и для работы с "колодой", некоторые из менеджеров считали его слишком честным, так как покупатели иногда проигрывали. Они хотели, чтобы Мел изменил программу таким образом, чтобы, установив переключатель на консоли, они могли менять карты и давать покупателю выиграть.

Мел упрямился. Он чувствовал, что это нечестно, как оно и было, что это покушение на целостность его личности как программиста, а так оно и было, и он отказался это делать. С Мелом говорил Главный Менеджер, и Большой Начальник, и, под нажимом начальника, некоторые Друзья Программисты. Мел в итоге сдался и написал код, но сделал все наоборот, когда переключатель включали, игра начинала жульничать и все время выигрывала. Мел был в восторге, утверждал, что это все его неконтролируемо честное подсознание и категорически отказывался это править.

Когда Мел ушел из компании на более привлекательное место, Большой Начальник попросил меня взглянуть на код и посмотреть, смогу ли я найти проверку и обратить ее. Я неохотно согласился. Чтение кода Мела было настоящим приключением.

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

Наверное, самый страшный шок я испытал, когда нашел невинный цикл, в котором не было условия. Вообще не было. *Никакого*. Здравый смысл подсказывал, что это должен был быть замкнутый цикл, где программа должна была зациклиться навсегда, навечно. Однако, программа входила в это место и спокойно выходила с другой стороны. Я две недели разбирался в чем дело.

В RPC-4000 была включена по-настоящему современная вещь, под названием индексный регистр. Он позволял программисту написать цикл с использованием индексированной инструкции; при прохождении этого цикла число из индексного регистра добавлялось к адресу этой инструкции, и таким образом он ссылался на следующие данные из серии. Программисту требовалось лишь инкрементировать индексный регистр при каждом проходе цикла. Мел его никогда не использовал.

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

Ключ к разгадке обнаружился, когда я заметил бит индексного регистра, бит, который находился между адресом и кодом операции в инструкции, был включен... но Мел ведь никогда не использовал индексный регистр, все время оставлял его равным нулю. И тут свет прозрения ослепил меня.

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

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

Когда я ушел из компании, "блэк джэк" все еще жульничал, стоило включить нужный переключатель, и, я думаю, именно так и должно было быть. Я чувствовал себя неловко, пытаясь хакнуть код Настоящего Программиста.

Было отправлено в USENET автором Эдом Hэсером 21 мая 1983 года.

Если специально культивировать "нетривиальность", ничего хорошего обычно не получается. Гениальная идея вполне может выглядеть странно, но вот обратное срабатывает крайне редко.

К счастью еще не перевелись места, где такое вполне настоящее.