FORH

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

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

> Код НЕ получается быстрым и компактным

У кого как.

> хороший компилятор C оптимизирует лучше, чем человек.

Чушь. Компилятор может оптимизировать больше кода, но квалифицированный человек получит лучший код.

Вопрос баланса затрат и выигрыша, всего-навсего.

> Чушь. Компилятор может оптимизировать больше кода, но квалифицированный человек получит лучший код.

Чушь. Квалифицированный человек в подавляющем большинстве случаев всё равно получит худший код.

Можно чуть больше по теме? ... :-[

а Насчет асма - я писал на нем, так как был его фанатом. В свое время у меня не было нормального И-Нета чтобы скачать компилятор, но был компилятор Ассемблера - MASM. Вот я и занялся асмом - а что еще было делать? ;)

Но все-таки, я думаю, что человек способен лучше компилятора код получить... ну смотря еще кто, ессно.

>Но все-таки, я думаю, что человек способен лучше компилятора код получить...

Способен. Но писать будет хуже. См. тему сначала.

> Но все-таки, я думаю, что человек способен лучше компилятора код получить... ну смотря еще кто, ессно.

В средних объёмах - не говоря уж о больших - не способен. В принципе.

Да, ТЕОРЕТИЧЕСКИ, ничто не мешает написать на ассемблере любую программу, вылизав код до полной оптимальности. На практике это невозможно.

> Да, ТЕОРЕТИЧЕСКИ, ничто не мешает написать на ассемблере любую программу, вылизав код до полной оптимальности. На практике это невозможно.

Гыгы =) и я о том же ;)

а теперь по теме вопрос... есть компиляторы форта, которые компилируют программу в исполняемый файл? а то я компилирую Hello World... файл размером в 93 КБ получается =)

>а теперь по теме вопрос... есть компиляторы форта, которые компилируют программу в исполняемый файл?

Полно. Самый известный - SP-Forth.

>а то я компилирую Hello World... файл размером в 93 КБ получается =)

Там обычно вся Форт-система внутри. По-моему, со времён DOS нет Фортов, которые бы вычищали ненужные библиотеки в себе. Ибо 100кБ в наш век - смешно :) И уже лет 10, как смешно...

но ведь программа на форте будет содержвать много подпрограмм. постоянные вызовы подпрограмм. разве не так? это не снизит производительность?

> но ведь программа на форте будет содержвать много подпрограмм. постоянные вызовы подпрограмм. разве не так? это не снизит производительность?

Ты лучше спроси - использует ли этот СП-Форт _все_ регистры проца и на сколько эффективно? И уточни - на каких именно процессорах... ;)

использует ли СП-форт _все_ регистры проца и насколько эффективно? :))

я говорю об IA-32 :) (или как эти процессоры называются =)) )

Мантру затверди: программы на форте плохо оптимизируются.

> Мантру затверди: программы на форте плохо оптимизируются.

постоянно меня огорчают вот такими сообщениями...

да нормально вполне. просто оптимизатор писать упаришься — это надо сначала стековый код развернуть назад в нечто, подобное AST или IR. а потом отлично оптимизируется стандартными техниками. просто никто не заморачивается, насколько я знаю, такими штуками, потому что и без того вполне шустро работает.

я когда-то делал прототип, оно даже чего-то там выплёвывало в итоге. ну и забросил — не надо, и так быстро.

>преждевременная ручная оптимизация суть пустая трата времени

Да-да, ещё расскажите что память и процессоры нынче дешёвые. "А мужики-то не знают" (к).

>но ведь программа на форте будет содержвать много подпрограмм. постоянные вызовы подпрограмм. разве не так? это не снизит производительность?

Смотря какой Форт, смотря как написан транслятор. SP-Forth, генерирующий обычный машкод, принципиально не отличатся от любого другого нативно компилируемого ЯВУ. Одно слово - один call.

да ещё как отличается. во-первых, учитывай размеры слов. таки то, что на других языках — одна функция, на форте — стихи из нескольких десятков словей.

>Мантру затверди: программы на форте плохо оптимизируются.

На всяких Фибоначи и Аккерманах SP-Forth себя хорошо показывает. Хотя вызовы высокоуровневхы слов - всегда слабое место Форта: http://balancer.ru/2003/08/13/post-261707.html

>да ещё как отличается. во-первых, учитывай размеры слов. таки то, что на других языках — одна функция, на форте — стихи из нескольких десятков словей.

Дурной стиль писать простыни на несколько экранов.

На любом языке надо писать так, чтобы токен состоял из 7+/-2 субтокенов.

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

