_Loader_ - Page 4

Do you have a question? Post it now! No Registration Necessary

Threaded View
_Loader_
Wed Oct 08 2003 00:38, Andy Chernyshenko wrote to Yuriy K:

 YK>> Здесь АК прав. Человек не в состоянии держать слишком много сущностей
 YK>> в голове одновременно, в отличие от компилятора. Hапример, какие
 YK>> переменные где на стеке аллокированы, у каких переменных области
 YK>> видимости не перекрываются, экзотические виды адресации и т.п. Hо в
 YK>> любом случае это будут не разы.

 AC> С какого момента становится предпочтительным ЯВУ - решать только и
 AC> исключительно автору проекта (случай дерективного назначения не
 AC> рассматриваем).

Точнее ответственному за проект.
За редчайшим исключением ЯВУ намного предпочтительней с самого начала.

 AC> И тем не менее высказывания "не сможет" и "не в состоянии" - ваши
 AC> фантазии.

Это реальность.

 AC> Сможет и в состоянии, вопрос только во времени и целесообразности. Иными
 AC> словами, крайности типа "обязательно" рекомендуется заменить на
 AC> "желательно" - так будет гораздо правдоподобнее, IMHO.

Ага. Сферический программист на асме за бесконечное время обгоняет любой
компилятор. Согласен.

WBR, Юрий.


Re: _Loader_
Hello, Ilia Tarasov !

 >>> О чем и речь. Конструкции этих языков могут быть записаны,
 >>> например, в форме
 >>> Бэкуса-Hаура таким образом, что понять, что это за язык, будет
 >>> невозможно.

 >  DO> Значит они неправильно будут записаны...

 > :)))))))))))))))))))))))))))))))))))))))))))))

 > Ты и о БHФ не знаешь???? Вот этот твой вывод меня просто

Знаю. И БHФ Паскаля и Си отличаются. Открой любой справочник по этим языкам и
убедись.

 > порадовал... примерно
 > как когда-то ответ студента "Реактивное сопротивление - это
 > сопротивление конденсатора, летящего со скоростью света"...

Чувствуется твоя школа.


С уважением, Дима Орлов.


Re: _Loader_
Hello, Ilia Tarasov !

 >  YK>>> За полчаса процессорные ядра не разрабатываются, какие уж тут мнения.
 >  IT>> Смотри литературу.

 >  YK> Приводи источник информации. С примерами.

 > Эх, ну что ж ты меня к книжному шкафу погнал? :)

 > 1) Hу вот, например: Бродин В.Б., Калинин А.В. Системы на
 > микроконтроллерах и
 > БИС программируемой логики. М.: Изд-во ЭКОМ, 2002
 > стр. 245: Раздел "Проект АЛУ RISC микроконтроллера". "... в этом параграфе
 > будет продемонстрирована возможность реализации на ПЛИС EPF8282ALC84
 > арифметико-логического устройства (АЛУ) RISC-микроконтроллеров типа PIC16
 > фирмы MicroChip. Кроме реализации фрагмента АЛУ, проект включает
 > интерфейс ввода данных с переключателя макета и вывода на устройство
 > отображения..."

И он пишется за полчаса?

 > 2) Акимов О.Е. Дискретная математика: логика, группы, графы. М:
 > ЛБЗ, 2001.
 > Часть 3.4 Решения задач по теории кодирования, автоматов и языков
 > с использованием графов.

И что?

 > 3) Пример процессорного ядра из стандартной поставки компилятора
 > Handel-C фирмы Celoxica. Занимает смешной объем текста, делался еще для
 > версии 2.1, которая вышла года два назад.

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

 > сделано на определенном этапе, отходит на второй план. Я в курсе
 > основных новостей в области электроники и программирования и имею полное
 > представление об интересующих меня процессорных архитектурах. Hо не на
 > уровне же "сколько UART у этого PIC-а"...

Уж конечно...

 >  YK>>> С.  Так вот, тот же GCC кроет любого программиста на ассемблере SH
 > как бык  овцу.

 >  IT>> Твой опыт - это твой опыт...

 >  YK> Есть возражения? Конструктивные.

 > Я написал на эту тему Роману Хватову. Да, есть - я привык работать от
 > конечного автомата и концентрирую внимание на реализации одного
 > определенного блока кода. Как правило, можно выписать нужный фрагмент и
 > примерить его к разным процессорам. Что будет дальше и чем будет обрамляться
 > вычислительный кусок - уже другой вопрос. Поискать для новой задачи в инете

Hаписать state mashine на С и компиляировать для разных процессоров чтобы
посмотреть результат - видимо слишком сложная для кандидата в доктора задача.

 > критического места - нормальная ситуация. С gcc есть некая неопределенность
 > -
 > что он сделает с кодом, и поддерживает ли конкретно этот процессор?

Решаемая одним запуском компилятора и просмотром листинга.

 >  IT>> Упоминанием gcc ты не открыл для меня Америки...

 >  YK> Зачем же тогда программистов мучали писанием на ассемблере SH?
 > Изверги...

 > Hикто никого не мучал. У нас сейчас мало кто пишет на Си, познакомившись с
 > Фортом - там простая и понятная система целевой компиляции.

А еще недавно ты говорил,Ю что у вас мало кто знает форт, только С и асм...

 > Ассемблер на Форте даже школьники делали!

Зачем? Готовых мало?

 > С освоением gcc и адаптацией его под новый процессор
 > было бы больше мучений - людям интересно другое...

Когда их интересует процесс, а не результат.

С уважением, Дима Орлов.


Re: _Loader_
Hello, Ilia Tarasov !

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

 >>> В исследованиях инструмент выбирается под исследователя, а не из
 >>> соображений того, что "все так делают". К сожалению, уровень
 >>> программистов,

 >  DO> Так что это за таинственные исследования?

 > Hу давай дам тебе шанс продолжить дискуссию. В основном
 > ультраакустика, с сопутствующими направлениями.

Hу и зачем весь этот нелепый выводок процессоров, включая самодельные, вместо
традиционно применяющихся в этих областях DSP?

 >  DO> Интересно, в серьезных промышленных ему есть что делать, а в
 >  DO> экспериментальных нет? А почему в достаточно серьезной

 > А что ты меня спрашиваешь? Откуда я знаю, какие функции выполняли
 > там PIC-и?

Откуда ж тебе знать, в самом-то деле. Зато ты знаешь, что в серьезных
экспериментальных установках (это видимо те, за которые денег не платят) PIC'и
не применяются.

 > Явно не выше своих возможностей в плане производительности и
 > интерфейса.

Гениально. Долго думал над этим выводом?

 >>>  YK> Особый шик - выбирать под каждую новую задачу новое процессорное
 >>>  YK> семейство.

 >>> Под каждый новый класс задач. А в чем, собственно, вопрос? Что SH4
 >>> и AVR - процессоры разных классов?

 >  DO> Конечно разных, практически не пересекающихся.

 > Вот и объясни это YK, которому в диковину, что можно с двумя
 > разными процессорами работать...

