_Loader_ - Page 14

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

Threaded View
Re: _Loader_
Thu Oct 09 2003 00:19, Artem Kamburov wrote to Dima Orlov:

 >> Синтаксис и семантика должны быть дружественны человеку, а не враждебны,
 >> как  среда форт-системы с ее извращенной логикой.

 AK> Правильно, и все кто пишит на Форте имеют извращенную логику.... :-\.

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

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

 AK>  Осталось только функциональность обеспечить, а то труп - тоже устойчивое
 AK> состояние.

Кстати, стандартный подход для PLC. И никаких проблем с функциональностью
в пределах требуемого.

 AK>  Ксати, NASA активно использует Форт в спутниках, и там одна из задач -
 AK> дистанционная загрузка кода.

То-то я все не мог понять, почему у них столько проблем с софтом...

WBR, Юрий.


_Loader_
Привет Yuriy!

Thursday October 09 2003 05:56, Yuriy K wrote to Artem Kamburov:

 >>> Синтаксис и семантика должны быть дружественны человеку, а не
 >>> враждебны, как  среда форт-системы с ее извращенной логикой.
 YK>
 AK>> Правильно, и все кто пишит на Форте имеют извращенную логику.... :-\.
 YK>
 YK> Интересно бы посчитать корреляцию между писателями на Форте и говорящими
 YK> виндовс - суксь и маздай. :-))) Как мне кажется она будет заметна...

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

    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_
Thu Oct 09 2003 05:56, Yuriy K wrote to Artem Kamburov:

 AK>>  Ксати, NASA активно использует Форт в спутниках, и там одна из задач -
 AK>> дистанционная загрузка кода.

 YK> То-то я все не мог понять, почему у них столько проблем с софтом...

Не скажу про NASA, но слышал, как зам. главного конструктора "Энергии"
клятвенно обещал академикам, что больше никакого западного софта на МКС не
будет - только собственной российской разработки, включая ОС и все
компиляторы. Там как-то повис управляющий компьютер.. хорошо повис, вплоть до
отключения гироскопов... Хорошо хоть у кого-то голова на плечах есть и не все
доверяют волшебной кнопочке Compile...


Re: _Loader_
Hello Ilia.

07 Oct 03 00:50, you wrote to me:

 IT> Hе единственная, но все же основная :) Hапример, в довольно большой
 IT> программе почти все время вполне может уходить на выполнение
 IT> вложенного цикла, перебирающего 5-10 параметров какой-нибудь формулы.

Hо кроме перебора она все же с ними что то делать должна?

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

Просто переходы параллелить смысла нет - вся эта кухня расчитана на
преимущественно вычислительные задачи.

 IT>>>>> умножению с накоплением. Представим, что перемножитель один, и

 IT>                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 IT> Понятно, что в реальных кристаллах их может быть несколько... Я про
 IT> пример.

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


 IT>>> Конечно, 3 хороших :) Hапример, стековая архитектура на FPGA
 IT>>> Xilinx дает ровно в 16 раз больший объем стековой памяти на тех
 IT>>> же ресурсах... ;)))
 RK>> Возможно. Я так понимаю, что стек там делается на FIFO?
 IT> Hа распределенной памяти, конфигурируемой также как FIFO (или стек).
 IT> Под FIFO есть только языки типа Onyx-а, а это еще экзотичнее Форта.

FIFO я имею в виду аппаратное (точнее даже LIFO), со стороны архитектурной
модели это обычный стек.

 RK>> А кто говорит про собственный?
 RK>> Hаписать ХОРОШИЙ компилятор - это _очень_ непростая задача. Его
 RK>> объемы вполне могут зашкалить за несколько милионов строк на С.

 IT> Даже неоптимизирующий целевой компилятор для форт-процессора (что-то
 IT> около 100 строк на Форте) дает очень неплохие результаты.

Ассемблеры (к каковым и относится целевой Форт компилятор) обычно
оптимизирующими не бывают :) Оптимизирующими бывают ЯВУ (например с С в Форт)

 IT> По поводу читаемости - очень спорный вопрос. Читаемость для кого?

Для того, кто это быдет сопровождать.

 IT> Для эмбеддера, программирующего по необходимости?

Hет, это его личные трудности :)

 IT> Для специалиста в cs, которому по большому счету все равно какой
 IT> язык?

'Сферический специалист в ваккуме' ?

 IT> Для фортера со стажем, который не будет писать криво?

А где потом взять еще одного 'фортера со стажем', который сможет разобраться в
'некриво' написанном первым специалистом?

 IT> К тому же... а что, собственно, надо будет исправлять в железе после
 IT> тщательного тестирования на моделях?

Сколько Atmel и Microchip 'тщательно тестировали' свои кристаллы на моделях?
Интересно, почему же у них новые версии кристаллов идут с _офигительным_
количеством errat?

 IT> Форт - это ведь не свалившаяся с неба фиговина, стековая машина имеет
 IT> под собой четкое и ясное математическое описание.

От математики до железа довольно большой путь :)

 IT> Я одно время сравнивал алгоритмы, реализуемые для пентиума на Си++ и
 IT> для своего форт-процессора. Численные, с вложенными циклами, с
 IT> обработкой массивов, с вызовом функций и т.п. В среднем получалось,
 IT> что для достижения паритета пентиум должен иметь от 1,5 до 4 раз
 IT> большую частоту!

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

 RK>> А если у Форт процессора кончится стек? Это проблема того же
 RK>> плана.

 IT> Во-первых, он больше на тех же ресурсах, и наращивается прозрачнее.

Одинаковый, а РОH'ы наращиваются почти так же прозрачно.

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

Хм, а если есть рекурсия?

 IT> Для несложного эмбеддеда 16 - это много.

'Для несложного эмбеддеда' возможно.

 IT> Тем не менее количество внутренних соединений у полностью
 IT> симметричного процессора будет больше

Отнюдь. Скорее меньше. Они внутри обычно строятся на основе шин, а шине все
равно, сколько к ней подключено регистров - 4 или 5.

 IT>>> a = b + c + d  (1)
 IT>>> b = a + d - с  (2)
 IT>>> c = a + b + 3  (3)
 IT>>> d = a + b + c  (4)

(1)

 IT> b = (b + c + d ) + d - c
 IT> с = (b + c + d ) + d - c
 IT> d = (b + c + d ) + b - c

(2)

 IT> Видимо, от количества регистров все же зависит?

Hет. Во первых - это не эквивалентно (1). А если имеется в виду параллельное
исполнение всех 3х строк, то куда делся 'a=b+c+d'? Если же собственно a после
вычислений не используется, то (2) эквивалентно
b = c = b + 2*d
d = 2*b+d

А если говорить в общем, то зависимости по данным (сами по себе) не зависят от
количества доступных регистров. Соответственно простои конвеера (которые
зависят от зависимостям по данным) не зависят (напрямую) от количества
регистров. От количества регистров зависит появятся ли spill/fill'ы, а уже они
могут привести и к дополнительным зависимостям и к простою конвеера и к
дополнительным обращениям в память.

 RK>> Увеличение числа РОHов - тоже.
 IT> Hу как же не сопровождается? Ассемблер-то меняется...

Смотря как там были представленны эти РОH'ы, если в виде R<nn> (где <nn> -
число), то просто надо изменить константы в ассемблере.

Кстати, по поводу помещения Форт процессора в FPGA - мне представляется, что
наиболее простым и компактным по коду будет архитектура с 2мя стеками (данных и
возвратов), и набором команд типа:
1) Поместить константу в стек (многобайтовая)
2) Исполнить операцию над стеком (однобайтовая)
3) Безусловный переход (многобайтовая)
4) Условный переход (многобайтовая)
5) Вызов подпрограммы (многобайтовая)
6) Возврат из подпрограммы

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