да штука в том, что на форте практически нет неделимых конструкций. на обычном языке типа того же си, например, ты не спожешь разнести начало, проверку и инкремент того же for'а по разным процедурам. не f = a(), а именно в одной процедуре остаётся 'f', во второй — '=', в третьей — ещё что-то. то есть, присваивание неделимо. а в форте — делимо. (понятно, что пример глупый) отсюда слова разбиваются не всегда так же, как в си, например. отсюда же их ощутимо больше, обычно.

я уж молчу про создание управляющих конструкций «на лету» и прочие прелести (да тот же doer). насколько элегантно это в форте — настолько коряво в си (ничего, что я к си привязался?).

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

>но это в том же си неудобно. семантические еденицы побольше.

Ты не поверишь, но даже в PHP вполне удобно :) Вот типичный пример.
Код сегодняшний:

    function admin_url() { return config('admin_host_url').'/images/gallery/'.$this->id().'/'; }

    function default_image() { return object_load('aviaport_image', $this->default_image_id()); }
    
    function data_providers()
    {
        $this->add_template_data('banner_right_zone', 108);
        $this->add_template_data('right_menu', 'right-menu/gallery.html');
        $this->add_template_data('skip_gallery', $this->id());

        return array(
            'images_list' => bors_get_cross_objs(object_load('aviaport_image_gallery', $this->id()), 'aviaport_image'),
            'stories_list' => bors_get_cross_objs(object_load('aviaport_image_gallery', $this->id()), 'aviaport_digest_story'),
        );
    }

Это уже 2/3 всего класса контроллера такой, вот, страницы:
http://www.aviaport.ru/images/archive/11/

Получается весьма компактно и удобно :)

наблюдаю страшное дублирование кода. отчего же, вполне поверю — страшно и коряво. это он, Глобальный и Надёжный, да. %-)

>наблюдаю страшное дублирование кода

На Форте, в случае большой системы, конечно, а не скрипта в 
тысячу-другую строк,  сильно компактнее не получится :)

...

Вон, в L2Fortress на Форте всего
$ find . -name '*.f'|xargs cat|wc -l
29607 строк набирается.

 А лепить уже ужасы приходится, вида:

: jail-me ( items_count -- )
    int to jail-to-collect

    self player? unless
        jail-to-collect "jail-me"  self getPlayer p-do-player
        exit
    then

    jail-to-collect jail-total-collected + to jail-total-collected

    true    to jailed?
    false   to can-teleport?

    jail-coords-back unless
        loc@ coords>s to jail-coords-back
    then

    10000 karma+!
    -1 self "updateNoChannel" { int.class } jexec

    "You are jailed! To free you must collect [ jail-to-collect ] item(s) from killed mobs" parse
    "Jail system" self .tell

    "help.htm" show

    jail-coords list-rev> drop jump
    suv-save-all
;


лепить :)

...

Из того, с чем работаю в последние пару лет, нагляднее всего
(особенно, через полгода незалезания в сорцы) получается
именно на PHP :)

Ещё нагляднее на Питоне должно быть, но пока я его не использую.

>А лепить уже ужасы приходится

потому что они провтыкали основной принцип использования форта. «никогда и ни за что не пишите на форте задачи! пишите на форте языки для решения задач!»

%-)

>потому что они провтыкали

Не "они", тогда уже, а я :)

>«никогда и ни за что не пишите на форте задачи! пишите на форте языки для решения задач!»

Именно язык и написан. Увы, широкий спектр задач требует реализации универсального языка. А все универсальные языки - неудобны :D

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

> "«никогда и ни за что не пишите на форте задачи! пишите на форте языки для решения задач!»"

эт почему?? :( задачи что ли неьзя на форте писать?

можно, но очень геморно. на ассемблере тоже можно, но не лучше ли сделать на асме транслятор с чего-то более удобного?

собственно, если *правильно* писать на форте, то в итоге всё равно получается DSL, хоть ты лопни. %-)

но все-таки можно? :) это главное. на асме транслятор писать? :) ну есть ФАСМ написанный на асме... но, думаю, что все-таки трансляторы лучше писать на ЯВУ, ибо сложно очень на ассемблере это делать %) DSL Это что? :) я поискал в Нете, и нашел это: http://ru.wikipedia.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B...

ты об этом DSL? :)

KRoN73, ну я об этом и говорю. одно слово - один CALL, но в Форте ведь все на словах (ведь так?), а от этого сплошные CALLы будут. или нет? О_о да и, наверн, можно написать, чтоб некоторые слова не вызывались а вставлялись сразу как INLINE-функции С... но так будет размер кода огромный :) если б можно было вручную выбирать, вставляться будет или как отдельная процедура...

>KRoN73, ну я об этом и говорю. одно слово - один CALL, но в Форте ведь все на словах (ведь так?), а от этого сплошные CALLы будут. или нет?