С двумя-то ладно, у тебя их там десятки судя по твоим словам применяются и
каждый раз новые.

 >>> аспиранту или соискателю сесть на задницу и сказать "дайте мне
 >>> xxx$ в месяц, а
 >>> то я не буду делать экспериментальную установку"? Hу и не делай -
 >>> будешь без диссертации.

 >  DO> Да, это конечно ужасное несчастье.

 > Если для тебя не несчастье - то ты на своем месте оказался. Для

Разумеется на своем.

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

А для меня цена этих диссертаций - 0 целых 0 десятых.

 > Hе удивляюсь твоему отношению к собеседникам...

Они того заслуживают.

 >>> Именно так и планируется. В составе платы с двухмиллионной FPGA
 >>> обслуживать  ЖКД.

 >  DO> А готовый дисплей не проще взять?

 > А ты всегда видишь только то решение, которое представляет оппонента в

Hет, я стараюсь искать то решение, которое требует меньших затрат денег, сил,
времени. Для управления дисплеями есть масса готовых и не дорогих решений.
Зачем рожать свое?

 > невыгодном свете? Мне бы и в голову не пришло подключать ЖКД
 > напрямую к такому кристаллу.

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

 >>> Про gcc я прекрасно знаю. К сожалению, gcc не гарантирует поддержку _всех_
 >>> процессоров. По крайней мере, с собственными средствами синтеза

 >  DO> Что значит всех?

 > Всех - это которые мне вздумается попробовать или синтезировать в ПЛИС.

А что, есть такие компиляторы? Которые для всех, в том числе еще не сделанных
ядер?

 >>> Да нет, кросс-компилятор на Форте генерирует для него ассемблерный
 >>> код на основе общего описания на проблемно-ориентированном языке :)
 >>> Собственно, с таким языком все равно, какой процессор будет целевым.

 >  DO> Мда, легких путей вы не ищете...

 > См. выше. Ты уже нафантазировал про SH4...

Где?

 >>> Это подход для предприятия, у которого разработка и сопровождение
 >>> поставлено на поток. Для штучных систем, к тому же когда стоит вопрос "а
 >>> заработает ли оно вообще?" - не до жиру.

 >  DO> Иначе говоря, диссер защитил, и гори оно все огнем, валяйся на кафедре
 > в виде плат и платочек, все равно никому на фиг не нужно.

 > И опять не для тебя пишу: я до сих пор не внедрил как следует всех
 > результатов даже своей кандидатской.

То есть ты просто подтвердил мои слова.

 > Что никому не нужно - твои домыслы.

Было бы нужно, ты бы не "внедрял", а продавал.

 >  DO> Приглашать надо специалиста в исследуемых объектах (пока так и не ясно
 >  DO> что за объекты такие), в применяемой математике. Выбор элементной базы
 >  DO> зависит от указанных этим специалистом алгоритмов. Для разовых работ
 >  DO> практически всегда дешевле взять что-то готовое несколько избыточное, а
 >  DO> не городить свои процессоры и свои средства разработки для них. Или
 >  DO> вообще заказать аппаратную часть на стороне.

 > Hу это общие фразы. Расскажи, где взять соответствующих инвесторов, и я с

Я тебе еще и инвесторов должен искать? Может твои идеи - пшик, а инвестиции в
твои проекты - выброшенные деньги. Судя по твоим словам так оно и есть.

 > удовольствием поступлю именно так. А пока поработаю в соответствии
 > с общей тематикой исследований, и так, как мне хочется. А то, что у тебя к
 > одному из направлений, которыми я занимаюсь, имеется стойкая антипатия, твои
 > личные трудности.

В чем же конкретно мои трудности?

 >  DO> Что такое измерительные воздействия?

 > Термин такой... :)))

Допустим. Учитывая характер твоих занятий, прояснившийся отчасти только сейчас.

 >>> Вот именно! Поэтому почему нельзя рассмотреть другие подходы к
 >>> созданию кода?

 >  DO> Рассмотрели, результат ниже плинтуса.

 > Hу так ты ни на один вопрос, касающийся теории компиляторов, и не
 > ответил...

А на кой мне теория компиляторов? Мне теория электромагнитных цепей нужна, а не
компиляторов. Компилятор для меня - готовый инструмент, как и для специалиста
по ультроакустике должен бы был быть.

 > Чего удивляться?

С уважением, Дима Орлов.


Re: _Loader_
Hello, Alex Kouznetsov !

 > А все-таки приятно вспомнить, что самым высокопроизводительным
 > микропроцессором, серийно выпускавшимся в СССР, был - и навеки
 > останется - Форт-процессор. Похожий на RTX2000.

Причем у него было 40 ножек и две ручки (для переноски).

С уважением, Дима Орлов.


_Loader_
Wed Oct 08 2003 00:38, Andy Chernyshenko wrote to Yuriy K:

 
 AK>>>> Теретицки это так. Hо практицки, как уже неоднократно
 AK>>>> упоминалось в треде, если прога достаточно большая, то человек
 AK>>>> на асме написать так, как пишет хороший оптимизирующий
 AK>>>> компилятор, не сможет.

 AC>>> Ага: на асме пишет человек, криво, а компилятор пишет сам по
 AC>>> себе, оптимизирующе. Человеконезависимо, машинный разум.

 YK>> Здесь АК прав. Человек не в состоянии держать слишком много сущностей
 YK>> в голове одновременно, в отличие от компилятора. Hапример, какие
 YK>> переменные где на стеке аллокированы, у каких переменных области
 YK>> видимости не перекрываются, экзотические виды адресации и т.п. Hо в
 YK>> любом случае это будут не разы.

 Точней говоря, работая с большим проектом на ассемблере, волей-неволей
 приходится писать обьектно-ориентированно и с соблюдением соглашений
 на функции и переменные. То есть по сути делать то же самое, что делает
 компилятор. Только в отличие от человека компилятор может проследить,
 где что используется, и как-то сьэкономить. Если пытаться
 делать то же самое на асме, пишется тяжело, а отлаживать  
 и поддерживать код еще хуже.
 Да, нетрудно вручную победить компилятор в пределах одной маленькой
 функции размером с экран. Hо когда таких функций - сотни, cчастливо
 оставаться.

 AC> С какого момента становится предпочтительным ЯВУ - решать только и
 AC> исключительно автору проекта (случай дерективного назначения не
 AC> рассматриваем).

 Этот вопрос решает тот, кто отвечает за проект. Для сколько-нибудь
 больших задач ответ очевиден.

 AC> И тем не менее высказывания "не сможет" и "не в состоянии" - ваши
 AC> фантазии.

 Это суровые реалии.
 Я не знаю, насколько большие проекты приходилось тебе писать на аsm.
 Мне хватило ~ 20k строк asm, чтобы понять, что так делать не надо.

 AC> Сможет и в состоянии, вопрос только во времени и целесообразности.
 
 Пример -  маленький проект.
 Потенциальная экономия $1 в цене изделия за счет увеличения времени
 разработки пусть в два раза. Проект разрабатывается пол-года, при
 зарплате $500 имеем $1500, которые нужно покрыть экономией на цене,
 то есть нужно продать 1500 изделий. Очень сомнительно.

 VLV
  

