_Loader_

Tue Oct 14 2003 22:01, Roman Khvatov wrote to Ilia Tarasov:

IT>>>> О чем говорит JC или JNZ? RK>>> О наличии в АЛУ таких флагов :) IT>> Где эти флаги в Си как элементы языка?

RK> А где в С АЛУ как элемент языка?

О чем я тебе и говорил! Ни флагов, ни АЛУ, ни регистров! Однако при рассмотрении процесса компиляции все это вдруг всплывает...

RK> Ага, имеем 1 команду, которая может быть использована для выполнения RK> _любого_ условного перехода. (Точнее имеем комбинацию из 2х команд, RK> первая выполняет какое нибудь арифметическое действие, вторая выполняет RK> переход - результат первой команды тоже может понадобится)

Вот как раз _любой_ переход с минимальным набором команд и не нужен...

RK> Язык не обязан ложиться на целевую платформу 1 в 1 (и даже будет лучше, RK> если он не будет так ложиться - больше простора для маневра компилятору)

С чего бы??????!!!!!! Какой такой маневр компилятора, если все его "маневры" делаются не от хорошей жизни? Именно соответствие 1 в 1 команд процессора (а лучше КА) диаграмме состояний, заданной в ТЗ, и является идеальным с точки зрения алгоритмики решением поставленной задачи!

RK> Кроме того, если делать JA_EQ_B, то придется сделать целый выводок таких RK> команд для всех условий и всех регистров, сам посчитаешь, сколько их RK> будет :)

Ну наконец-то....

RK> Для стековой машины имеет смасл вводить операции JEQ/JNE/etc. - RK> там операнды находятся в одном месте и можно сэкономить на команде RK> сравнения.

Для стековой машины достаточно ввести операции над вершиной стека. Для Форт-машины - переход по проверке вершины на 0...

IT>> Обоснуй, почему хуже. С точки зрения схемотехники принципиальной IT>> разницы нет.

RK> Есть, если делать одной командой, то придется задействовать RK> _последовательно_ АЛУ и логику переходов, что потребует усложнения схемы RK> или введение микропрограм.

АЛУ в данном случае и есть логика переходов... Разницы нет (по наблюдениям за готовым проектом).

IT>>>> Все, что кому-нибудь нужно, рано или поздно может появиться. RK>>> Оно уже появилось, теперь отмирает :) IT>> Это твое мнение, или объективные исследования?

RK> Можешь собрать статистику например по этой эхе - здесь периодически RK> вспыхивают войны асм/C, причем со обычно воюют один или два человека RK> (сторонники асма) со всей остальной эхой :)

Статистика по эхе мне мало интересна. Я отсюда могу "забрать" только результаты обсуждений или технические советы от людей, тесно работавших с неким оборудованием. То, что xx% работают с Си, мало о чем говорит, даже если xx много больше 50...

IT>> Joy подсказали - а я совсем забыл, и зря.... Орлов вон и про Ocaml IT>> ничего не слышал, но о чем это говорит?

RK> О том, что они практически никому не известны, если не веришь - можешь RK> провести опрос, прямо здесь :)

Известны - не известны.... разве об этом речь? Разработка состоялась, кто не спряталс.... эээ... кто не сообразил как воспользоваться - я не виноват...

IT>>>> Си, Паскаль, Алгол, Фортран - разные языки? RK>>> Да. Программа на С не будет компилироваться Паскалем и т.д. IT>> Они сопоставимы на уровне грамматики,

RK> Это как это? То, что грамматики у них похожи, это еще не значит, что они RK> одинаковы.

Не придирайся. Они _сопоставимы_. Если угодно, программу на Паскале можно переписать на Си.

IT>> а ты описываешь эффект от применения конкретных реализаций IT>> компиляторов.

RK> Ээ, Паскаль и С это 2 реализации одного компилятора? Это откровение :)

а) "конкретных реализаций компиляторОВ" б) сильное подозрение, что дело обстоит таки довольно близко к тому, над чем ты тут улыбаешься.... ;)

(skipped то, что все равно не приведет к реальным результатам... ты компиляторы пишешь? тебе этот анализ нужен для конкретной работы, или просто "почему не стековая архитектура"?)

RK>>> Можно дать более точное определение: RK>>> Языки можно считать диалектами друг друга, если найдется RK>>> осмысленная программа, не содержащая коментариев, которая будет RK>>> компилится обоими языками и давать в результате своей работы RK>>> идентичные результаты.

IT>> :-/ Hичего себе определение.

RK> Вполне нормальное.

Для интереса - приведи парочку определений диалекта из соотв. литературы..