Как и в любом другом языке. Однин метод/функция/процедура - один call. Не считая inline, конечно. Но inline и на Форте делается.

Управляющие конструкции на Форте - не call, а в код разворачиваются, опять же, как и в других ЯВУ.

Различий нет :)

> собственно, если *правильно* писать на форте, то в итоге всё равно получается DSL, хоть ты лопни. %-)

Не поверишь, но на Хаскеле - то же самое. И на Лиспе. И даже, говорят, на C++.

> Как и в любом другом языке. Однин метод/функция/процедура - один call.

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

>Вообще-то нет. Например, в любом языке, умеющем хвостовые вызовы - jump.

А в прямом шитом коде - вообще любой низкоуровневый вызов - это jmp [reg] :) Из-за этого, кстати, на x86 раньше (не знаю, как сейчас) прямой шитый код Форта при вызове низкоуровневых определений был быстрее подпрограмного.

...

А хвостовую рекурсию в Форте, как раз, элементарно сделать. Именно скомпилировать обычный jmp (branch в терминах Форта) в начало текущего слова :)

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

на цпп вряд ли. близко, но не то.

ЩИТО? O_O

угу. пока остальные только мечтали, Forth уже использовал continuations. %-)

>Кстати, а нельзя как-то так сделать, чтоб форт работал без виртуальной машины?

SP-Forth компилирует нативный x86 код.

>чтоб как-то использовался только один стек...

? Э... Не понял :) На Форте по определению, минимум, два стека. Если же фраза звучит «использовался только стек», то совсем непонятно. x86 полный набор вычислений только через регистры обеспечивает :)

>Просто я терпеть не могу виртуальные машины типа Java и т.д.

Ну так на Java более-менее классические Форт - только мой JBForth мне и известен :D Остальные мне известные - только компиляторы Форт-кода без интерактивных режимов.

> ? Э... Не понял :) На Форте по определению, минимум, два стека. Если же фраза звучит «использовался только стек», то совсем непонятно. x86 полный набор вычислений только через регистры обеспечивает :)

не... я то и имел в виду - 1 стек, а не два... хотя да.. в форте их ведь два... а нету процессоров, которые поддерживают два стека и чтоб для этого не надо было никаких ВМ? или как... :)

я вот такую программу скомпилил компилятором Forthec:

: CCCCC 2 + 3 * ; 10 CCCCC .

вот, что получилось: процедура CCCCC

; CCCCC @@lbl_4343434343: sub ipstackptr,4 mov eax,ipstackptr pop dword ptr [eax] add dword ptr [esp],2 mov eax,3 imul dword ptr [esp] mov [esp],eax @@lbl_4343434343_return: mov eax,ipstackptr add ipstackptr,4 jmp dword ptr [eax]

вычисление прямо в стеке... но ведь если бы использовались регистры, а не данные прямо в стеке слаживались/умножались - было бы быстрее.. или нет? :)

вижу по тексу, который мне Forthec выдал, что даже адреса возврата не в обычном стреке лежат, а "эмулируется" и стек возвратов и стек вычислений... или как они называются :-[ :

mov eax,ipstackptr pop dword ptr [eax]

но зачем? разве это скорость выполнения не снижает? %)

кстати, а существуют процессоры, которые "аппаратно" поддерживают два стека и для которых не надо это все "эмулировать"? :)

я заметил, что многие фортеры Джаву любят... лично мне она как язык не нравятся из-за виртуальных машин ....

А вот Форт очень понравился своей необычностью, постфиксной записью. е такой как все...

>И даже, говорят, на C++

правду говорят. другое дело, что ограничений на его проектирование в C++ на порядок больше

>а нету процессоров, которые поддерживают два стека и чтоб для этого не надо было никаких ВМ?

Ещё на древних PDP-машкодах, любой из регистров общего назначения мог адресовать автоинкрементом и автодекрементом. Т.е. мог быть указателем стека. R7 был зарезервирован под указатель инструкций (да-да, IP там был обычным регистром и JMP выполнялся загрузкой в этот регистр числа), R6 был регистром, через который сохранялись/загружались адреса по call. Т.е. классический стек вызовов. оставшиеся шесть регистров могли использоваться под 6 _пользовательских_ стеков :)

mov r0, (r1)+ == записали содержимое r0 по адресу, на который указывает r1 и инкрементировали r1. Это push r0 через стек r1.

mov -(r1), r2 == декрементировали r1 и результат, находящийся по полученному адресу записали в r2. Это pop r2 из стека r1

:)

>вычисление прямо в стеке... но ведь если бы использовались регистры, а не данные прямо в стеке слаживались/умножались - было бы быстрее.. или нет? :)