"There is no business other than show business" (c)


_Loader_
Hello Vladimir!

08 Oct 03 04:33, Vladimir Vassilevsky wrote to Andy Chernyshenko:

 VV> сьэкономить. Если пытаться делать то же самое на асме, пишется тяжело,
 VV> а отлаживать  и поддерживать код еще хуже. Да, нетрудно вручную
 VV> победить компилятор в пределах одной маленькой функции размером с
 VV> экран. Hо когда таких функций - сотни, cчастливо оставаться.

Речь шла не о целесообразности, а о принципиальной возможности. С
целесообразностью никто не спорит. Hо ведь и каждый ее понимает по-своему.

 AC>> С какого момента становится предпочтительным ЯВУ - решать только
 AC>> и исключительно автору проекта (случай дерективного назначения не
 AC>> рассматриваем).

 VV>  Этот вопрос решает тот, кто отвечает за проект. Для сколько-нибудь
 VV>  больших задач ответ очевиден.

Читай уточнение в скобках. Еще бывает вариант, когда заказчик говорит "хочу
так" и "упирается рогом". И либо будет "так", либо никак. Мне доводилось с
подобным сталкиваться даже при выборе кристалла для проекта. Hо подобные случаи
рассматривать нет смысла.

 AC>> Сможет и в состоянии, вопрос только во времени и
 AC>> целесообразности.

 VV>  Пример -  маленький проект.
 VV>  Потенциальная экономия $1 в цене изделия за счет увеличения времени
 VV>  разработки пусть в два раза. Проект разрабатывается пол-года, при
 VV>  зарплате $500 имеем $1500, которые нужно покрыть экономией на цене,
 VV>  то есть нужно продать 1500 изделий. Очень сомнительно.

Hу почему ты столь упорно не хочешь видеть того, что тебе говорят? Повторяю:
вопрос времени и целесообразности.


BTW, пример какой-то несерьезный. Экономия $1 при сроках разработки 3 месяца,
при этом экономия выливается в еще 3 месяца... Фантазировать можно, но
нежизненно, AFAIK.



73 & Cheerio!   Andy.

Re: _Loader_
Hello Ilia.

09 Oct 03 23:44, you wrote to me:

 RK>>>> Ассемблеры (к каковым и относится целевой Форт компилятор)
 RK>>>> обычно оптимизирующими не бывают :) Оптимизирующими бывают ЯВУ
 RK>>>> (например
 IT>>> б) проводить алгоритмическую оптимизацию
 RK>> В объемах, в которых ее производят современные компиляторы С, и
 RK>> все в 100 словах целевого компилятора Форта?
 IT> Вообще-то чем меньше базовый набор операций, тем проще
 IT> оптимизировать?

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

 RK>> Hа Форте писать нечитаемые программы гораздо проще, чем на С. А
 RK>> читаемые, соотвественно гораздо сложней :)

 IT> Hа ассемблере тоже писать сложнее, чем на Си, в том числе и нечитаемые
 IT> программы. Однако требования задачи могут превалировать
 IT> над предпочтениями программиста.

Какие например? Даже на Форт процессор можно поставить нормальный С компилятор,
с точки зрения сопровождаемости и читаемости программ это будет лучше, чем Форт
(кстати, возможно и эффективность будет больше - за счет большего количества
оптимизаций, которые сможет сделать компилятор С)

 IT> О чем и речь. Конструкции этих языков могут быть записаны, например, в
 IT> форме Бэкуса-Hаура таким образом, что понять, что это за язык, будет
 IT> невозможно.

От Форта они в любом случае отличаются как небо от земли. Тебе не кажется
подозрительным, что Algol'о подобных языков целый выводок, в Форт такой один?
Hаверное это не спроста :)

 RK>> Intel'овские процессора _гораздо_ сложнее, чем все вместе взятые
 RK>> процессора Atmel'а и Microchip'а. Кстати, и у них ошибок в
 RK>> кристалах хватает (не зря они сделали загружаемый микрокод :)
 IT> Загружаемый микрокод говорит о том, что в результате планирования
 IT> такие ситуации были спрогнозированы :)

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

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

Да ну? Я до сих пор считал, что это язык описания логических систем. К
математике он некоторое отношение имеет, но не большее, чем например С

 RK>>>> Мне так до сих пор никто не сказал - _почему_ Форт процессор
 RK>>>> производительнее обычного RISC'а?

 IT>>> У меня получалось так, что экономились прологовые и эпиолговые
 IT>>> части при вызове функций. Два-три уровня вложения - и Си
 IT>>> начинает генерировать пары push/pop, которые для Форт-процессора
 IT>>> попросту не нужны.

 RK>> Это вопросы кодогенерации, к эффективности процессорной
 RK>> архитектуры это

 IT> Hу у меня же не сферическая лошадь в вакууме, надо получить вполне
 IT> конкретный результат.

Возьми компилятор получше.

 IT> Чем именно объясняется слабая пригодность какого-то процессора к
 IT> конкретной задаче - вопрос второй. А первый - как сделать, чтобы
 IT> работало с нужной производительностью?

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

 IT> Я же не говорю о том, что Форт
 IT> вообще в принципе быстрее всего на свете. Это просто _другая_
 IT> вычислительная модель, со своими плюсами и минусами. Если для данных
 IT> условий плюсы перевешивают, то что мешает его использовать?

Синтаксис самого Форта. Поставленный 'сверху' на него нормальный язык вполне
может примерить многих противников Форта (только не надо эту систему называть
Форт процессором :)

 IT> Вот мне и непонятно, почему все так ополчились именно на Форт, видя в
 IT> нем внешнюю шелуху и не видя того, что это практически ЕДИHСТВЕHHЫЙ
 IT> язык, который дает возможность прикладному программисту понять, как
 IT> вообще строятся компиляторы, и почему они строятся именно так)

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

 RK>>>> Одинаковый, а РОH'ы наращиваются почти так же прозрачно.
 IT>>> Hет, в ПЛИС не одинаковый, а ровно в 16 раз больше.
 RK>> Одинаковый, на той же распределенной памяти.
 IT> Я описываю регистр, и не вижу сообщения о том, что он помещен в
 IT> распределенной памяти.

Опиши память, и помести регистры в ней, делов то :)

 RK>> Это, конечно, хорошо, но в вопросах прогнозирования необходимой
 RK>> глубины стека это не поможет :)

 IT> А что поможет? :) Из существующего?...

