_Loader_

Mon Oct 06 2003 22:47, Dima Orlov wrote to Ilia Tarasov:

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

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

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

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

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

Я ни в одной разработке не замечал, что Форт существенно уступает Си. Твои наблюдения ни о чем не говорят.

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

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

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

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

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

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

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

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

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

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

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

И зачем, по-твоему, Форт вообще нужен здесь? Весь инструментарий в одном приложении.

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

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

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

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

- COM в обе стороны...

DO> Hу-ну.

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

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

Итак. В ПЗУ находится Форт (со словарными статьями). Работает интерпретатор, который разбирает строку, полученную из COM. В процессе разбора в произвольном (задаваемом во введенной строке) порядке вызываются слова из словаря, если они там есть. Поскольку переменнные там явно есть, и есть слово, посылающее их значение в COM, не составляет труда подать на интерпретатор строку вида

MY_VAR @ ->COM

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

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

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

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

А посмотри-ка ты Dragon Book, а? Прежде чем ляпать такое.... Например, что такое раскрутка компиляторов, и вокруг этого. Я тебе памятник поставлю, если ты мне докажешь, что целевой код зависит от языка, на котором написан кросс-компилятор....

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

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

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

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

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

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

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

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

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

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

Tue Oct 07 2003 03:51, Yuriy K wrote to Ilia Tarasov:

YK>>> Это альтруизм или хобби?

IT>> Это исследовательская работа.

YK> Значит она кем-то оплачивается.

Пока нет - из внутренних резервов.

YK>>> Разговор идет о коммерческих применениях.

IT>> ...которая позволит сформулировать ТЗ для HИОКР... что не так?

YK> Что слова "деньги не вернутся" ошибочны.

Тогда давай смотреть, когда они вернутся. Если в ходе разработки выяснится, что требования к процессору много выше, чем в состоянии обеспечить имеющийся кристалл, то в готовом приборе его и не будет. Покрыть расходы способна только продажа первой партии приборов, до которой достаточно далеко. К этому времени накопится приличное количество затрат на комплектующие, материалы и оборудование, которые в явном виде в изделии использованы не будут. Это получается особый шик - покупать все подряд, в надежде, что пригодится? Надо мной, btw, нет такого начальства, перед которым имеет смысл "отмазываться" в стиле: "вот - сижу, ничего не делаю, жду EK с компилятором..."

IT>>>> Процессор явно embedded,

YK> Кстати, какой?

Hitachi SH4

IT>> И я вот так распорядился временем и деньгами... этого делать было IT>> нельзя?

YK> Можно, но неэффективно даже при российских зарплатах.

И если для меня получается эффективно, то это мои галлюцинации?

IT>> Эхотаг - это исключительно изготовление плат с PIC-ами и AVR-ами?

YK> Тут уже было долгое обсуждение. Я согласен с определением Димы Орлова.

Тем не менее на мой вопрос ответа нет. Я не буду вдаваться в тонкости состоявшегося обсуждения... но все же: если процессор по характеристикам находится в ином классе, нежели PIC/AVR, эхотажно ли обсуждение методик проектирования систем на нем? Если для организации ПО использована иная вычислительная модель, нежели предлагаемая Си - эхотажно ли такое устройство? Наконец, эхотажно ли обсуждение решений вопроса "а что делать, если ни ассемблер, ни Си не устраивают"?

YK> Я не возражаю, когда люди тратят свое время и деньги неэффективно. YK> Это не мое время и не мои деньги, мне чужого не жалко. :)

YK> Я возражаю против того, что такой подход хорош и правилен.

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

Tue Oct 07 2003 08:03, Vadim Rumyantsev wrote to Ilia Tarasov:

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

IT>> (Кстати, а чем контрольная сумма плоха? И прочие методы контроля за IT>> передаваемой информацией? Эхо там, мажорирование...)

VR> Hе ты ли двумя строчками выше писал об отсутствии дополнительного VR> протокола?

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

Tue Oct 07 2003 12:04, Dmitry Orlov wrote to Artem Kamburov:

DO> Ага, за полчаса...

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

Wed Oct 08 2003 13:36, Dmitry Orlov wrote to Alexey Boyko:

DO> А ему и не нужно влазить в MC, в MC - только интерпретатор байт-кода, а DO> сам язык в PC.

Не надо путать синтаксис и семантику базового словаря Форта с синтаксисом и семантикой высокоуровневых слов

DO> Это бОльшая его часть.

1) Лексический анализатор 2) Синтаксический анализатор 3) Семантический анализатор 4) Генератор промежуточного кода 5) Система оптимизации 6) Генератор выполняемого кода.

Какова функциональность парсера по приведенной классификации?

DO> Именно.

DO> Да во что угодно, что удобней. Очевидно, что для таких задач DO> производительность дело двадцать пятое. Главное, чтобы пользователю было DO> удобно этим пользоваться.

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

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> Форта и некоторые другие мелочи)

Может быть, тоже сходишь на

? :) Такое уже стоит в готовом изделии.

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

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> Думайте, оно всегда полезно :)

А то! :)

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

RK>>> За счет чего оно проще? Пока был упомянут только дешифратор RK>>> команды - это не настолько сложная часть процессора, что бы его RK>>> упрощение сделало процессор в целом ощутимо проще.

IT>> За счет того, что это ASIC - Application-Specific Integral Circuit.

RK> Ты не понял - за счет чего стековый процессор будет проще не стекового?

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

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

RK> Это не есть 'распараллелить', это есть 'распараллелил компилятор'.

Ну все же H.Corporaal, а? Я уже ссылку кидал, могу и саму статью кинуть в почту, она небольшая. Там есть четкая классификация процессорных архитектур по тому, какие действия по обработке команд выполняет компилятор, а какие - процессор.

IT>> А какая мне в данном случае разница? :))

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

По задаче требовалась именно синхронная работа 4-х блоков...

IT>> Кстати, могу сослаться на TIGRE - это такая система редукции графов IT>> (GRE = Graph REduction), которая дает вполне хорошие результаты для IT>> стековых машин.

RK> И что, она позволит на ходу свести 1 поток команд к 4м независимым RK> потокам, да еще будет исполненна в железе? Что то не верится.

Не знаю. Это не схемотехническое решение, это именно "система редукции графов". Смотря какие графы... И в железе она не исполняется, это теоретическая модель, позволяющая упрощать алгоритмы под стековую машину.

Всем привет.

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

АртемКАД

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

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

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

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

Ругань...

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

Наезд?

DO> Твои тоже.

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

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

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

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

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

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

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

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

Денег.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наезд?

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

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

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 используется кросс-ассемблер, а не Форт.