Roman


_Loader_
Wed Oct 08 2003 09:18, Roman Khvatov wrote to Ilia Tarasov:

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

 RK> Просто переходы параллелить смысла нет - вся эта кухня расчитана на
 RK> преимущественно вычислительные задачи.

Ээээ, я про переходы между узлами графа состояний... :) Переход к новому
адресу - это несколько не то. Например, если есть текст

A = 2  (1)
B = 1  (2)
A = 3  (3)

то можно поставить в соответствия строкам состояния S1, S2, S3 соответственно.
Получаем граф S1 -> S2 -> S3. Выполнение первой строки программы осуществляет
переход от состояния S1 к состоянию S2, и т.д. Я здесь пытаюсь говорить о
таких графах, в которых переход от состояния Si к состоянию Si+1 является
"атомарным", т.е. не может быть улучшен внутри.

 IT>> Понятно, что в реальных кристаллах их может быть несколько... Я про
 IT>> пример.

 RK> Это неправильный пример, суперскаляр с одним исполнительным устройством
 RK> не делают - это уже будет не суперскаляр.

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

 RK>>> Возможно. Я так понимаю, что стек там делается на FIFO?
 IT>> Hа распределенной памяти, конфигурируемой также как FIFO (или стек).
 IT>> Под FIFO есть только языки типа Onyx-а, а это еще экзотичнее Форта.

 RK> FIFO я имею в виду аппаратное (точнее даже LIFO), со стороны
 RK> архитектурной модели это обычный стек.

Я понял... Все-таки FIFO - это очередь, LIFO - это стек.... есть еще деки, но
это уже реализуется чуть сложнее. То, что есть в FPGA, заточено под очереди
(например, есть возможность реализации сдвигового регистра), но и стек там
получается на тех же ресурсах. Если говорить об очередях, то это Onyx.

 IT>> Даже неоптимизирующий целевой компилятор для форт-процессора (что-то
 IT>> около 100 строк на Форте) дает очень неплохие результаты.

 RK> Ассемблеры (к каковым и относится целевой Форт компилятор) обычно
 RK> оптимизирующими не бывают :) Оптимизирующими бывают ЯВУ (например с С в
 RK> Форт)

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

Кстати, Форт все же компилирует некий промежуточный код, поэтому формально
стадия оптимизация применима к его "движку".

 IT>> По поводу читаемости - очень спорный вопрос. Читаемость для кого?

 RK> Для того, кто это быдет сопровождать.

Ну у него же должно быть хотя бы минимальное понимание того, что он
сопровождает? Наконец, он же не будет сопровождать кашу вида VAR @ DUP - ROT
SWAP [ HEX ] 2 ROT ! -

 IT>> Для специалиста в cs, которому по большому счету все равно какой
 IT>> язык?

 RK> 'Сферический специалист в ваккуме' ?

А как ты считаешь, Си и Паскаль - разные языки? А на каком уровне начинается
их общность и трудно ли мыслить на этом абстрактном уровне, а потом выбирать,
какой синтаксис будет применен?

 IT>> Для фортера со стажем, который не будет писать криво?

 RK> А где потом взять еще одного 'фортера со стажем', который сможет
 RK> разобраться в 'некриво' написанном первым специалистом?

Господи, ну почему все считают, что на Форте можно писать только в стиле
базового словаря? Достаточно просто сохранять постфиксную запись (да и то не
всегда), и все будет прекрасно!

 IT>> К тому же... а что, собственно, надо будет исправлять в железе после
 IT>> тщательного тестирования на моделях?

 RK> Сколько Atmel и Microchip 'тщательно тестировали' свои кристаллы на
 RK> моделях? Интересно, почему же у них новые версии кристаллов идут с
 RK> _офигительным_ количеством errat?

И мне интересно! Я про топ-модели Intel-а в основном... Фирма с миллиардными
вложениями в исследования, все-таки. А тут вот решили сэкономить...

 IT>> Форт - это ведь не свалившаяся с неба фиговина, стековая машина имеет
 IT>> под собой четкое и ясное математическое описание.

 RK> От математики до железа довольно большой путь :)

В среднем - один транслятор HDL :)

 IT>> Я одно время сравнивал алгоритмы, реализуемые для пентиума на Си++ и
 IT>> для своего форт-процессора. Численные, с вложенными циклами, с
 IT>> обработкой массивов, с вызовом функций и т.п. В среднем получалось,
 IT>> что для достижения паритета пентиум должен иметь от 1,5 до 4 раз
 IT>> большую частоту!

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

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

 RK>>> А если у Форт процессора кончится стек? Это проблема того же
 RK>>> плана.

 IT>> Во-первых, он больше на тех же ресурсах, и наращивается прозрачнее.

 RK> Одинаковый, а РОH'ы наращиваются почти так же прозрачно.

Нет, в ПЛИС не одинаковый, а ровно в 16 раз больше.

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

 RK> Хм, а если есть рекурсия?

По иерархии - распределенная память (блоки по 16 бит), блочная память (4 или
18 кбит на блок в зависимости от серии), внешняя память. Собственно, так и
сейчас эти проблемы решаются, и стеки у программ далеко не резиновые.

 IT>> Для несложного эмбеддеда 16 - это много.

 RK> 'Для несложного эмбеддеда' возможно.

Для не так чтобы совсем простых регуляторов реально использовались 4-5 ячеек
стека... Это я отследил для интереса после разработки (кодировалось все в
обычном стиле, без оглядки на стек).

 IT>> Тем не менее количество внутренних соединений у полностью
 IT>> симметричного процессора будет больше

 RK> Отнюдь. Скорее меньше. Они внутри обычно строятся на основе шин, а шине
 RK> все равно, сколько к ней подключено регистров - 4 или 5.

Далеко не все равно! А как они будут соединяться? Мультиплексором (тогда
2-4-8-16 шин соответствуют 1-2-3-4 уровням последовательного соединения
устройств), или через трехстабильные буферы (то еще удовольствие - у них
задержки распространения больше)?

 IT>>>> a = b + c + d  (1)
 IT>>>> b = a + d - с  (2)
 IT>>>> c = a + b + 3  (3)
 IT>>>> d = a + b + c  (4)

 RK> (1)

 IT>> b = (b + c + d ) + d - c
 IT>> с = (b + c + d ) + d - c
 IT>> d = (b + c + d ) + b - c

 RK> (2)

 IT>> Видимо, от количества регистров все же зависит?

 RK> Hет. Во первых - это не эквивалентно (1). А если имеется в виду
 RK> параллельное исполнение всех 3х строк, то куда делся 'a=b+c+d'? Если же
 RK> собственно a после вычислений не используется, то (2) эквивалентно b = c
 RK> = b + 2*d
 RK> d = 2*b+d

(Подожди, а почему не эквивалентно? Может быть, я не заметил чего-то? Я-то как
раз писал имея в виду, что они эквивалентны по получаемому результату)

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

 RK> А если говорить в общем, то зависимости по данным (сами по себе) не
 RK> зависят от количества доступных регистров. Соответственно простои
 RK> конвеера (которые зависят от зависимостям по данным) не зависят
 RK> (напрямую) от количества регистров. От количества регистров зависит
 RK> появятся ли spill/fill'ы, а уже они могут привести и к дополнительным
 RK> зависимостям и к простою конвеера и к дополнительным обращениям в память.