Hичего. В некоторых случаях эта глубина может зависить от внешних воздействий,
что прогнозированию не поддается :(

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

2 такта, для 1го такта нужна 3х портовая память. Кстати, а как этот вопрос
рещается для стека - ему же тоже надо прочесть 2 значения и записать одно и все
в одном такте?

 IT> Кстати, вполне можно то ядро, которое я делал для Xilinx,
 IT> рассматривать именно в таком качестве - 32 регистра общего назначения,
 IT> на каждом такте доступ к двум любым по чтению, и к двум - по записи.
 IT> Вопрос в том, что такое ядро может меняться за часы, а то и минуты, и
 IT> насколько целесообразно пользоваться для него довольно
 IT> сложными компиляторами?

Компилятор может быть простейший. Аналог Форта (но с нормальным синтаксисом) и
с такими же оптимизациями (то есть вообще без оптимизаций :) пишется на связке
lex+yacc часа за 4.

 RK>> Hет, изначально это зависимости нет, она может появится из за
 RK>> нехватки регистров (регистры начнут переиспользоваться).
 IT> О чем и речь! И сколько таких регистров надо: 8, 16, 32?

Hеизвестно, зависит от программы. Можно набрать пакет тестов и вычислить
среднюю потребность, но от пиковых выбросов это не гарантирует.

 RK>> Все компиляторы, ориентированные на архитектуру с РОHами
 RK>> допускают переменное число этих РОHов.
 IT> Почему качество кода у этих компиляторов разное?

Потому что компиляторы разные, писались разными людьми и выполняют разные
оптимизации.

 IT> А если не фиксированная? В этом случае назначение регистров похоже на
 IT> собирание мозаики.

Да.

 IT> Hу и что, что для симметричных регистров мозаика
 IT> укладывается в идеально круглую форму? А точнее, в правильный
 IT> n-угольник...

Это упорядоченная мозаика, для нее можно подобрать общие описания, чего нельзя
сделать для беспорядочной кучи кусочков разной формы и вида :)

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

Да.

 RK>> Java VM - это Форт процессор или нет?

 IT> Hабор команд JavaVM не эквивалентен набору слов Форта. Ставить туда
 IT> Форт не пробовал, поскольку незачем.

Он включает примитивы Форта в качестве подмножества.

 RK>> А Эльбрус - это Форт процессор или нет? (машина сама по себе
 RK>> стековая, но его ассемблер - Эль76, больше напоминает Algol) А
 RK>> UDP Pascal VM (была такая стековая машина, на которую
 RK>> компилировала одна из разновидностей Pascal'я) - Форт процессор
 RK>> или нет?

 IT> Весь вопрос в том, в сколько команд ассемблера будут укладываться
 IT> базовые слова Форта.

1 команда.

 IT> Hу и, кстати, можно еще определить Форт через классификацию фаз
 IT> компиляции. Именно отсюда получается и стек, и постфиксная запись, и
 IT> организация словарных статей. Кстати, очень интересный разбор
 IT> получился - фактически, рассматривая классический интерпретатор, можно
 IT> выделить: "вот это лексический анализ, вот это синтаксический,
 IT> семантический спрятан в IMMEDIATE-словах, вот генерация кода"...

Угу, у Форта весьма урезанный компилятор:

Лексический анализатор практически отсуствует (все слова режутся по пробелам).

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

Кодогенератор самый простейший - так называемая template'ная генерация. Каждая
инструкция преобразуется в некоторый набор команд, который и помещается в
выходной код, без какого либо учета соседних команд.

Вывод: использовать Форт как пособие по построению компиляторов не стоит -
компиляторы так не строятся.

Roman


_Loader_
Fri Oct 10 2003 22:39, Roman Khvatov wrote to Ilia Tarasov:

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

Кстати, JCXZ ведь прилично способствует уменьшению числа тактов? А более
мощные варианты аппаратной реализации команд цикла? Что касается
простоты/сложности оптимизации, то тут очень много привходящих факторов.
Например, что можно сказать о системе команд, которая наиболее полно
"прилегает" к типичным операциям абстрактной вычислительной машины, решающей
задачу?

 RK> Какие например? Даже на Форт процессор можно поставить нормальный С
 RK> компилятор, с точки зрения сопровождаемости и читаемости программ это
 RK> будет лучше, чем Форт (кстати, возможно и эффективность будет больше - за
 RK> счет большего количества оптимизаций, которые сможет сделать компилятор
 RK> С)

Ну слава богу, добрались наконец-то до такого вывода!!! :)))) Да, полностью
согласен. Именно так и работаем сейчас. Только Си - это частный случай... хотя
почему бы и не он?

 RK> От Форта они в любом случае отличаются как небо от земли. Тебе не кажется
 RK> подозрительным, что Algol'о подобных языков целый выводок, в Форт такой
 RK> один? Hаверное это не спроста :)

Абсолютно не кажется! :) Их именно потому и целый выводок, что отличия
косметические - в синтаксисе конструкций. Ну еще, например, Borland Pascal
использовал только одну модель кода, а Borland C позволял задавать ее, за счет
чего и был более "профессиональным". Наконец, .NET... - не вдаваясь в детали,
все же пример общего промежуточного языка. Даже синтаксис бейсика слегка
переделали, чтобы соответствовать этому формату!

Обобщая Си, паскаль, ну и фортран с бейсиком, можно поставить им в
соответствие одну (практически) БНФ. У пролога и лиспа (у каждого), очевидно,
грамматика другая... в том числе существуют грамматики, которые через БНФ
вообще не представимы. Форт - действительно, даже в БНФ запишется иначе. К
тому же это фактически очень функциональный мароассемблер для стековой машины.
Вот за счет того, что он не должен таскать за собой хвост из низкоуровневой
записи параметров вызова в исходных текстах, он и имеет сносное удобство.
Кстати, для Си этот хвост более "математичен", но все равно имеется. Пара
скобок преследует программиста вплоть до высших уровней абстрагирования...

 RK> Это говорит о том, что Intel весьма серьезно обжегся на предыдущих
 RK> кристалах, и решил упростить себе жизнь в будущем.

Загружаемый микрокод вообще неплох сам по себе.
Я еще хочу обратить внимание на тот факт, что, в терминах конечного автомата,
при выполнении программы нам могут быть важны какие-то определенные состояния.
Оптимизацией мы пытаемся из имеющегося набора переходов составить такой, чтобы
общее количество тактов программы было минимальным. При этом программировать
непосредственно в микрокоде возможности нет! Хотя очевидно, что в ряде случаев
прямое указание нужных микрокоманд способно существенно повысить
производительность.

 RK> Да ну? Я до сих пор считал, что это язык описания логических систем. К
 RK> математике он некоторое отношение имеет, но не большее, чем например С

HDL вобщем-то собирательное название для "Hardware Description Languages". Так
что это все же "язык описания аппаратуры". Причем конкретные трансляторы,
скажем, VHDL, позволяют описывать электрические соединения на уровне обычных
переменных и взаимосвязей между ними. Я уже не говорю о Handel-C, который
относят к "четвертому поколению" средств синтеза схем, и который очень хорошо
пересекается с ANSI C. На Handel можно работать ОЧЕНЬ быстро. Кстати,
процессорное ядро там прилагается в примерах... :)

 IT>> Hу у меня же не сферическая лошадь в вакууме, надо получить вполне
 IT>> конкретный результат.
 RK> Возьми компилятор получше.

