Mon Oct 13 2003 22:16, Roman Khvatov wrote to Ilia Tarasov:
IT>> О чем говорит JC или JNZ?
RK> О наличии в АЛУ таких флагов :)
Где эти флаги в Си как элементы языка?
IT>> Покажи мне ту конструкцию Си, которая в явном виде устанавливает флаг IT>> нуля.
RK> a==b
Где установка флага нуля? CMP установит _все_ флаги, это side effect...
IT>> А чем плохо JA_EQ_B (переход, если AX = BX)?
RK> Это объединение 2х конструкций - операции вычитания (в АЛУ) и условного RK> перехода.
Которые делаются за несколько тактов, хотя с точки зрения требований языка операция атомарна.
IT>> Это разве не более короткая версия перехода, прекрасно ложащаяся IT>> на Си?
RK> Hа C - да, на процессор - хуже.
Обоснуй, почему хуже. С точки зрения схемотехники принципиальной разницы нет.
RK>>> Про ассемблер уже давно все забыли (кроме нескольких упертых RK>>> личностей и авторов компиляторов)
IT>> Даже в этой эхе найдутся те, кто еще не забыл.
RK> О! В этой эхе их навалом :) Мне кажется у них тут заповедник ;-)
Твои смайлики тебе выйдут боком ;) Знание ассемблера целевого процессора для грамотного инженера обязательно (а программист - это даже не высшее образование, это техникума хватит).
IT>> Программирование, в том числе и эхотажное - невообразимо широкое поле IT>> деятельности, и делать такие выводы вряд ли корректно.
RK> И тем не менее - есть очень отчетливая тенденция к переходу от ассемблера RK> к ЯВУ.
Тенденций есть много, и они разные. За всех говорить не стоит.
IT>> Все, что кому-нибудь нужно, рано или поздно может появиться.
RK> Оно уже появилось, теперь отмирает :)
Это твое мнение, или объективные исследования?
RK>>> Другие Форты? Это не производные, это просто другие версии. Есть RK>>> хоть один язык, построенный на основе Форта, но не Форт? IT>> Hе другие Форты, а другие языки. Lux, Onyx, еще что-то...
RK> Хм, если о Форте еще хоть что то известно, то об этих я лично даже не RK> слышал.
Joy подсказали - а я совсем забыл, и зря.... Орлов вон и про Ocaml ничего не слышал, но о чем это говорит?
IT>> Си, Паскаль, Алгол, Фортран - разные языки?
RK> Да. Программа на С не будет компилироваться Паскалем и т.д.
Они сопоставимы на уровне грамматики, а ты описываешь эффект от применения конкретных реализаций компиляторов. Это очень разные вещи.
RK> Фортран точно не для стековой - он даже рекурсии не поддерживал RK> изначально. RK> Другие имеют стек, хотя это не значит, что он должен быть аппаратный.
При чем здесь рекурсия? Любой язык, поддерживающий передачу параметров подпрограммам, использует для этого стек.
IT>> Иначе зачем там стековый кадр
RK> Для размещения активизаций процедур. Стек в этих языках нужен не сам по RK> себе, а как средство обеспечить возможность рекурсии.
???????? 8-|
Ты уверен? А не все ли равно, что именно вызывать? А если ты сгенерируешь вызов функции (другой) с десятком параметров, то параметры разве будут не на стеке?
RK> Это было сделано для языков типа Паскаля для организации display RK> регистров на стеке, сейчас эти команды практически не используются (по RK> крайней мере в том объеме, в котором они задумывались)
Это было сделано для целого класса языков, Си в первую очередь - с его конвенцией вызова накладные расходы на вызов больше, чем с Паскалевской.
RK> Можно дать более точное определение: RK> Языки можно считать диалектами друг друга, если найдется осмысленная RK> программа, не содержащая коментариев, которая будет компилится обоими RK> языками и давать в результате своей работы идентичные результаты.
:-/ Ничего себе определение. Применяем его к .net и видим, что ВСЕ эти языки (C++ C# VB и т.д.) - диалекты друг друга. Про фазы компиляции в определении ни слова.... (А .net использует единый промежуточный формат)
IT>> Hо если серьезно, то над всем зоопарком процедурных языков давно IT>> делают разные надстройки метауровня.
RK> Да, что однако не мешает применять эти языки и сами по себе.
Simulink - это хорошо или плохо? Ты сам говорил о тенденции перехода к все более высокому уровню.
IT>> Это ты утрируешь. Я же привел все примеры, как ты и просил. RK> Я ожидал чего нибудь из области откровений в постоении аппаратуры, а
За откровениями - в церковь... :)
RK> получил тривиальный ответ - умножаем частоту ... :(
Ты передергиваешь - я привел тебе _все_ варианты, в том числе и с умножением частоты. А триггер позволит записать в него по фронту, а затем асинхронно читать в любое количество выходов.
IT>> Hеверно. Форт не позволяет пересекаться конструкциям управления. Для IT>> этого существует control-flow стек (часто не отделяемый специально от IT>> стека данных). Во время компиляции каждая открывающая часть IT>> управляющей структуры будет класть на этот стек уникальный IT>> идентификатор типа структуры. Если он не будет снят, или закрывающее IT>> слово не увидит нужного ей идентификатора (например, пересеклись IT>> конструкции), это будет ошибкой.
RK> Hикто не мешает дописать своих управляющих слов с использованием того же RK> control-flow стека и непреднамеренно разрушить весь контроль в результате RK> ошибки.
Ээээ.... а что, кто-то говорил, что Форт - панацея? Надо думать, что делаешь. На Си тоже можно написать бесконечный цикл и войти в него с запрещенными прерываниями...
RK> Это можно описать такой грамматикой (фрагмент):
RK> слово := ':' { элемент } ';' RK> элемент := примитив | if-конструкция | ... RK> if-конструкция := элемент 'if' { элемент } [ 'else' { элемент } ] 'then'
RK> При таком подходе компилятор сможет досконально проверить всю грамматику RK> (как синтаксис так и семантику), но пользователь не сможет расширить RK> грамматику Форта своими словами.
Для такого подхода лучше взять язык с более простым синтаксисом.
RK>>> Hе очень. Синтаксис/семантика должны проверяться в целом, а не по RK>>> отдельным элементам. IT>> К этому есть существенные основания? RK> Есть - надежность.
Композицию уже отменили?
IT>> (to be continued)
RK> Ой, а может хватит?
А как хочешь...