Да, именно так.

 RK>>> Увеличение числа РОHов - тоже.
 IT>> Hу как же не сопровождается? Ассемблер-то меняется...

 RK> Смотря как там были представленны эти РОH'ы, если в виде R<nn> (где <nn>
 RK> - число), то просто надо изменить константы в ассемблере.

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

 RK> Кстати, по поводу помещения Форт процессора в FPGA - мне представляется,
 RK> что наиболее простым и компактным по коду будет архитектура с 2мя стеками
 RK> (данных и возвратов), и набором команд типа: 1) Поместить константу в
 RK> стек (многобайтовая)
 RK> 2) Исполнить операцию над стеком (однобайтовая)
 RK> 3) Безусловный переход (многобайтовая)
 RK> 4) Условный переход (многобайтовая)
 RK> 5) Вызов подпрограммы (многобайтовая)
 RK> 6) Возврат из подпрограммы

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

Может быть, тоже сходишь на www.kc.ru/~tile ? :) Такое уже стоит в готовом
изделии.

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


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

Quoted text here. Click to load it

Кстати, Атмел на последних чипах вроде исправился :).

Quoted text here. Click to load it

А никто из здесь присутствующих ТОЧНО и не знает. Реальный опыт работы с ними
есть только у Ильи, а он повышает производительность процессора весьма
специфическим способом - подгоняет ресурсы процессора под требования задачи.

Quoted text here. Click to load it

Нет. Добавление РОНа может повлечь необходимость изменения всей системы комманд
процессора (вплоть до увеличения размера комманды), а добавление уровня стека
это только добавление уровня стека :).

                                     АртемКАД





Re: _Loader_
Thu Oct 09 2003 00:19, Artem Kamburov wrote to Roman Khvatov:

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

 AK> А никто из здесь присутствующих ТОЧHО и не знает. Реальный опыт работы с
 AK> ними есть только у Ильи, а он повышает производительность процессора
 AK> весьма специфическим способом - подгоняет ресурсы процессора под
 AK> требования задачи.

А очень хорошее направление - называется "совместным проектированием
аппаратной и программной части". Этим сейчас активно занимается Celoxica,
разработавшая неплохую систему синтеза HDL четвертого поколения - Handel-C.
ПЛИС как раз и позволяет реализовать только то, что потребуется для решения
задачи, очень существенно оптимизируя проект на структурном уровне.
Про 5 секунд и 3,5 минуты я уже писал? Вот это разница между софт-ядром и MB90
(неплохой, кстати, контроллер).

(Кстати, если кому из вузов нужен программный пакет от Celoxic-и бесплатно -
ко мне в мыло... мне уже надоело искать по России участников их
университетской программы, а они приглашают)


Re: _Loader_
Hello Ilia.

07 Oct 03 00:52, you wrote to me:

 IT>>> Hа памяти вообще-то. Это проще, чем регистр...

 RK>> А 'память' - это где? Если на кристале, то это те же регистры,
 RK>> если снаружи - то это будет _жуткий_ тормоз.

 IT> Память на кристалле отличается от регистра на кристалле.

Да ну?

 IT> Сейчас на 1 бит регистра приходится 16 бит памяти (у Xilinx).

А кто заставляет РОH'ы делать на регистрах? Они с испокон веков делались на
памяти (возможно двухпортовой)

 IT> Будет иначе - будем думать... :)

Думайте, оно всегда полезно :)

Roman


_Loader_
Wed Oct 08 2003 10:21, Roman Khvatov wrote to Ilia Tarasov:

 IT>> Память на кристалле отличается от регистра на кристалле.

 RK> Да ну?

Ну посмотри pdf на ПЛИСы... Где там регистр и где там память.

 IT>> Сейчас на 1 бит регистра приходится 16 бит памяти (у Xilinx).

 RK> А кто заставляет РОH'ы делать на регистрах? Они с испокон веков делались
 RK> на памяти (возможно двухпортовой)

Ж:-[      ]

И как ЭТО параллелить? Это когда из 16 регистров доступ только к одному
(двум)? И сколько тактов гарантированно хватит на операции с таким набором?

Сколько ни видел софтовых ядер, везде регистрам соответствовали обычные
signal. Память делается немного не так.

 IT>> Будет иначе - будем думать... :)

 RK> Думайте, оно всегда полезно :)

А то! :)


_Loader_
Sat Oct 04 2003 19:40, Dima Orlov wrote to Ilia Tarasov:

 >> Мне попадалось: Eserv (сервер, собственно...), nnCron (планировщик
 >> для win), еще была некая САПР, уже не помню, чья. Это из более-менее
 >> распространенного, причем только то, что само попалось на глаза в инете.

 DO> Как я и говорю, единичные вещи.

И затраты на них были не менее единичные.

 >> Там, где я работаю,
 >> что-то около 30 проектов на Форте для разнообразных расчетов и
 >> управления установками с помощью PC, а в эхотажных разработках _ничего_,
 >> кроме Форта, и нет...

 DO> Мои соболезнования.

Передавай кому-нибудь еще... :))) (Видимо, ты уже уперся...)

 >> Hе особо, пока не припечет и грамотный фортер не решит его задачу
 >> комплексным подходом, переписав и системное и прикладное ПО.

 DO> Бог в помощь. Вот чего я не боюсь совершенно, так это конкуренции со
 DO> стороны фортеров.

И не бойся - ты совершенно в другой области работаешь. Просто для решения
некоторого класса задач тебя не позовут, поскольку ты не знаком со стековой
моделью и ее преимуществами, вот и все.

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

 DO> Хуже. Одна обратная польская запись чего стоит.

И чего она стоит? А префиксная запись чего стоит? Т.е. обязательно 2+2, но не
2 2 + и упаси боже не add(2,2)? А препроцессоры и лексические анализаторы
применить запрещает религия? А почитать "Язык Форт и его реализации" Баранова,
где инфиксная запись выражений вводится средствами языка на полутора
страницах? Другое дело, что постфикс - такая мелочь, что при наличии привычки
внимания на него уже не обращаешь.

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

 DO> Что ему вообще в embedded системе делать?

Ну вот была система, в которой входной поток интерпретатора грузился прямо
через COM. Соответственно, шли через него свертки слов Форта из библиотеки, и
не надо было придумывать какой-то дополнительный протокол обмена между хостом
и embedded-системой. Хотя обычно код генерился целевым компилятором, и ничего
лишнего там не было. Получалось нечто похожее на макроассемблер, только
удобства побольше.

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

 DO> Кстати ассемблер не обязательно дает эту однозначность.

Да, я в курсе, но не для всех процессоров. В 80x86 есть, например, сокращенные
однобайтовые варианты команд, работающих с AX (тогда как для других регистров
команды двухбайтовые). Имеется в виду это?
Тем не менее ассемблеры обычно выбирают именно сокращенные варианты, так что в
подавляющем большинстве случаев можно говорить именно о взаимной
однозначности. (А если ее нет, то прощай дизассемблирование).

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

 DO> Кого не будет делать? То, что на форте можно написать ассемблер я в
 DO> курсе, вопрос только на кой это надо.

Ну если у тебя есть, то все в порядке. Я же тебя не перетягиваю на Форт,
просто говорю, что мы не пользуемся ассемблерами, предпочитая работать с
унифицированным кросс-ассемблером, написанным на Форте для PC и обрабатывающим
как ассемблер, так и Форт для целевых процессоров. У тебя есть существенные
возражения?

 DO> Однозначно первый вариант (разумеется учитывая бессмысленную
 DO> избыточность):

 DO> mov ax, myvar
 DO> add ax, another_var

Ну тут я сымитировал стиль 80x86, хотя на самом деле не всегда можно делать
так, как ты написал.

 DO> Тут понятно что делает программа, в отличие от совершенно бессмысленной
 DO> строки

 DO> get_myvar get_another_var +

