Fri Oct 17 2003 09:08, Roman Khvatov wrote to Ilia Tarasov:
IT>> :))))) Можно подумать, я писал что-то другое и отталкивался от других IT>> соображений....
RK> Писал тоже самое, но выводы сделал другие
И это так уж страшно? :) Можно подумать, здесь мы занимаемся поиском истины в последней инстанции, и выводы должны быть одни-единственные. Чем плоха ситуация, когда выводы будут охватывать проблему с разных сторон? Ниже ты пишешь о "повышенном содержании разработчиков" - неужели всесторонний анализ будет вреден для них?
IT>> Чем так плоха постфиксная запись, минимизирующая неоднозначности в IT>> трактовке понятий входного языка?
RK> Hа ней неудобно писать, она слишком близка к уровню ассемблера, то есть RK> пользователю придется все оптимизации делать вручную.
а) грамотному пользователю может быть нужно именно это, просто как предоставленная возможность б) (по значимости вполне можно поставить перед п. а) некий компилятор ЯВУ может сгенерировать постфиксную запись в качестве промежуточного представления кода. для пользователя то же самое, а оперативная поддержка новых процессорных ядер существенно упрощается
RK>>> и чем дальше, тем этот разрыв больше и тем более сложные становятся RK>>> компиляторы. IT>> Hе обязательно.
RK> Что 'не обязательно'? Что компиляторы становятся сложнее при увеличении RK> разрыва, или что разрыв необязателен?
Необязателен разрыв. Объясни необходимость писать на ЯВУ человеку, экономящему байты в очень дешевом кристалле...
IT>> Я еще раз повторяю: "диаграмме состояний, заданной в ТЗ (!!!!)". И еще IT>> раз: ТЗ - это техническое задание. То есть документ (!),
RK> И что, там описан язык, на котором должен програмироваться данный RK> процессор, или архитектура процессора?
Нет, там описана задача :) Решение этой задачи, в виде конечного автомата, может представлять собой хоть набор реле, хоть гидравлическую логику (была и такая). То, что сейчас для реализации относительно несложных КА используют микроконтроллеры, объясняется попросту дешевизной и удобством такого подхода (ну еще габаритами, массой, надежностью и т.п.). Абсолютно никакого преимущества от того, что "атомарные" переходы в целевом КА выполняются за пару сотен тактов процессора, не наблюдается, да и процессор как таковой в ТЗ не фигурирует.
IT>> регламентирующий (!) поведение создаваемого устройства. Откуда взялся IT>> "средний" результат? Что, соответствие ТЗ 1 в 1 - средний результат???
RK> Сначала надо составлять грамотное ТЗ. ТЗ, описывающему средний процессор RK> будет соотвествовать средний процессор :)
Естественно :) Только вот никакой процессор в ТЗ может и не присутствовать, а присутствовать, например, система стабилизации с периодом квантования, ну скажем 1 мс (что соответствует 1 кГц). Этому ТЗ будет абсолютно адекватно соответствовать автомат управления с тактовой частотой 1 кГц, выполняющий операции строго по диаграмме переходов и соотношениям между управляющими сигналами. Что с того, что 1 кГц - слишком мало для современной микроэлектроники?
RK> Я вообще не понимаю, о чем мы спорим: если делается процессор общего RK> назначения, то все обстоит так, как я написал. Если делается какой то RK> спецвычислитель, то на каком языке он будет програмироваться и какая у RK> него система команд - дело десятое. Hа него никто не будет разрабатывать RK> полноценные компиляторы, и тогда тот самый 'средний' процессор будет RK> идеальным вариантом.
Именно о таких системах я и говорю... Так действительно, о чем мы спорим? :)
RK> Зато эха является местом с повышенным содержанием людей, которые RK> проффесионально занимаются эхотагом, и по ней вполне можно собирать RK> _статистику_ о использовании тех или иных средств разработки.
Статистические результаты полезны, когда объем выборки стремится к бесконечности. Т.е., когда я сделаю бесконечное количество эхотажных устройств, оптимальными результатами будут именно среднестатистические :) Среднестатистическим по эхе будет скорее всего PIC или AVR, но чем это мне поможет?
IT>> Ээ, ты абсолютно не прав. Если результаты востребованы (и заказчику IT>> все равно, на каких принципах это сделано),
RK> Если таковой заказчик 1 (прописью: один), то идея умрет вместе с RK> заказчиком, а организации, как и люди, не вечны.
Ну и что? Разработка проведена, оплачена и окупилась. Кого волнует дальнейшая судьба заказчика, по большому-то счету? Невозвращенных денег уже _нет_ после продажи некоторой партии изделий, о чем волноваться?
IT>> Вот AVreal Александра Редчука тому пример - свободная разработка, но IT>> без финансирования она же не померла?
RK> Я про финансирование ничего не говорил, это здесь абсолютно не при чем, я RK> говорил как раз о востребованности. Еще раз повторяю: если _все_ не RK> сообразили, как такой разработкой воспользоваться (читай - никому, кроме RK> непосредственного заказчика не нужна) - разработка пойдет в мусорную RK> корзину (возможно после смерти заказчика).
Ну значит такая судьба, что ж тут поделать? Это же не повод для того, чтобы отметать новые подходы, боясь, что они не сразу станут широко известными.
RK> Такая разработка может жить в железе, или где то еще, но она так и RK> останется в единственном экземпляре независимо от тиража этого RK> экземпляра.
Опять-таки, чем это плохо? Еще раз повторяю, финансовых потерь нет, есть даже прибыль, практические результаты совпадают с предположениями теории (и теория выиграла от такого подтверждения). Не принято "широкими массами"? Ну извините, квантовая механика тоже далеко не всем нужна в реальной жизни, многие установки ядерной физики существуют в единственных экземплярах, и "не поняты". Игнорировать иной теоретический подход, только потому, что он не распространился мгновенно?
RK>>> Если речь идет о _диалектах_, то грамматика одного диалекта RK>>> должна быть частью граматики другого (точнее они должны иметь RK>>> большую пересекающуюся часть, которая по объему должна быть RK>>> близка к объему одного из диалектов) IT>> "Большую" и "близка" - квантифицируй, плиз...
RK> 80-90% устроит?
Вполне :))) Итак, begin end паскаля заменили на { } Если считать по зарезервированным словам, заменено явно меньше 10% Чем будет являться такой язык?
IT>>>> Если угодно, программу на Паскале можно переписать на Си. RK>>> Можно, но тогда она перестанет быть программой на Паскале и RK>>> станет программой на С IT>> И где та грань?
RK> Как только переписали, так и перестала.
_сколько_ переписали? (см. выше)
RK> У нас похоже некоторые разночтения в том, что такое 'программа'. RK> Программа - это _конкретный_ текст. Если его начали преобразовывать или RK> прогонять через препроцессоры, то это уже _другая_ программа.
Текст - это текст, а программа - это программа.
RK>>> Можно, но это уже будет _другая_ программа.
IT>> Когда? После препроцессора?
RK> Да.
А после генерации промежуточного кода? Нет, тут что-то не то с определением...
RK> Тогда препроцессор входит в состав компилятора, и это уже компилятор RK> другого языка (того, с которого работает препроцессор)
Препроцессор - это одна из фаз компиляции...
IT>> А компиляторы часто преобразуют исходный язык во внутреннее IT>> представление - промежуточный код. Это тоже другая программа?
RK> Hет, это их внутреннее дело.
RK> Компилятор рассмаривается как 'черный ящик', на вход которому RK> _непосредственно_ подается программа (в виде простого текста, без всяких RK> препроцессоров)
Это ты так предлагаешь? Обычно-то не рассматривается... если только мы хотим разобраться с местом постфикса в этой каше...
IT>> ..... :) Так что же такое компилятор? Это .exe или принцип, или IT>> грамматика, или что?
RK> Грамматика.
О! :)
IT>> Hе прав. Лексические анализаторы и препроцессоры умеют генерировать IT>> осмысленный текст, который вполне может быть откорректирован вручную.
RK> Вот то, с чего они генерируют этот текст, и есть программа _для них_. Их RK> выход - есть программа для _другого_ компилятора.
И еще раз напоминаю, что компилятор - более широкое понятие, чем препроцессор. Препроцессор (или лексический анализатор) по имеющейся терминологии выступает как составная часть компилятора.
IT>> Hапример, у нас есть автогенераторы VHDL, написанные на тикле. Одна IT>> фаза разбора исходного текста уже прошла, а мы влезли руками и IT>> пустили дальше. Где компилятор-то?
RK> Здесь их 2, последовательно запущенных: первый 'автогенератор VHDL, RK> написанный на тикле', и второй - VHDL
Автогенератор - интерпретируемый, если уж придраться... После него мы еще и руками поправили. А можно было написать один .bat и ничего не править руками... Опять непонятки...
IT>> А почему ты так и не вчитался в мои сообщения? :))))) Я ведь и про это IT>> писал - про ассемблер стековой машины с командами, синтаксически IT>> совпадающими с базовыми словами Форта.
RK> Ок, тогда не надо называть это Фортом - это ассемблер, написанный на RK> Форте.
А я и не называю :))) Я говорю о Форте как о примере подобного подхода и рассматриваю следствие из него и технологии программирования, появляющиеся в связи с ним...
RK> Входной язык у него - ассемблер стековой машины, и на чем написан сам RK> ассемблер - совершенно не важно.
Fixed
RK> Если это остается в единственном экземпляре, так где 'выросло' - то ради RK> бога, а рекомендовать это как подход для всех не стоит.
:))))))))) А где я рекомендовал-то? Я как раз и _не_ рекомендовал всем бросаться в Форт. Но зачем про него специально умалчивать, тем более что есть как раз неплохой материал и неплохие результаты? Может быть, кому-то пригодится?