Hi Roman,
Sun Oct 12 2003 21:45, Roman Khvatov wrote to Ilia Tarasov:
IT>> А прямое соответствие конструкций высокого уровня машинному коду не IT>> лучше?
RK> Hет, не лучше. Это тупиковая ветвь - сейчас развитие вычислительной RK> техники идет в прямо противоположном направлении. Вполне резонно RK> считается, что компилятор (так как ему не надо быть реализованным в RK> железе) сможет лучше сгенерировать низкоуровневый код, чем заставлять RK> высокоуровневый код исполнять интерпретатором в железе.
Для меня то что ты говоришь - не очевидно. Ссылочки какие-нибудь можешь дать в подтверждение?
Я рассуждаю так. Компилятор может, конечно "сгенерировать" код. Однако, насколько мне известно, AI в компиляторах пока не применяют. Значит, что компилятор всего лишь может выбрать какую-то последовательность команд, которая была "сгенерирована" программистом, писавшим компилятор. Для выбора он использует правила, тоже написанные программистом. Если эти последовательности команд подчинены определенной логике, а именно - образуют Форт-процессор, то результат компиляции будет "очень похож" на Форт. Я пока не встречал формальных (или просто убедительных) доказательств, что при этом получится неэффективный в каком-либо смысле код. С другой стороны, аргументы в пользу Форт-машины мне представляются весомыми, хотя бы из-за отсутствия громоздких операций с фреймами. Однако в выходном коде, возможно, не будет хватать некоторых базовых слов, необходимых для Форт-процессора. Таких слов немного, они часто используются, но все же есть вероятность, что в данной конкретной программе какие-то из базовых слов оказались не нужны. Если компилятор заставить _всегда_ компилировать минимальный набор слов Форт-процессора, это не создаст больших издержек, поскольку кол-во этих слов невелико, а сами они маленькие. Следующий логический шаг - не надо "генерировать" ядро Форт-машины, пусть оно всегда стоит на целевом процессоре. При этом оно "выглядит" как интерпретатор. Из недостатков - надо чуть больше памяти. Из достоинств - целевая программа приобретет свойства интерпретатора.
[...]
RK> Другие Форты? Это не производные, это просто другие версии. Есть хоть RK> один язык, построенный на основе Форта, но не Форт?
Функциональный язык Joy
formatting link
language Joy is a purely functional programming language. Whereas all other functional programming languages are based on the application of functions to arguments, Joy is based on the composition of functions. All such functions take a stack as argument and produce a stack as value. Consequently much of Joy looks like ordinary postfix notation. However, in Joy a function can consume any number of parameters from the stack and leave any number of results on the stack. ... The similarities and differences between Joy and Forth are striking and profound
Язык Stoical, про который я знаю мало, но он есть:
formatting link
was inspired by the classic stack language STOIC. STOIC was developed circa 1977 by Jonathan M. Sachs while at the Biomedical Engineering Center for Clinical Instrumentation under the Massachusetts Institute of Technology Program in Health Sciences and Technology. STOIC was itself preceded by a language called FORTH, developed circa '68
Пока, Алексей