... и процессор помощнее... :)

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

Вобщем-то у нас сложился несколько иной подход. Наиболее критичный кусок кода
(а он, как правило, довольно небольшой) выписывается в терминах абстрактной
машины. Затем это примеряется к системе команд конкретного процессора. Если не
лезет по производительности, то компилятор уже ничем не поможет (напоминаю,
что от конечного автомата идти очень просто - это не полуинтуитивный подход
ассемблерщика, который действительно может что-то пропустить). Но если есть
описание КА и хорошо освоены ПЛИСы, то...?

 RK> Синтаксис самого Форта. Поставленный 'сверху' на него нормальный язык
 RK> вполне может примерить многих противников Форта (только не надо эту
 RK> систему называть Форт процессором :)

Yesss!... :))) Неужто родили? В долгих муках.... :)))))))

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

Именно так!

 RK> Опиши память, и помести регистры в ней, делов то :)

Ну нельзя так, не берется это средствами синтеза. Возможно, последующие
архитектуры ПЛИС и средства синтеза будут более лояльны к подобным вещам.

 RK> 2 такта, для 1го такта нужна 3х портовая память. Кстати, а как этот
 RK> вопрос рещается для стека - ему же тоже надо прочесть 2 значения и
 RK> записать одно и все в одном такте?

Тут много схемотехнических решений, специфичных для конкретных архитектур
ПЛИС. Вкратце могу сказать, что это делается, и вариантов, в том числе
компромиссных (сколько чтений-записей, за сколько тактов, на каких ресурсах, с
какой скоростью и т.п.) появляется довольно много. Меня в стековой модели
привлекло то, что она полностью укладывается в "два чтения, одна запись".
Регистровая тоже сюда укладывается, но для регистровой нужен компилятор,
который сможет вызов функции сделать так, чтобы параметры были помещены на
стек, но по возможности сразу в регистры... потом обработаются в регистрах и
вернутся на стек... а может и тоже в регистры. И вот теперь возникает такой
вопрос: а ЗАЧЕМ же еще нужен этот психологический барьер в виде стека и
регистров, если стек и регистры - ОДНО И ТО ЖЕ????!!!! Действительно, так
проще даже для того же Си, он получает параметры сразу там, где они могут быть
операндами в командах обработки! Но вот Форт изучить здесь обязательно надо,
поскольку именно он начинает играть роль ассемблера для такого процессора.

 RK> Компилятор может быть простейший. Аналог Форта (но с нормальным
 RK> синтаксисом) и с такими же оптимизациями (то есть вообще без оптимизаций
 RK> :) пишется на связке lex+yacc часа за 4.

Так тоже можно. Однако конкретно у нас не прижилось, поскольку Форт уже
освоили все, кто хоть как-то программирует... и спрашивается - зачем эта
связка, если есть одна сквозная система подготовки ПО? К тому же с
лексическими анализаторами появляется возня с выбором синтаксиса создаваемого
языка.... оно надо - плодить их?

 IT>> О чем и речь! И сколько таких регистров надо: 8, 16, 32?
 RK> Hеизвестно, зависит от программы. Можно набрать пакет тестов и вычислить
 RK> среднюю потребность, но от пиковых выбросов это не гарантирует.

А пиковый выброс означает переход к load/store...

 RK> Потому что компиляторы разные, писались разными людьми и выполняют разные
 RK> оптимизации.

...

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

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

 RK> Он включает примитивы Форта в качестве подмножества.

Но только на Форте писать уже необязательно? Можно ли говорить про переход к
качественно иному уровню?

 IT>> Весь вопрос в том, в сколько команд ассемблера будут укладываться
 IT>> базовые слова Форта.

 RK> 1 команда.

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

 RK> Угу, у Форта весьма урезанный компилятор:
 RK> Лексический анализатор практически отсуствует (все слова режутся по
 RK> пробелам).

Да. Впрочем, необязательно по пробелам, что дает возможность строить довольно
мощные парсеры. По системной переменной BL.

 RK> Семантический анализатор отсуствует полностью - все что набрал
 RK> лексический анализатор немедленно исполняется. Hа Форте любая
 RK> последовательность слов что нибудь да сгенерирует :) Единственные ошибки,
 RK> которые могут возникнуть - отсуствие слова в словаре и исчерпание стека.

Синтаксический анализатор - слова FIND и NUMBER (или есть в словаре, или нет,
но это число). Семантический есть, например, у "закрывающих" слов из
конструкций управления. THEN без IF - тоже возможная ошибка, прекрасно
отслеживаемая анализатором.

 RK> Кодогенератор самый простейший - так называемая template'ная генерация.
 RK> Каждая инструкция преобразуется в некоторый набор команд, который и
 RK> помещается в выходной код, без какого либо учета соседних команд.

Фактически это генерация промежуточного кода, который либо путем
дополнительных нахлобучек (интерпретатор шитого кода) делается подобием
машинного, либо уже генерируется в набор call для слов и lit для чисел.
Годится в качестве "чернового наброска"... хотя Форт для PC, как ни странно (и
несмотря на такое "черновое" качество кода), проигрывает Си в среднем 10-20%
по скорости (а за счет ассемблерных вставок, которые могут быть и там, и там,
этот проигрыш сводится на нет), а вот размер кода существенно меньше.

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

 RK> Вывод: использовать Форт как пособие по построению компиляторов не стоит
 RK> - компиляторы так не строятся.

Компиляторы Си-подобных языков действительно так не строятся :) Форт имеет
смысл использовать лишь как пособие по построению _какого-нибудь_ компилятора,
поскольку самостоятельные поделки интерпретаторов байт-кода и самопальных
целевых языков частенько имеют некорректности просто в грамматике. Форт по
крайней мере является завершенным языком для стековой машины, и многие вещи в
нем не вполне тривиальны. К тому же дискуссии в реале с ярыми сторонниками Си
приводили обычно к тому, что они начинали с жаром доказывать, что в Си "тоже
можно" так сделать, т.е. обеспечить рантаймовый разбор скриптов и доступ к
оборудованию на уровне портов и памяти. Дальше - больше... а можно ли
математику? А дисковые операции? Да без проблем - делаем массив, в котором имя
скрипта и ссылка на функцию, которая будет выполняться для этого имени. А
параметры как же? А из переменных, или сэмулируем стек... да вот как в вашем
любимом Форте! А новые скрипты добавлять? Ну... чуть сложнее... но оставляем в
массиве место, и пишем туда не ссылку на функцию, а индексы скриптов, которые
должны выполняться.... Так извините, ребята, это вы Форт-машину хотите
сделать, только зачем-то на Си и зачем-то с эмуляцией стека. Вон она есть, и
на ассемблере...

(Кстати, я Фортом пользуюсь только под DPMI... ;))) Вот такая вот тонкость...)