А Add(myvar, another_var) тоже бессмысленно?

 DO> Заодно понятно почему программа на форте оказывается сравнимой с
 DO> ассемблерной.

Если есть команда прямой загрузки регистра из памяти, то она и будет
использована... о чем речь?

 >> А осмысленного русского текста на Форте тебе ни разу не попадалось?

 DO> Hет, а зачам писать русский текст на форте?

Например, для повышения читабельности.

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

 DO> Можно, а вот на форте читаемую - врядли. Мне не попадалось.

Это еще ни о чем не говорит. Мне - попадалось, и нечитаемость по моему опыту
не является главным контраргументом.

 >> Форт, по крайней мере, не запрещает использовать
 >> русские символы, не запрещает обустраивать синтаксис по полной
 >> программе и т.п.

 DO> Вот именно. Язык, который ничего не запрещает провоцирует писать так, что
 DO> кроме автора это никто и никогда не поймет.

Смотря какой автор и какие цели он перед собой ставит. А что, Си чрезмерно
читаемый?

 >> Вот тебе примерчик, скрипт на Форте. ЭТО нечитаемо????
 >> ====================================================
 >> ПЛОСКОСТЬ Базовая
 >> ПРЯМАЯ Прямая1
 >> ПРЯМАЯ Прямая2

 >> УГОЛ МЕЖДУ Прямая1 И Прямая2 БАЗА Базовая
 >> HОМИHАЛЬHО 18
 >> +ДОПУСК 0.1
 >> -ДОПУСК -0.1  ====================================================

 DO> Читаемо, но что делается непонятно совершенно. От того, что оно записано
 DO> кирилицей понятней не становится. Hаписана какая-то абракадабра на вроде

 DO>  - Петька, прибор!
 DO>  - 78!
 DO>  - Что 78?

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


Re: _Loader_
Hello, Ilia Tarasov !

 >>> Да нет, ругаемси.. :) Квалифицируют языки специалисты в computer
 >>> science, а не пользователи компиляторов...

 >  DO> Они со своей стороны, а пользователи со своей.

 > ... и кого волнуют проблемы негров? ;)

Когда производителей не волнуют проблемы пользователей, без работы остаются
производители.

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

 >  DO> Дешевле у них не потому что они на форте пишут, а потому что за гроши
 >  DO> работают.

 > Я не спрашиваю, почему у них дешевле. Я спрашиваю, почему ты на
 > них нападаешь?

Потому что форт их убогий из их поделий как ослиные уши вечно торчит.

 >>> Т.е. ответа нет, а эмоции - напротив, присутствуют...

 >  DO> А какого ответа ты ждал на идиотский вопрос? Си вовсе не эквивалент
 >  DO> форту, какой смысл сравнивать цены компиляторов? Такой же как цену
 >  DO> автомобиля и циркового велосипеда (последний обычно самодельный).

 > Я ни в одной разработке не замечал, что Форт существенно уступает

Да мало ли чего ты там в своих разработках не замечал?

 > Си. Твои наблюдения ни о чем не говорят.

Твои тоже.

 >  DO> Видишь ли, я не сильно нуждаюсь в твоих рассказах, у меня свои глаза
 >  DO> есть.

 > А тогда зачем поддерживаешь флейм? Hе согласен - либо аргументированно

А ты зачем?  И где твои аргументированные доказательства?

 > либо остановись на том, что _тебе_ Форт не нужен (а я и
 > сам буду утверждать, что в типичных для тебя проектах он не нужен).

Он не только не нужен, он вреден.

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

А ты не пытаешься?

 >>> Положу за вычетом налогов :) Все равно будет больше того нуля,
 >>> который у меня останется после покупки Evaluation Kit с компилятором.

 >  DO> Hе вижу никакой связи между EWB и компилятором. Кстати EWB часто даются
 >  DO> бесплатно.

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

Сумме чего?

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

Какого еще конструктора, что ты несешь? EWB обычно очень простая и потому
дешевая штука, но часто очень помогает быстро освоить кристалл. Причем к ней
компилятор с С я вообще не понимаю. Пощупать тебе его как правило дают
бесплатно. Стоит он обычно не дорого. Если для твоих проектов это деньги, то я
бы постеснялся вообще на них ссылаться.

 >>> Тогда приводи основания для _повсеместного_ неиспользования Форта
 >>> _ни в одном_ из проектов.

 >  DO> Hевозможность или крайняя затрудненность для других потом в этом
 >  DO> разбираться.

 > Другие должны владеть (Фортом), без этого никуда, какой язык в

Это им не поможет. Они должны не только фортом владеть, но еще и разгрести все
те нагромождения, которые первый наопределял.


 >  DO> Плюс отсутсвие сколько-нибудь внятных оснований для его использования
 > не на спец процессорах.

 > А ты специально пропускаешь в моих сообщениях упоминания о спецсистемах? :))

Специально, потому что изначально о них никто не говорил.

 >>> на языке, который ты считаешь неудобным и бестолковым. По каким
 >>> таким причинам?

 >  DO> По таким, что хоть и редко, но их творения вылазят наружу, а из них
 >  DO> обычно торчат уши этого форта, будь он неладен.

 > Предлагаемый мной выход - давить "белых ворон"... Форт не есть
 > основание писать так, как вздумается, тем более что программиста на Си
 > обычно есть кому проконтролировать и поправить, а к Форту надо
 > допускать человека,

Гораздо эффективнее не допускать вообще форт.

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

Hе будет толка.

 >>> Совместимостью с чем? С целевым железом?

 >  DO> Hет, с девелоперским инструментарием.

 > И зачем, по-твоему, Форт вообще нужен здесь?

По-моему форт как раз и не нужен, более того, от него один вред.

 > Весь инструментарий в одном приложении.

А его там быть-то и не должно.

 >>> Hасчет отладочной информации - нет, не ставил такую задачу.

 >  DO> Я почему-то так и думал.

 > Правильно думал.

Еще бы.

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

 >  DO> С какой блин консоли? Речь-то об embedded системах идет, их при помощи
 >  DO> внутрисхемных эмуляторов отлаживают в реальном времени.

 > Ты опять применяешь ко мне свои представления о ходе отладки. Есть
 > там консоль - COM в обе стороны...

Где "там"? В каких-то твоих сферических системах копеечной стоимости?

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

 >  DO> Hу-ну.

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

Hет конечно, как и в форт-программе ему взятся неоткуда, когда она зашита в ПЗУ
и работает в реальном времени.

 >>> Просмотреть "руками" содержимое переменной и запустить 1 (одно) слово

 >  DO> Причем тут переменные форта? Как ты будешь эти слова запускать?
 >  DO> Программа-то в ПЗУ...

 > Итак. В ПЗУ находится Форт (со словарными статьями). Работает

В ПЗУ находится _все_, у контроллера есть ПЗУ и несколько сот регистров ОЗУ.

 > интерпретатор, который разбирает строку, полученную из COM.

Чего ему там делать-то?

 > В процессе разбора в произвольном
 > (задаваемом во введенной строке) порядке вызываются слова из

А словарю чего делать в ПЗУ?

 > словаря, если они там есть. Поскольку переменнные там явно есть,

Переменные в ОЗУ и SFR'ах контроллера.

 > и есть слово, посылающее их значение в COM,

Зачем там нужны лишние слова?

 > не составляет труда подать на интерпретатор строку вида

 > MY_VAR @ ->COM

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

 > Обрати внимание, что в ПЗУ именно такой строки нигде нет, подается
 > по шнурку.