В SP-Forth вершина стека хранится в eax. При вычислениях - индивидуально. Иногда сразу со стеком операция, иногда предварительно в регистры грузят. Как быстрее, так и делают.

Конкретный код сейчас лениво смотреть. У меня SP-Forth под Linux не установлен, а в винду перегружаться ломает :)

>кстати, а существуют процессоры, которые "аппаратно" поддерживают два стека и для которых не надо это все "эмулировать"? :)

Да. Именно те самые Форт-процессоры. Которые сейчас стали Java-процессорами часто :)

>я заметил, что многие фортеры Джаву любят... лично мне она как язык не нравятся из-за виртуальных машин ....

Java на уровне JVM - тот самый Форт :D Два стека, стековая безрегистровая машина. Типа, «поместить 1-й параметр метода в стек», «поместить в стек число 2», «умножить», «поместить результат в 3-ю переменную класса».

> а нету процессоров, которые поддерживают два стека и чтоб для этого не надо было никаких ВМ? или как... :)

мотороллеры m680x0, древние VAX PDP-11 и т.п.

в мотороллерах был ортогональный набор команд с двойной-тройной косвенной адресацией.. то есть, команды вроде move.l (a1)+, (a2)- ; в Си: *a2-- = *a1++

Сишный /* *dst++ = *src-- */оттуда же и пошел, из этих ассемблеров

mc68k позволял делать финты ушами вроде move.l [ (a1)+ 8*a2 ]-, [ (a3)- 32*a4 ] -- одной командой

то есть, для этих стеков практически ничего не надо делать особенного, всё было во встроенном ассемблере > вычисление прямо в стеке... но ведь если бы использовались регистры, а не данные прямо в стеке слаживались/умножались - было бы быстрее.. или нет? :)

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

> кстати, а существуют процессоры, которые "аппаратно" поддерживают два стека и для которых не надо это все "эмулировать"? :)

ну если не брать совсем экзотического того 4 stacks vliw cpu, а что-то промышленное, подойдут процессоры с ортогональной системой команд (где например в цикле LOOP вместо cx может использоваться любой доступный регистр, то есть, любая команда может работать с любым регистром, нет жестко заданных "регистров по умолчанию" для команды). Какой-нибудь мотороллер или может быть SPARC с регистровыми окнами.

в мотороллах 680x0 примерно то же самое. Только было 8 адресных регистров и 8 регистров данных. Все эти сишные x++, --y пошли прямиком из этих ассемблеров.

> на цпп вряд ли. близко, но не то.

Зависит от уровня понимания того, что такое "правильно писать" на цпп.

Впрочем, я цпп не знаю, передаю из других рук.

Вот вы демагогию развели - несколько стеков для процессора - а подумать не слабо зачем это ? Откопали хлам из 70 годов... Не надо забывать что у того же 8086 расширенный набор инструкций - а начиная с 80286 он еще шире с появлением mmu а уж с появлением 386 :) при их помощи можно сделать все что вы тут написали легко и непринужденно правда не одной командой. Доступ на запись к IP круто - а какое преимущество он дает по сравнению с jmp ? В защищенном режиме этих стеков знаете сколько ? правильно - сколько душе угодно без всякого напряга потому что у каждой задачи свой контекст регистров и он автоматом сохраняется и восстанавливается при переключении задач. cx вам для loop жалко - никто не запрещает заменить на
dec регистр
jnz куданадо в разумных пределах
автоинкремент и автодекремент нужен - cld/std и цепочные инструкции вам в руки. Даже без mmu стеков для задачи можно организовать сколько душе угодно - пока память не кончится - вспомните первую версию windows которая работала на процессорах без mmu.
Думаете когда мне надо массив скопировать с перестановкой элементов и я пишу
*dst++ = *src--
это я написал потому что у древних процессоров можно было сделать это одной инструкцией ассемблера ? Я так не думаю :) Ностальгия дело хорошее только я не вижу никакого преимущества в тех процессорах.

> В защищенном режиме этих стеков знаете сколько ?

сколько? :) разве больше 1? :) хы =) не знал

>> В защищенном режиме этих стеков знаете сколько ?

>сколько? :) разве больше 1? :) хы =) не знал

А повашему сколько ? У каждой задачи свой стек иначе при нарушении указателя стэка в пользовательской задаче у вас бы неминуемо падала вся ОС :) Хотя хз - может у вас именно так...

>Ностальгия дело хорошее только я не вижу никакого преимущества в тех процессорах.

Правильно. Потому что _те_ процессоры были 30 лет назад. и сравнивать надо бы с теми же 8086, где слив возможностей по системе команд очевиден :)

...

А сегодня - да хоть с тем же ARM сравни. x86 по сравнению с ним только застрелиться останется :D