_Loader_
Sat Oct 11 2003 01:13, Ilia Tarasov wrote to Roman Khvatov:

 
 IT> Кстати, JCXZ ведь прилично способствует уменьшению числа тактов?

 Cмотря на каком процессоре. Hа суперскалярных x86 способствует увеличению
 числа тактов.

 II> А более
 IT> мощные варианты аппаратной реализации команд цикла?
 
 Проблемы. Если цикл реализован аппаратно, то отработать прерывание
 в процессе выполнения такого цикла непросто. Особенно если это
 переключение задач с вложенными аппаратными циклами.

 IT> Hапример, что можно сказать о системе команд, которая наиболее полно
 IT> "прилегает" к типичным операциям абстрактной вычислительной машины,
 IT> решающей задачу?

 Cуществует N способов описать алгоритм задачи пользуясь операциями
 той или иной вычислительной мащины c той или иной стоимостью различных
 операций. Из способов интересны только высокоуровневые и общепринятые.

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

 IT> Hу слава богу, добрались наконец-то до такого вывода!!! :)))) Да,
 IT> полностью согласен. Именно так и работаем сейчас.

 Можете ли вы внятно пояснить, зачем же тогда нужен форт-посредник и почему
 нельзя просто взять C ?
 Работа необщепринятыми средствами имеет очевидные недостатки. Ради каких
 преимуществ весь сыр-бор?

 IT> Вобщем-то у нас сложился несколько иной подход. Hаиболее критичный кусок
 IT> кода (а он, как правило, довольно небольшой) выписывается в терминах
 IT> абстрактной машины.

 MathLab.


 IT> Затем это примеряется к системе команд конкретного
 IT> процессора.

 MathLab или C/asm. Вполне достаточно для оценки.

 IT> Если не лезет по производительности, то компилятор уже ничем
 IT> не поможет (напоминаю, что от конечного автомата идти очень просто - это
 IT> не полуинтуитивный подход ассемблерщика, который действительно может
 IT> что-то пропустить). Hо если есть описание КА и хорошо освоены ПЛИСы,
 IT> то...?

 Чем же вы все-таки занимаетесь? Алгоритмами ультразвуковой локации,
 разработкой компиляторов или разработкой процессоров? Что является
 конечным продуктом?

 VLV

"There is no business other than show business" (c)


_Loader_
Привет Vladimir!

Saturday October 11 2003 06:44, Vladimir Vassilevsky wrote to Ilia Tarasov:

 IT>> Если не лезет по производительности, то компилятор уже ничем
 IT>> не поможет (напоминаю, что от конечного автомата идти очень просто -
 IT>> это не полуинтуитивный подход ассемблерщика, который действительно
 IT>> может что-то пропустить). Hо если есть описание КА и хорошо освоены
 IT>> ПЛИСы, то...?
 VV>
 VV>  Чем же вы все-таки занимаетесь? Алгоритмами ультразвуковой локации,
 VV>  разработкой компиляторов или разработкой процессоров? Что является
 VV>  конечным продуктом?


Как что? Диссертации....


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



Re: _Loader_
Привет Oleksandr!

Tuesday October 14 2003 04:43, Oleksandr Redchuk wrote to Alexander Torres:

 AB>>> Hе знаю, что нужно для mass production, но для повышения скорости я
 AB>>> думал
 OR>
 AT>> Для mass production - нужен "insertion test", т.е. способность железа
 AT>> программатора определять что вставлен чип.
 AT>> Как оно реально делается - хрен его знает, но работает весьма
 AT>> впечатлительно, отливливает и полхой контакт тоже.
 OR>
 OR>  Один из вариантов -- подать на все ножки, скажем, -5V через резистор
 OR> в 100k. И глянуть, что вышло -- -0.5V на входном диоде или все -5V.
 OR> Таким образом можно отловить "нет ноги где надо" и "есть нога где не надо"
 OR> (Скажем, затолкали 27C256 вместо 27С64).


  Гениально!
  А главное - надежно и точно!

  Сейчас приду на работу - померяю, может там так и сделано ?


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



Re: _Loader_
Hello Oleksandr.

13 Oct 03 21:51, you wrote to me:

 AB>> Портировать gcc гораздо легче, чем кажется. Особенно, если
 AB>> синтезировать процессор самому, подгоняя его под gcc. (Типа
 AB>> каждому insn в rtl - одна команда процессора)
 OR>  Может, расскажешь поподробнее?
 OR>  Глядишь, через какое-то время пофлеймим про gcc-процессоры :-)

Желательно, конечно, скачать исходники gcc и начать поглядывать туда,
и почитывать дукументацию.

В общем, у нутрях gcc работает с RTL (Register Transfer Language).
Есть текстовое представление RTL (Lisp подобное), но внутри он представлен
на структурах данных.

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

Из .md файла, в котором на RTL-языке, описаны команды процессора. Также там
описаны всякие подстановки, если какая-то операция не имеет однозначной
последовательности
команд.

(Hапример команда mov r,i для AVR-а кодируется малость через ж., так как только
в r16..r32
можно загрузить константу)

Из одного или нескольких .c файлов, содержащие всякие функции, использующиеся
из
.md и .h файлов.

Hедавно документацию gcc разбили на 2 части gcc и gccint. Информация о
портировании
попала в gccint

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

А, чуть не забыл. gcc генерирует asm исходник, который нужно потом
ассемблировать в
объектный код. То есть ассемблер придется написать в ручную. (Вроде бы в gas
тоже
есть какие-то методы упрощения этой процедуры)

Дай gcc команду -da и он сохранит на диск RTL твоей программы на всех фазах
обработки.


Alexey


_Loader_
Sat Oct 11 2003 06:44, Vladimir Vassilevsky wrote to Ilia Tarasov:

 RK>>> Даже на Форт процессор можно поставить нормальный С
 RK>>> компилятор, с точки зрения сопровождаемости и читаемости программ это
 RK>>> будет лучше, чем Форт
...
 VV>  Можете ли вы внятно пояснить, зачем же тогда нужен форт-посредник и
 VV>  почему нельзя просто взять C ?
 VV>  Работа необщепринятыми средствами имеет очевидные недостатки. Ради каких
 VV>  преимуществ весь сыр-бор?

У языка Форт есть несколько преимуществ:
-- Компилятор с Форта намного проще, чем компилятор с С, особенно если целевой
проц - Форт-процессор. Чем тратить месяцы на переделки С транслятора, проще за
день-другой сделать Форт и начать работать.
-- Программы на Форте пишутся и отлаживаются примерно в 2-3 раза быстрее чем
на С. Особенно "специфические" задачи, для которых нельзя найти готовую либу
на С. Причина тому - быстрый интерактивный цикл написания/тестирования
процедур на Форте. Сейчас эту же идею заново "открыли" в "extreme
programmming" (как один из методов), я же, глядя на них, только ухмыляюсь ;-)
-- Программы на Форте компактнее чем на С. Как исходник компактнее, так и код
в памяти занимает меньше места.
/* Гы, случай из практики. Коммуникационный драйвер, что я когда-то сделал на
асме для 74-го ПИКа, мой коллега сделал на сях. И в очередном проекте меня
заставили его драйвер применить, "в целях совместимости, переносимости,
унификации" и прочей лапши. Оказалось, что этому говну нужно отвести одного
стека не менее 200 байт, не говоря уж об остальных ресурсах. Еле-еле все
вместе влезло на H8S. Узнай разницу в цене между ПИКом и H8S, и спроси себя -
на что эти деньги потрачены? В основном - на ресурсы, которые сожраны как
самими сями, так и расточительным стилем программирования, к которому писание
на сях приучает */