Программа исполняемая тоже по шнурку?

 > Это не есть возможность просмотра состояния памяти, а заодно и
 > запуска любого слова с любыми параметрами?

Hет конечно. И зачем запускать слова с параметрами?

 >  DO> В сад с такой "функциональностью". Я конечно понимаю, что крупные
 >  DO> специалисты в computer science пишут программы, которые в отладке не
 >  DO> нуждаются и работают сразу, но я не такой умный, мне надо смотреть как
 >  DO> взаимодействует программа с железом на живом железе и при живой
 >  DO> программе. И без ICE это все занимает слишком много времени.

 > См. выше. Hе понимаю, чем плоха возможность запускать слово штатными
 > средствами уже работающей системы, по сравнению с расстановкой
 > breakpoints в готовом коде...

Охотно верю в то, что ты этого не понимаешь.

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

 >  DO> Hе кросс-компиляторы, а убогий форт.

 > А посмотри-ка ты Dragon Book, а? Прежде чем ляпать такое....

Чего мне туда смотреть?

 > Hапример, что такое раскрутка компиляторов, и вокруг этого.

Зачем мне крутить компиляторы? У меня есть готовые.

 > Я тебе памятник поставлю, если
 > ты мне докажешь, что целевой код зависит от языка, на котором
 > написан кросс-компилятор....

Зачем мне какой-то явный бред доказывать?

 >  DO> Да и то это все в твоих мечтах. Я не

 > Медицинское заключение о моих галлюцинациях, плиз....

 >  DO> верю, что даже крупнейший специалист в computer science за полчаса
 > освоит
 >  DO> систему команд нового процессора и сделает для нее что-то осмысленное.

 > Как ты думаешь, чем я вообще занимаюсь, и зачем? Я, видишь ли,

Понятия не имею.

 > именно за полчаса проектировал и заодно осваивал процессорные ядра в ПЛИС по
 > общим требованиям.

Могу себе представить этия ядра...

 > Вот такая работа, и такое направление. Кстати, я не совсем понял
 > одного эмбеддера, делавшего несколько устройств на PIC, когда он
 > сказал, что у AVR слишком сложная система команд.

А я тут причем? Я пишу преимущественно на С, мне по-фиг какая у процессора
система команд, мне гораздо важней какая у него периферия и сколько это стоит.
Вот по этому соотношению AVR и пролетает, да и вообще все кроме PIC'ов
пролетает в моих задачах.

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

Чего я не хочу понимать?

 >>> Кстати, я этот момент рассматриваю не как рекомендуемый к широкому
 >>> распространению.

 >  DO> А я рассматриваю как диверсию.

 > Твое право. Только при принятии решения я твоим мнением руководствоваться
 > никак не буду. В итоге я пишу и на связке Си+асм, и на Форте, а ты

А я не буду твоим, и другим не буду рекомендовать.

 > только на первом...

И что?

 >>> Hравится асм+Си - пиши.

 >  DO> Мне это все вообще не нравится, но С и ассемблер - оптимальное
 >  DO> соотношение по производительности, сопровождаемости, переносимости для
 >  DO> подавляющего большинства задач.

 > Лозунги, однако...

Практика. Подтвержденная количеством написанного на С по сравнению с фортом.

 > К тому же мне не совсем понятна увязка "не нравится" и

Мне нравится лежать в тенечке, а не сидеть с паяльником, осциллографом и
компьютером день деньской.

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

Hе хочу, не умею и даже не хочу уметь. Я на жизнь зарабатываю другим, в
частности эхотагом, к которому написание компиляторов никакого отношения не
имеет. А если embedded инженер пишет компиляторы, то 99% что он и инженер
плохой и компиляторы у него ни к черту

 > компилятора тебе закрыт?

Разумеется.

 >>> Подавляющее большинство embedded процессоров сугубо ортогональны к
 >>> методикам генерации машинного кода. А Форт реализует методику, отличную от
 >>> Си, и закрывать на это глаза - бессмысленно.

 >  DO> Бессмысленно его использовать для чего-то кроме под него сделанных
 >  DO> процессоров (типа того же marc4), а их использование, в свою очередь,
 >  DO> тоже должно иметь веские основания.

 > У меня есть и процессоры, и веские основания. Что дальше?

Hичего. Если я правильно тебя понял в соседнем письме, то этот таинственный
процессор (Hitachi SH4) - 32хразрядный 200 мегагерцовый RISC для которого
нормальные люди используют gcc и на который ставят linux. Если ты системы с
такими ресурсами на форте программируешь, иначе как диверсию мне это
рассматривать ну очень трудно.

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


_Loader_
Wed Oct 08 2003 20:42, Dima Orlov wrote to Ilia Tarasov:

 >> ... и кого волнуют проблемы негров? ;)

 DO> Когда производителей не волнуют проблемы пользователей, без работы
 DO> остаются производители.

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

 DO> Потому что форт их убогий из их поделий как ослиные уши вечно торчит.

Ругань...

 >> Я ни в одной разработке не замечал, что Форт существенно уступает

 DO> Да мало ли чего ты там в своих разработках не замечал?

Наезд?

 >> Си. Твои наблюдения ни о чем не говорят.

 DO> Твои тоже.

К сожалению для тебя, мои - говорят...

 >> А тогда зачем поддерживаешь флейм? Hе согласен - либо аргументированно

 DO> А ты зачем?  И где твои аргументированные доказательства?

Аргументированные доказательства чего? Рулезности Форта? Не приписывай мне
свойств "обобщенного форррртера". Свойств вычислительной модели стековой
машины? Иди читай классику - Кнута и Dragon Book. Пока что аргументы оттуда
тебе непонятны...

 DO> Он не только не нужен, он вреден.

Не тебе судить. Заметь, я про Си ничего не говорю.

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

 DO> А ты не пытаешься?

Нет, не пытаюсь. Покажи мои письма, где я _указывал_, что _надо_ пользоваться
Фортом взамен Си.

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

 DO> Сумме чего?

Денег.

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

 DO> Какого еще конструктора, что ты несешь? EWB обычно очень простая и потому

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

 >> Другие должны владеть (Фортом), без этого никуда, какой язык в

 DO> Это им не поможет. Они должны не только фортом владеть, но еще и
 DO> разгрести все те нагромождения, которые первый наопределял.

Аналогично для любого языка.

 >> А ты специально пропускаешь в моих сообщениях упоминания о спецсистемах?
 >> :))

 DO> Специально, потому что изначально о них никто не говорил.

Я сказал. Я отвечаю за свои слова и утверждения, а не за чьи-то еще.

 DO> Гораздо эффективнее не допускать вообще форт.

Чем конкретно подкреплено твое заявление? Обладаешь ли ты правами и
возможностью определять техническую политику своей организации?

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

 DO> Hе будет толка.

"Стрижено-брито"...

 >> Ты опять применяешь ко мне свои представления о ходе отладки. Есть
 >> там консоль - COM в обе стороны...

 DO> Где "там"? В каких-то твоих сферических системах копеечной стоимости?

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

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

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

 DO> Hет конечно, как и в форт-программе ему взятся неоткуда, когда она зашита
 DO> в ПЗУ и работает в реальном времени.

Я только что написал, что эта строка появляется в результате интерпретации
входного потока, приходящего через отладочный COM. Если ты этого понимать не
хочешь, развожу руками.

 DO> В ПЗУ находится _все_, у контроллера есть ПЗУ и несколько сот регистров
 DO> ОЗУ.

Банальное утверждение.

 >> интерпретатор, который разбирает строку, полученную из COM.

 DO> Чего ему там делать-то?

Разбирать строку, полученную из COM

 >> В процессе разбора в произвольном
 >> (задаваемом во введенной строке) порядке вызываются слова из

 DO> А словарю чего делать в ПЗУ?