IT>> Применяем его к .net и видим, что ВСЕ эти языки (C++ C# VB и т.д.) - IT>> диалекты друг друга. IT>> Про фазы компиляции в определении ни слова....

RK> Причем тут фазы компиляции, я же явно написал _программа_, то есть RK> исходный текст.

И никаким препроцессором один исходный текст не превратить в другой? А то, что некоторые компиляторы умеют "смешивать" языки в исходных текстах? Неет... это ты не то написал...

IT>> (А .net использует единый промежуточный формат)

RK> А что, на всех этих языках пишут сразу на промежуточном формате? Или все RK> же на собственно языке?

"Собственно языка" там практически нет. Начиная с определенной _фазы_ (о которой вообще ни слова) компилятор работает с единым представлением кода. Соответственно, .net умеет компилировать все языки, которые способны после определенной обработки выдать это самое представление.

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

RK> Это тоже разновидность умножения частоты.

Ничего подобного! Не путай асихронные и синхронные схемы!

RK> Я ожидал красивого решения, RK> например разделение памяти на 2 банка и подключения АЛУ так, что бы можно RK> было читать операнды и записывать результат так, что бы к любому банку

:))))))) а) это наиболее оптимальное из используемых решений б) про это я уже писал... ты просто не увидел :))))

RK>>> Hикто не мешает дописать своих управляющих слов с использованием RK>>> того же control-flow стека и непреднамеренно разрушить весь RK>>> контроль в результате ошибки.

IT>> Ээээ.... а что, кто-то говорил, что Форт - панацея? Hадо думать, что IT>> делаешь.

RK> Бывают же и просто ошибки.

И кто в таким случае их сделал?

IT>> Hа Си тоже можно написать бесконечный цикл и войти в него с IT>> запрещенными прерываниями...

RK> Да, но поломать компилятор это не сможет :)

То, что поломает отвертку, не поломает молоток... Форт и Си - языки совершенно разных классов, и подобные сравнения вряд ли полезны...

IT>> Для такого подхода лучше взять язык с более простым синтаксисом.

RK> У Форта _очень_ простой синтаксис.

Соответственно, он может быть спрятан в качестве ассемблера с последующей надстройкой над ним серии ЯВУ... (Десятый раз тут уже повторяю)

IT>> Композицию уже отменили? RK> Она все равно снижает надежность.

???????? 8-| С чего?????

Tue Oct 14 2003 22:39, Roman Khvatov wrote to Ilia Tarasov:

RK> Я привел исходную формулу и то, что сделает из нее нормальный компилятор RK> С (в нотации Форта), Форт же сам это делать не станет.

Он ничего не станет делать сам по себе, но на такой вывод вполне натолкнет.

IT>> Плюх... Watcom C - DPMI, однако. Hе додумывай за меня - будут IT>> _фактические_ ошибки... ;)

RK> Я тебе привел оба варианта, совет по второму варианту был 'надо что то в RK> консерватории править', так как разница между оптимизирующим компилятором RK> С и ассемблером не может быть в 10 раз - так написали программу на С.

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

RK>>> Hикак. Могут взаимодействовать интерпретатор и _откомпилированная RK>>> программа_ IT>> Примером чего и является Форт-система... RK> И не только она, есть еще _дофига_ подобных систем, и не на Форте.

У тебя какой телевизор дома? ;)))))

RK> А зачем они вообще нужны. Я не понимаю исходной задачи - зачем RK> понадобилось скрещивать скрипты с программой в нулевом кольце?

В нулевом кольце все, поскольку какой смысл что-то оттуда специально выковыривать?

IT>> Входной поток - это либо клавиатура, либо файл. У тебя опять странная IT>> картинка. В файл можно записать программу работы установки хоть на IT>> целый день, она и будет потихоньку исполняться.

RK> Так же можно все это набить прямо в программу, откомпилировать, RK> запустить, и она так же будет выполняться хоть целый день, зачем там RK> интерпретатор?

ЗАЧЕМ???? Чтобы программеру было приятно, что он востребован? Проблемы надо решать максимально простыми средствами....

RK> Дельфи не для того сделан. RK> Кроме того, специально посмотрел - tcl (на cygwin'е) занимает около 1.8м, RK> мне кажется, что это побольше hello world на Дельфи.

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

RK> Я тоже. У этого принципиального подхода есть такой же принципиальный RK> недостаток - если ты в своем проекте применил интерпретатор, то ты (или RK> твой пользователь) должен этот интерпретатор иметь, что бы запустить твою RK> программу. Тут есть 2 пути: 1) Интерпретатор встроен в саму программу RK> (Форт или какой нибудь прилинкованный к программе интерпретатор) 2) RK> Интерпретатор в программу не встроен, тогда он или должен быть приложен к RK> программе, или пользователю придется самому озаботится его поисками, что RK> никак не способствует удобству работы с программой.

Есть коробочные продукты и внутренние решения разработчика. Мы о чем? Здесь явно актуальнее второе - как с помощью такой массовой вещи, как PC, максимально облегчить себе жизнь. Тикль поставить - плевое дело. Настроить интерпретатор Форта на генерацию ассемблерного кода для контроллера, который в данный момент лежит на столе - тоже довольно просто.

IT>> (которые, btw, должны быть удобно стыкуемыми), я говорю, что они IT>> прекрасно заменяются одной.

RK> Которая так же хорошо выполняет все 3 задачи, как 3 специализированные RK> системы каждая свою? Что то не верится.

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