Есть и другие резоны.

Из отрицательных - в основном психологические факторы. Многие из тех, кто
привык работать на сях, изучать Форт не желают. Приводят любые доводы и
отговорки, вплоть до самых глупых. В треде все это было наглядно видно.
С моей точки зрения, какая-то сермяжная правда за этим есть. Способных людей
не так уж много, а признавать, что не способен писать на Форте просто из-за
генетических проблем - никто не будет.

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


_Loader_
Sat Oct 11 2003 12:06, Alex Kouznetsov wrote to Vladimir Vassilevsky:

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

 VV>>  Можете ли вы внятно пояснить, зачем же тогда нужен форт-посредник и
 VV>>  почему нельзя просто взять C ?
 VV>>  Работа необщепринятыми средствами имеет очевидные недостатки. Ради
 VV>> каких
 VV>>  преимуществ весь сыр-бор?

 AK> У языка Форт есть несколько преимуществ:

 Вроде бы, даже IT согласился, что на форт-систему в качестве языка
 нужно ставить C, чтоб обеспечить читаемость и поддерживаемость.
 Форт как самостоятельный язык - нонсенс.

 AK> -- Компилятор с Форта намного проще, чем компилятор с С,

 Это проблемы тех, кто делает компилляторы.

 AK> особенно если
 AK> целевой проц - Форт-процессор.

 Процессору все равно, на чем написан код, который он исполняет.

 AK> Чем тратить месяцы на переделки С
 AK> транслятора, проще за день-другой сделать Форт и начать работать.

 Вот и обьясни это IAR-у и Микрософту :)
 
 AK> -- Программы на Форте пишутся и отлаживаются примерно в 2-3 раза быстрее
 AK> чем на С.

 Очень странное утверждение.
 Разработка состоит из проектирования, кодирования и отладки процедур
 и ресурсов, и сборки и отладки проекта как целого. Удобный язык облегчает
 кодирование, неудобный - утяжеляет.
  
 AK> Особенно "специфические" задачи, для которых нельзя найти
 AK> готовую либу на С.

 ?????
 Либа - не более чем сборище примитивов, чтобы не тратить время на
 их кодирование. Кстати, я предпочитаю по возможности не пользоваться
 либами, так как из-за их стандартности и ненужной универсальности
 возникает оверхед.  

 AK> Программы на Форте компактнее чем на С. Как
 AK> исходник компактнее, так и код в памяти занимает меньше места.

 Cпорное утверждение. И даже если это так, то кого это волнует.
 Задача вмещается в поставленные рамки - значит, все отлично.  
 Проект должен быть сделан быстро. Его должно быть удобно поддерживать.
 Все остальное - второстепенная шелуха.

 AK> /* Гы, случай из практики. Коммуникационный драйвер, что я когда-то
 AK> сделал на асме для 74-го ПИКа, мой коллега сделал на сях. И в очередном
 AK> проекте меня заставили его драйвер применить, "в целях совместимости,
 AK> переносимости, унификации" и прочей лапши. Оказалось, что этому говну
 AK> нужно отвести одного стека не менее 200 байт, не говоря уж об остальных
 AK> ресурсах. Еле-еле все вместе влезло на H8S. Узнай разницу в цене между
 AK> ПИКом и H8S, и спроси себя - на что эти деньги потрачены? В основном - на
 AK> ресурсы, которые сожраны как самими сями, так и расточительным стилем
 AK> программирования, к которому писание на сях приучает */

 Да, хороший программист может сделать маленькую задачку на асме
 намного эффективнее, чем плохой программист на сях. Только причем тут
 форт и где за дешево набрать хороших программистов на все маленькие
 и большие задачи?

 AK> Из отрицательных - в основном психологические факторы. Многие из тех, кто
 AK> привык работать на сях, изучать Форт не желают.

 И правильно. А зачем? Ты же не собираешься изучать латынь или
 древнегреческий язык.

 AK> В треде все это было наглядно видно.

 Отвратительно. Обе воюющие стороны потеряли лицо :(
 
 AK> Способных
 AK> людей не так уж много, а признавать, что не способен писать на Форте
 AK> просто из-за генетических проблем - никто не будет.

 Способным людям глупо тратить свои способности на борьбу с мелкими
 неудобствами форта и ассемблера.
 
 VLV

"There is no business other than show business" (c)


_Loader_
Sat Oct 11 2003 20:40, Vladimir Vassilevsky wrote to Alex Kouznetsov:

 VV>  Вроде бы, даже IT согласился, что на форт-систему в качестве языка
 VV>  нужно ставить C, чтоб обеспечить читаемость и поддерживаемость.
 VV>  Форт как самостоятельный язык - нонсенс.

Я сказал "_можно_ поставить Си". А из изложенных материалов напрашивается
вопрос, а почему же именно Си и только его?

 VV>  ?????
 VV>  Либа - не более чем сборище примитивов, чтобы не тратить время на
 VV>  их кодирование. Кстати, я предпочитаю по возможности не пользоваться
 VV>  либами, так как из-за их стандартности и ненужной универсальности
 VV>  возникает оверхед.  

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

 AK>> Программы на Форте компактнее чем на С. Как
 AK>> исходник компактнее, так и код в памяти занимает меньше места.

 VV>  Cпорное утверждение. И даже если это так, то кого это волнует.
 VV>  Задача вмещается в поставленные рамки - значит, все отлично.  
 VV>  Проект должен быть сделан быстро. Его должно быть удобно поддерживать.
 VV>  Все остальное - второстепенная шелуха.

Человек тебе рассказывает про _собственный_ опыт. Этот опыт говорит о том, что
на Форте получаются удобные и сопровождаемые программы, которые в ряде случаев
переводят софт в принципиально иной класс. Другими, совершенно независимыми
людьми, при схожих методиках работы были получены аналогичные результаты.


Re: _Loader_
Всем привет.

Quoted text here. Click to load it

 Си как самостоятельный язык (без библиотек, без поддержки крупными компаниями,
без курсов обучения, без громадного числа программистов) тоже нонсенс :). Вот и
приходится ставить Си (кстати Си на Форт очень даже ложится) что-бы обеспечить
"комфорт" в поддержке для среднестатистического программиста :). А вообще никто
так не делает. Обычно если используешь Форт, то Си в качестве альтернативы уже
рассмотрен и отброшен.

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

Quoted text here. Click to load it

 Вы в этом теряете главное преимуущество Си над Фортом - наборы библиотек на все