Обеспечивать идентификацию слов. Тормозишь? Или закусил удила?

 >> словаря, если они там есть. Поскольку переменнные там явно есть,

 DO> Переменные в ОЗУ и SFR'ах контроллера.

И что? А где, по-твоему, мнемонические обозначения этих переменных?

 >> и есть слово, посылающее их значение в COM,

 DO> Зачем там нужны лишние слова?

Послать байт в COM - лишнее слово?

 DO> И что оно пошлет? Значения переменных нужны в точке останова. Собственно
 DO> часто и не нужны, достаточно бывает понять попало управление в нужную
 DO> точку или нет.
 DO> Порставить брейкпойнт в тексте и запустить программу в _реальном
 DO> времени_, после остановки посмотреть значения переменных и SFR'ов - вот
 DO> что позволяет эмулятор и вот для чего нужна отладочная информация
 DO> (которая естественно в самой отлаживаемой программе не присутствует и на
 DO> вывод которой в ней ресурсов не предусмотрено).

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

 >> Обрати внимание, что в ПЗУ именно такой строки нигде нет, подается
 >> по шнурку.

 DO> Программа исполняемая тоже по шнурку?

Ты структуру Форт-машины знаешь? Вот в соответствии со структурой она и
исполняется - из ПЗУ, после интерпретации входного потока или наступления
событий, привязанных к словам.

 >> Это не есть возможность просмотра состояния памяти, а заодно и
 >> запуска любого слова с любыми параметрами?

 DO> Hет конечно. И зачем запускать слова с параметрами?

Опять удила закушены... У твоих функций нет аргументов? А почему аргументы не
должны быть у слов Форта?

 >> См. выше. Hе понимаю, чем плоха возможность запускать слово штатными
 >> средствами уже работающей системы, по сравнению с расстановкой
 >> breakpoints в готовом коде...

 DO> Охотно верю в то, что ты этого не понимаешь.

Наезд?

 >> А посмотри-ка ты Dragon Book, а? Прежде чем ляпать такое....

 DO> Чего мне туда смотреть?

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

 >> Hапример, что такое раскрутка компиляторов, и вокруг этого.

 DO> Зачем мне крутить компиляторы? У меня есть готовые.

Это пять!!!! :))))))))) Это надо переслать кое-кому...

 >> Я тебе памятник поставлю, если
 >> ты мне докажешь, что целевой код зависит от языка, на котором
 >> написан кросс-компилятор....

 DO> Зачем мне какой-то явный бред доказывать?

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

 >> Как ты думаешь, чем я вообще занимаюсь, и зачем? Я, видишь ли,

 DO> Понятия не имею.

А я вот озаботился из писем узнать, что ты работаешь в Израиле и получаешь
зарплату в тысячах долларов. А среди разработок преобладают PIC и AVR на Си +
асм. Соответственно я с тобой и разговариваю, причем, как видишь, не указываю
на то, что при твоей-то работе тебе бы помалкивать и продолжать решать свои
задачи за свою зарплату.

 >> именно за полчаса проектировал и заодно осваивал процессорные ядра в ПЛИС
 >> по  общим требованиям.

 DO> Могу себе представить этия ядра...

Наезд? Или хамство? Молодой человек, ВАС НЕ СПРАШИВАЮТ! Мне абсолютно
наплевать на твое мнение, но эху все же люди читают, и незачем им видеть, как
один стиль проектирования абсолютизируется.

 DO> Вот по этому соотношению AVR и пролетает, да и вообще все кроме PIC'ов
 DO> пролетает в моих задачах.

Тем более. Тебе русским языком было сказано, для чего нужен Форт. Что касается
PIC-ов, то _Я_ тебе могу формально доказать, что Форт на PIC-е МЕНЕЕ
эффективен, чем Си. Соответственно, пока не начнешь обсуждать другие задачи, я
с тобой продолжать ругань не намерен.

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

 DO> Чего я не хочу понимать?

А вот там выше я оставил цитату, чего ты не хочешь понимать. Прямо со слов
"ассемблеры всех процессоров..." и далее по тексту.

 >> Твое право. Только при принятии решения я твоим мнением руководствоваться
 >> никак не буду. В итоге я пишу и на связке Си+асм, и на Форте, а ты

 DO> А я не буду твоим, и другим не буду рекомендовать.

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

 DO> Практика. Подтвержденная количеством написанного на С по сравнению с
 DO> фортом.

А кто-то спорит с количеством? Я тебе в сотый раз толкую о _наличии_
регистровой архитектуры и _методиках_ работы с Фортом. Ты начинаешь вопить,
что это все чушь... Ну-ну...

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

 DO> Hе хочу, не умею и даже не хочу уметь. Я на жизнь зарабатываю другим, в
 DO> частности эхотагом, к которому написание компиляторов никакого отношения
 DO> не имеет. А если embedded инженер пишет компиляторы, то 99% что он и
 DO> инженер плохой и компиляторы у него ни к черту

Видишь ли, я не embedded инженер... я главный инженер ;) А еще я тут
докторскую дописываю в близкой к эхотагу области, и вот только сегодня днем
мне из Интела звонили по поводу моих работ ;))) Ты извини, конечно, я держался
сколько мог, но как бы разницу чувствуешь? Твои мнения так и остаются твоими
мнениями, а мои мнения - это техническая политика моего предприятия и научных
работ кафедры, на которой я преподаю. Расслабься...

(Кстати, диверсия - это не когда Форт используют. Это когда израильский
инженер учит российского ученого)

 >> компилятора тебе закрыт?

 DO> Разумеется.

Fixed. Поэтому кушай что дают... Дали Си - пиши на Си...

 >> У меня есть и процессоры, и веские основания. Что дальше?

 DO> Hичего. Если я правильно тебя понял в соседнем письме, то этот
 DO> таинственный процессор (Hitachi SH4) - 32хразрядный 200 мегагерцовый RISC
 DO> для которого нормальные люди используют gcc и на который ставят linux.
 DO> Если ты системы с такими ресурсами на форте программируешь, иначе как
 DO> диверсию мне это рассматривать ну очень трудно.

Нет, ты неправильно понял. У нас обычно до десятка проектов с разными
процессорами и для разных задач. Я если что и программирую, то новые
разработки, в которых проверяю новую математику. Для Си есть соответствующие
сотрудники, которые пока ничего больше не знают. В SH4 используется
кросс-ассемблер, а не Форт.


Re: _Loader_
Hi Ilia!

В субботу, 11 октябpя 2003 22:17:26, Ilia Tarasov писал to Vadim Rumyantsev:

 IT> Да я и сам несколько удивился ситуации. Вообще-то "академики" - Черток
 IT> и Ишлинский, в прошлом замы Королева...

Так бы сразу и сказал :)

                                                                Sincerely,
                                                                       Vadim.

_Loader_
Wed Oct 08 2003 20:42, Dima Orlov wrote to Ilia Tarasov:

 >> ... и кого волнуют проблемы негров? ;)

 DO> Когда производителей не волнуют проблемы пользователей, без работы
 DO> остаются производители.

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

 DO> Потому что форт их убогий из их поделий как ослиные уши вечно торчит.

Ругань...

 >> Я ни в одной разработке не замечал, что Форт существенно уступает

 DO> Да мало ли чего ты там в своих разработках не замечал?

Наезд?

 >> Си. Твои наблюдения ни о чем не говорят.

 DO> Твои тоже.

К сожалению для тебя, мои - говорят...

 >> А тогда зачем поддерживаешь флейм? Hе согласен - либо аргументированно

 DO> А ты зачем?  И где твои аргументированные доказательства?