IT>> Для полностью компилируемых программ эта система не является частью IT>> языка. Соответственно, она автоматически попадает в разряд "прикладных IT>> программ". Что там наворочено - еще надо разобраться...

RK> А если она 'автоматически попала' в систему, с ней уже не надо RK> разбираться, и она стала абсолютно безглючной?

Алгоритм, отработанный на десятках Фортов, явно стабильнее только что состряпанной программы.

RK> Мы пока обсуждаем эти самые _иные_ подходы не имея представления к _чему_ RK> же они были применены.

Это долго, и здесь я пытался дать общее представление о том, что с Фортом _можно_ работать... и _как_ с ним работать...

RK> PS. А вообще то наша беседа уже свалилась в полнейший офтопик, пора RK> закругляться.

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

Mon Oct 13 2003 11:42, Lev Serebryakov wrote to Ilia Tarasov:

IT>> Разве есть принципиальная разница, в каком конкретно языке или ОС IT>> будет использована подобная методология? gcc, кстати, это компилятор IT>> для _одного_ языка из целой серии. Как быть с Паскалем или Фортраном?

LS> Открой для себя g77 и gpc. Чес-слово, они так же собираются кроссово, LS> как и C-Часть gcс. LS> И, предвосхищая вопросы, есть еще Objective C, ADA и Java с компилением LS> в нативный код.

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

Wed Oct 15 2003 14:15, Arcady Schekochikhin wrote to Ilia Tarasov:

AS> HЕТ, HЕТ и HЕТ. Для передачи параметров программам стек HЕ HУЖЕH. Вообще. AS> Даже для хранения адресов возврата стек HЕ HУЖЕH - смотри IBM 360. И AS> даже, AS> о боже - для рекурсии стек не нужен - нужны активационные фреймы и AS> поддержка механизма LIFO, что совсем не обязательно аппаратный стек (но AS> таки да - любой LIFO можно так же назвать и стеком).

Тогда давай так: одна из реализаций механизма передачи параметров - использование стека. Что он не является необходимым условием - это я и так знаю. Активационные фреймы - несколько абстрактное описание...похожее на утверждение "вы находитесь в корзине воздушного шара"... _где_ их держать?

AS> Весьма неграмотное утверждение.

Вполне справедливое для платформы x86 и упоминающееся в целом ряде источников.

AS> Сишная конвенция по определению проще и AS> дешевле - она не поддерживает вложенных процедур (то есть не нужны AS> дисплеи для доступа к переменным объемлющих процедур) и стек чистит AS> вызывающий - не нужна специальная команда "RET n" (без которой для AS> паскалевского возврата нужно извращаться, если у тебя стек аргументов AS> совпадает со стеком вызовов).

Ну и как вызывающий будет чистить стек после пары сотен вызовов функций в программе малой или средней сложности? Посчитай-ка количество серий PUSH/POP...

А если ты про проблему передачи параметров "в общем", то просмотри тред внимательнее... А то ты выхватил кусок, и теперь с ним споришь. Я про x86-подобные архитектуры, с одним стеком и регистрами. Другие архитектуры - другие решения!....

Hi Roman,

Sun Oct 12 2003 21:45, Roman Khvatov wrote to Ilia Tarasov:

RK> Есть хоть один язык, построенный на основе Форта, но не Форт?

Вот еще один, называется Atlast ftp://ftp.fourmilab.ch/pub/kelvin/atlast/ Сделан основателем Autodesk, и вроде бы даже используется где-то в недрах Автокада. Приложенный к Atlast "рид ми" файл звучит как манифест, под многими положениями которого я готов подписаться. Приведу некоторые выдержки:

ATLAST is an attempt to make software component technology and open architecture applications commonplace in the mainstream software market. It is both a software component which can be readily integrated into existing applications, providing them a ready-made macro language and facilities for user extension and customisation and, at the same time, it is a foundation upon which new applications can be built in an open, component-oriented manner

ATLAST was developed at Autodesk, Inc. Autodesk returned the rights to me in 1991, and I subsequently placed the program in the public domain.

ATLAST is based upon the FORTH-83 language, but has been extended in many ways and modified to better serve its mission as an embedded toolkit for open, programmable applications. ATLAST is implemented in a single file, written in portable C.

Most programs start out as nonprogrammable, closed applications, then painfully claw their way to programmability through the introduction of a limited script or macro facility, succeeded by an increasingly comprehensive interpretive macro language which grows like topsy and without a coherent design as user demands upon it grow. Finally, perhaps, the program is outfitted with bindings to existing languages such as C.

Everything should be programmable. EVERYTHING! I have come to the conclusion that to write almost any program in a closed manner is a mistake that invites the expenditure of uncounted hours "enhancing" it over its life cycle. Further tweaks, "features," and "fixes" often result in a product so massive and incomprehensible that it becomes unlearnable, unmaintainable, and eventually unusable.

Far better to invest the effort up front to create a product flexible enough to be adapted at will, by its users, to their immediate needs. If the product is programmable in a portable, open form, user extensions can be exchanged, compared, reviewed by the product developer, and eventually incorporated into the mainstream of the product.

Пока, Алексей