случаи жизни :).

Quoted text here. Click to load it

Неудобства столь же мелкие как и при работе с Си :). Главное отличие - в Си
пишешь программу, а в Форте выращиваешь систему. После того как понимаешь это
отличие писать в Форте становится очень просто.

                                    АртемКАД



_Loader_
Sat Oct 11 2003 20:40, Vladimir Vassilevsky wrote to Alex Kouznetsov:

 AK>> У языка Форт есть несколько преимуществ:

 VV>  Вроде бы, даже IT согласился, что на форт-систему в качестве языка
 VV>  нужно ставить C, чтоб обеспечить читаемость и поддерживаемость.
 VV>  Форт как самостоятельный язык - нонсенс.

Язык как язык, уж не хуже С. Дело привычки.

 AK>> -- Компилятор с Форта намного проще, чем компилятор с С,

 VV>  Это проблемы тех, кто делает компилляторы.

Я делаю компиляторы, потому и упомянул.

 AK>> особенно если
 AK>> целевой проц - Форт-процессор.

 VV>  Процессору все равно, на чем написан код, который он исполняет.

Тому кто пишет компилятор - не все равно, на какой целевой процессор генерить
код. На стековый процессор генерить код проще.

 AK>> Чем тратить месяцы на переделки С
 AK>> транслятора, проще за день-другой сделать Форт и начать работать.

 VV>  Вот и обьясни это IAR-у и Микрософту :)

Не в кассу...
Микрософт до этого в конце концов допедрил. Его .NET, насколько мне известно,
использует виртуальную стековую машину. Какую виртуальную машину используют
IAR компиляторы - точно не знаю, но скорей всего тоже стековую.

 AK>> -- Программы на Форте пишутся и отлаживаются примерно в 2-3 раза быстрее
 AK>> чем на С.

 VV>  Очень странное утверждение.
 VV>  Разработка состоит из проектирования, кодирования и отладки процедур
 VV>  и ресурсов, и сборки и отладки проекта как целого. Удобный язык
 VV> облегчает  кодирование, неудобный - утяжеляет.

То что ты перечислил - типовой цикл, в т.ч проектов на С. Форт, помимо этого,
позволяет использовать и другие стили программирования. Больше свободы.

 AK>> Особенно "специфические" задачи, для которых нельзя найти
 AK>> готовую либу на С.

 VV>  ?????
 VV>  Либа - не более чем сборище примитивов, чтобы не тратить время на
 VV>  их кодирование. Кстати, я предпочитаю по возможности не пользоваться
 VV>  либами, так как из-за их стандартности и ненужной универсальности
 VV>  возникает оверхед.  

Тогда теряется одно из главных преимуществ С над Фортом.

 AK>> Программы на Форте компактнее чем на С. Как
 AK>> исходник компактнее, так и код в памяти занимает меньше места.

 VV>  Cпорное утверждение. И даже если это так, то кого это волнует.
 VV>  Задача вмещается в поставленные рамки - значит, все отлично.  
 VV>  Проект должен быть сделан быстро. Его должно быть удобно поддерживать.
 VV>  Все остальное - второстепенная шелуха.

То, что ты говоришь, верно для мелкосерийных проектов и халтурок "на дядю".

 VV>  Да, хороший программист может сделать маленькую задачку на асме
 VV>  намного эффективнее, чем плохой программист на сях. Только причем тут
 VV>  форт

На Форте нетрудно сделать так же эффективно, как на асме.

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


_Loader_
What do you think about sharp blades, Vladimir?

[Answer on] [Vladimir Vassilevsky wrote to Alex Kouznetsov at [11 Oct 03
20:40]]:

 AK>> Из отрицательных - в основном психологические факторы. Многие из
 AK>> тех, кто привык работать на сях, изучать Форт не желают.
 VV>  И правильно. А зачем? Ты же не собираешься изучать латынь или
 VV>  древнегреческий язык.
  Отличный пример.
  Вообще-то, всем, занимающимся гуманитарщиной (и особенно -- языками), очень
полезно поизучать латынь и древнегреческий (пусть и не знать их досконально,
etc.). Что, кстати, мы и видим на примере программ многих соотв. факультетов
университетов.
  Тоже самое надо бы и всем CS'  никам (хотя тут, конечно, все больше инженеры,
с них и спрос другой) -- Lisp, Fortran, Forth, и всю классику. Hе знать
досконально, но иметь хорошее представление.

    Remember, pain is part of pleasure, Vladimir.
... Ползет сквозь пальцы медузья плоть некрепкого сна...

Re: _Loader_
Hello Oleksandr!

14 Oct 03 04:44, Oleksandr Redchuk wrote to Vladislav Baliasov:

 >>>>> (Vcc+7V) ----|____|----- MCU Pin. (питание 0V, +Vcc)
 >>>>>             220k
 >>>>>
 >>>>> Я тебя правильно понял?

 AK>>>> Да (+/- емкость :))

 YK>>> Гнать разработчика поганой метлой.

 VB>> Hу, пока ничего криминального я лично не вижу.

 OR> Hу как сказать...

Вообще-то, если добавить резистор делителя на землю (про емкость Артем
упомянул), то вполне честное решение. Т.е. оно и так вполне честное, но я бы
поделил (в том числе и из соображения исключения висячего входа). Да и номинал
резистора с запасом на порядок... В похожем виде мы использовали неоднократно в
случаях, когда важно только "есть/нет".

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

[...]

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

Согласен, по поводу аналоговых. Цифровой же вход в автомобиле - вполне.

[...]
 OR> Как прекрасно уходило напряжение на выходе 4051, когда на
 OR> _невыбранные_ входы поступало 12В....

Для цифровых входов AVR влияния не наблюдается, естественно. Про АЦП врать не
буду.

 OR> p.s.2 Кстати, а цепи кварцевого генератора довольно высокоомные,
 OR> и левая утечка туда тоже может быть неприятной.
 OR> Так что таки поэкспериментируй, доложи общественности результаты :-)

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

Hамедни видел мегу8515, в которой не только не был запрограммирован CKOPT,
из-за чего генератор работал с маленьким размахом (кварц 4 МГц, емкости 27
пик), но и из-за ошибки монтажа вообще отсутствовало штатное питание меги. И
питалась она как раз паразитно по входам, в том числе и от того же сдвигового
регистра, которым и управляла. Она же управляла и 3-мя драйверами ULN2803, а
там, помнится, резисторы по входам всего 2.4 кОм. И еще парой биполяров через 1
кОм в базу ОЭ. Hо зато как питалась - песня! :-) Забавно, что все работало
вполне устойчиво, включая и чтение/запись внутренней EEPROM. Вот только для
управления регистром не всегда хватало уровня, отсюда и некоторые странные
проявления отработки входных сигналов, заставившие пристально вглядеться.

У AVR "правильный" тактовый генератор :-) И цифровые входы/выходы - тоже :-)



73 & Cheerio!   Andy.

Site Timeline