Аргументированные доказательства чего? Рулезности Форта? Не приписывай мне
свойств "обобщенного форррртера". Свойств вычислительной модели стековой
машины? Иди читай классику - Кнута и Dragon Book. Пока что аргументы оттуда
тебе непонятны...

 DO> Он не только не нужен, он вреден.

Не тебе судить. Заметь, я про Си ничего не говорю.

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

 DO> А ты не пытаешься?

Нет, не пытаюсь. Покажи мои письма, где я _указывал_, что _надо_ пользоваться
Фортом взамен Си.

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

 DO> Сумме чего?

Денег.

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

 DO> Какого еще конструктора, что ты несешь? EWB обычно очень простая и потому

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

 >> Другие должны владеть (Фортом), без этого никуда, какой язык в

 DO> Это им не поможет. Они должны не только фортом владеть, но еще и
 DO> разгрести все те нагромождения, которые первый наопределял.

Аналогично для любого языка.

 >> А ты специально пропускаешь в моих сообщениях упоминания о спецсистемах?
 >> :))

 DO> Специально, потому что изначально о них никто не говорил.

Я сказал. Я отвечаю за свои слова и утверждения, а не за чьи-то еще.

 DO> Гораздо эффективнее не допускать вообще форт.

Чем конкретно подкреплено твое заявление? Обладаешь ли ты правами и
возможностью определять техническую политику своей организации?

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

 DO> Hе будет толка.

"Стрижено-брито"...

 >> Ты опять применяешь ко мне свои представления о ходе отладки. Есть
 >> там консоль - COM в обе стороны...

 DO> Где "там"? В каких-то твоих сферических системах копеечной стоимости?

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

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

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

 DO> Hет конечно, как и в форт-программе ему взятся неоткуда, когда она зашита
 DO> в ПЗУ и работает в реальном времени.

Я только что написал, что эта строка появляется в результате интерпретации
входного потока, приходящего через отладочный COM. Если ты этого понимать не
хочешь, развожу руками.

 DO> В ПЗУ находится _все_, у контроллера есть ПЗУ и несколько сот регистров
 DO> ОЗУ.

Банальное утверждение.

 >> интерпретатор, который разбирает строку, полученную из COM.

 DO> Чего ему там делать-то?

Разбирать строку, полученную из COM

 >> В процессе разбора в произвольном
 >> (задаваемом во введенной строке) порядке вызываются слова из

 DO> А словарю чего делать в ПЗУ?

Обеспечивать идентификацию слов. Тормозишь? Или закусил удила?

 >> словаря, если они там есть. Поскольку переменнные там явно есть,

 DO> Переменные в ОЗУ и SFR'ах контроллера.

И что? А где, по-твоему, мнемонические обозначения этих переменных?

 >> и есть слово, посылающее их значение в COM,

 DO> Зачем там нужны лишние слова?

Послать байт в COM - лишнее слово?

 DO> И что оно пошлет? Значения переменных нужны в точке останова. Собственно
 DO> часто и не нужны, достаточно бывает понять попало управление в нужную
 DO> точку или нет.
 DO> Порставить брейкпойнт в тексте и запустить программу в _реальном
 DO> времени_, после остановки посмотреть значения переменных и SFR'ов - вот
 DO> что позволяет эмулятор и вот для чего нужна отладочная информация
 DO> (которая естественно в самой отлаживаемой программе не присутствует и на
 DO> вывод которой в ней ресурсов не предусмотрено).

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

 >> Обрати внимание, что в ПЗУ именно такой строки нигде нет, подается
 >> по шнурку.

 DO> Программа исполняемая тоже по шнурку?

Ты структуру Форт-машины знаешь? Вот в соответствии со структурой она и
исполняется - из ПЗУ, после интерпретации входного потока или наступления
событий, привязанных к словам.

 >> Это не есть возможность просмотра состояния памяти, а заодно и
 >> запуска любого слова с любыми параметрами?

 DO> Hет конечно. И зачем запускать слова с параметрами?

Опять удила закушены... У твоих функций нет аргументов? А почему аргументы не
должны быть у слов Форта?

 >> См. выше. Hе понимаю, чем плоха возможность запускать слово штатными
 >> средствами уже работающей системы, по сравнению с расстановкой
 >> breakpoints в готовом коде...

 DO> Охотно верю в то, что ты этого не понимаешь.

Наезд?

 >> А посмотри-ка ты Dragon Book, а? Прежде чем ляпать такое....

 DO> Чего мне туда смотреть?

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

 >> Hапример, что такое раскрутка компиляторов, и вокруг этого.

 DO> Зачем мне крутить компиляторы? У меня есть готовые.

Это пять!!!! :))))))))) Это надо переслать кое-кому...

 >> Я тебе памятник поставлю, если
 >> ты мне докажешь, что целевой код зависит от языка, на котором
 >> написан кросс-компилятор....

 DO> Зачем мне какой-то явный бред доказывать?

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

 >> Как ты думаешь, чем я вообще занимаюсь, и зачем? Я, видишь ли,

 DO> Понятия не имею.

А я вот озаботился из писем узнать, что ты работаешь в Израиле и получаешь
зарплату в тысячах долларов. А среди разработок преобладают PIC и AVR на Си +
асм. Соответственно я с тобой и разговариваю, причем, как видишь, не указываю
на то, что при твоей-то работе тебе бы помалкивать и продолжать решать свои
задачи за свою зарплату.

 >> именно за полчаса проектировал и заодно осваивал процессорные ядра в ПЛИС
 >> по  общим требованиям.

 DO> Могу себе представить этия ядра...

Наезд? Или хамство? Молодой человек, ВАС НЕ СПРАШИВАЮТ! Мне абсолютно
наплевать на твое мнение, но эху все же люди читают, и незачем им видеть, как
один стиль проектирования абсолютизируется.

 DO> Вот по этому соотношению AVR и пролетает, да и вообще все кроме PIC'ов
 DO> пролетает в моих задачах.

Тем более. Тебе русским языком было сказано, для чего нужен Форт. Что касается
PIC-ов, то _Я_ тебе могу формально доказать, что Форт на PIC-е МЕНЕЕ
эффективен, чем Си. Соответственно, пока не начнешь обсуждать другие задачи, я
с тобой продолжать ругань не намерен.

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

 DO> Чего я не хочу понимать?

А вот там выше я оставил цитату, чего ты не хочешь понимать. Прямо со слов
"ассемблеры всех процессоров..." и далее по тексту.

 >> Твое право. Только при принятии решения я твоим мнением руководствоваться
 >> никак не буду. В итоге я пишу и на связке Си+асм, и на Форте, а ты

 DO> А я не буду твоим, и другим не буду рекомендовать.

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

 DO> Практика. Подтвержденная количеством написанного на С по сравнению с
 DO> фортом.

А кто-то спорит с количеством? Я тебе в сотый раз толкую о _наличии_
регистровой архитектуры и _методиках_ работы с Фортом. Ты начинаешь вопить,
что это все чушь... Ну-ну...

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

 DO> Hе хочу, не умею и даже не хочу уметь. Я на жизнь зарабатываю другим, в
 DO> частности эхотагом, к которому написание компиляторов никакого отношения
 DO> не имеет. А если embedded инженер пишет компиляторы, то 99% что он и
 DO> инженер плохой и компиляторы у него ни к черту

Видишь ли, я не embedded инженер... я главный инженер ;) А еще я тут
докторскую дописываю в близкой к эхотагу области, и вот только сегодня днем
мне из Интела звонили по поводу моих работ ;))) Ты извини, конечно, я держался
сколько мог, но как бы разницу чувствуешь? Твои мнения так и остаются твоими
мнениями, а мои мнения - это техническая политика моего предприятия и научных
работ кафедры, на которой я преподаю. Расслабься...

(Кстати, диверсия - это не когда Форт используют. Это когда израильский
инженер учит российского ученого)

 >> компилятора тебе закрыт?

 DO> Разумеется.

Fixed. Поэтому кушай что дают... Дали Си - пиши на Си...

 >> У меня есть и процессоры, и веские основания. Что дальше?

 DO> Hичего. Если я правильно тебя понял в соседнем письме, то этот
 DO> таинственный процессор (Hitachi SH4) - 32хразрядный 200 мегагерцовый RISC
 DO> для которого нормальные люди используют gcc и на который ставят linux.
 DO> Если ты системы с такими ресурсами на форте программируешь, иначе как
 DO> диверсию мне это рассматривать ну очень трудно.

Нет, ты неправильно понял. У нас обычно до десятка проектов с разными
процессорами и для разных задач. Я если что и программирую, то новые
разработки, в которых проверяю новую математику. Для Си есть соответствующие
сотрудники, которые пока ничего больше не знают. В SH4 используется
кросс-ассемблер, а не Форт.


Re: _Loader_
Hello, Artem!

AK>> Именно. Ты эмулятоpов (не только для PIC'ов) в глаза не видел, в лучшем
AK> случае
AK>> на каpтинке.
AK>
AK> Хм... Попpобуй тут не увидеть, когда почти каждая фиpма тоpгующая МК
AK> пытается тебе его всунуть ;).

А купить и использовать - такая идея не пpиходила в голову?



Best regards,  // Садись, pасслабься и их тpупы
Yurij.         // пpоплывут мимо тебя по pеке. :) (c) DVK

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

Quoted text here. Click to load it

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

Изменение порогов входных буферов для различных процессоров (разница где-то
до 0,7 вольта).
Паразитная утечка на аналоговые входы АЦП при превышении напряжения питания
на цифровых ногах процессора
Не качественная схема и разводка по цепям питания (устойчивость к импульсным
помехам)

Кроме того, основная часть изменений проходит во время испытаний на
автомобилях, а там эмулятор просто не допустим.

                                 АртемКАД



_Loader_
Thu Oct 09 2003 01:00, Ilia Tarasov wrote to Dima Orlov:

 >>> именно за полчаса проектировал и заодно осваивал процессорные ядра в ПЛИС
 >>> по  общим требованиям.

 DO>> Могу себе представить этия ядра...

 IT> Hаезд? Или хамство?

Констатация факта.

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

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

 DO>> А если embedded инженер пишет компиляторы, то 99% что он и
 DO>> инженер плохой и компиляторы у него ни к черту

 IT> Видишь ли, я не embedded инженер... я главный инженер ;)

Это достоинство или недостаток? :)

 IT> А еще я тут
 IT> докторскую дописываю в близкой к эхотагу области, и вот только сегодня
 IT> днем мне из Интела звонили по поводу моих работ ;))) Ты извини, конечно,
 IT> я держался сколько мог, но как бы разницу чувствуешь? Твои мнения так и
 IT> остаются твоими мнениями, а мои мнения - это техническая политика моего
 IT> предприятия и научных работ кафедры, на которой я преподаю. Расслабься...

Hеубедительно. У меня года три назад была презабавнейшая дискуссия с
человеком, даже обучавшим студентов где-то в Москве, который "нашел ошибку"
в Max+Plus II и даже опубликовал это в Chip News...
Он, кстати, так и не понял всю глубину своего непонимания.

 >>> У меня есть и процессоры, и веские основания. Что дальше?

 DO>> Hичего. Если я правильно тебя понял в соседнем письме, то этот
 DO>> таинственный процессор (Hitachi SH4) - 32хразрядный 200 мегагерцовый
 DO>> RISC  для которого нормальные люди используют gcc и на который ставят
 DO>> linux.  Если ты системы с такими ресурсами на форте программируешь,
 DO>> иначе как  диверсию мне это рассматривать ну очень трудно.

 IT> Hет, ты неправильно понял. У нас обычно до десятка проектов с разными
 IT> процессорами и для разных задач.

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

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

SH-4 на ассемблере???? Мама роднАя...

WBR, Юрий.


_Loader_
Привет Yuriy!

Thursday October 09 2003 22:52, Yuriy K wrote to Ilia Tarasov:

 IT>> Hет, ты неправильно понял. У нас обычно до десятка проектов с разными
 IT>> процессорами и для разных задач.
 YK>
 YK> Ужас какой. Зачем такое разнообразие нужно, тем более для единичных
 YK> задач. где себестоимость процессора никого не волнует.

Так им важен не результат а "сам процесс".

 IT>> Я если что и программирую, то новые
 IT>> разработки, в которых проверяю новую математику. Для Си есть
 IT>> соответствующие сотрудники, которые пока ничего больше не знают. В
 IT>> SH4 используется кросс-ассемблер, а не Форт.
 YK>
 YK> SH-4 на ассемблере???? Мама роднАя...

Hе мешай людям наукой заниматься! конечный результат их не интересует, он им
просто не нужен.


    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



_Loader_
Fri Oct 10 2003 00:27, Alexander Torres wrote to Yuriy K:

 IT>>> Я если что и программирую, то новые
 IT>>> разработки, в которых проверяю новую математику. Для Си есть
 IT>>> соответствующие сотрудники, которые пока ничего больше не знают. В
 IT>>> SH4 используется кросс-ассемблер, а не Форт.
 YK>>
 YK>> SH-4 на ассемблере???? Мама роднАя...

 AT> Hе мешай людям наукой заниматься! конечный результат их не интересует, он
 AT> им просто не нужен.

Да мне не жалко, я просто имею представление об ассемблере SH-1.
Это вам не на AVR писать. И не на x51. И даже не на х86.

Hапример загрузка константы в регистр делается так:

        !---------- set up WCR1 ----------

                mov.l   wcr1_addr,r0    
! записать в r0 32bit содержимого памяти по адресу wcr1_addr

                mov.w   wcr1_value,r1
! записать в r0 16bit содержимого памяти по адресу wcr1_value

                mov.w   r1,@r0
! собственно инициализация регистра периферии.

                .align  4

wcr1_addr:      .long   BSC_WCR1_ADDR   ! 0x5FFFFA2
wcr1_value:     .word   0x8A00          ! 1000 1010 0000 0000  see p. 99 :


Программисты на ассемблере просто пищат от восторга...

WBR, Юрий.


RE:_Loader_
Hello, Yuriy!

IT>>> SH4 используется кpосс-ассемблеp, а не Фоpт.

YK>> SH-4 на ассемблеpе???? Мама pоднАя...

AT> Hе мешай людям наукой заниматься! конечный pезультат их не
AT> интеpесует, он  им пpосто не нужен.
YK>
YK> Да мне не жалко, я пpосто имею пpедставление об ассемблеpе SH-1.
YK> Это вам не на AVR писать. И не на x51. И даже не на х86.
YK>
YK> Hапpимеp загpузка константы в pегистp делается так:
YK>
YK>         !---------- set up WCR1 ----------
YK>
YK>                 mov.l   wcr1_addr,r0    
YK> ! записать в r0 32bit содеpжимого памяти по адpесу wcr1_addr

[...]

Чего-то тут не того... SH-4 - не тpебует манипуляций с пеpифеpией (поpтами)
для опеpаций с памятью. Или я в чем-то ошибаюсь.




Best regards,  //   Совесть - неотъемлемый компонент
Yurij.         //          знаний и опыта.

Site Timeline