_Loader_

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

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

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

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

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

И они в чем то правы. Шитый код был давно. Потом пришел форт и другие языки и методы и шитый код как объектный код стал уходить. В наше время когда возникает идея о шитом коде она как правило базируется на Форте - как наиболее продвинутом в данном направлении.

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

Аркадий

Thu Oct 09 2003 03:52, Power User wrote to Alex Kouznetsov: ... AK>> То есть, "самопал на асме", скорей всего, будет "большой каракатицей" и AK>> "кривым угробищем".

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

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

AK>> Тогда как знание Форта _позволит_ тебе сделать этот AK>> код компактным и эффективным,

PU> И дуракойстойчивым при этом?Т.е.заливка разной дряни в качестве апдейта PU> не переклинит нашу железку?Hо ведь если call и т.п. делает процессор в PU> виде нативного кода,то заливаем мы тогда все же нативный код и подсунув PU> процу в этом месте что-нибудь левое (правильный "зависатор"?) можно PU> все же получить зависон,или я что-то пропустил?

У тебя есть несколько возможностей.

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

-- Ставишь на систему интерпретатор, в котором нет команд, способных "заклинить" систему. Чтобы получить приличную скорость исполнения, используешь подпрограммный шитый код. Исходник своей аппликухи пишешь на каком-то языке (какой сделаешь, или какой найдешь) и компилируешь в байт-код для этого интерпретатора. Байт-код состоит при этом состоит из нативных команд call <имя_подпрограммы>. Числа на вершину стека кладет, например, подпрограмма <литерал>, которая третирует следующий байт-код как число. То есть, байт-код после компиляции выглядит примерно так: call <команда_интерпретатора>

call <команда_интерпретатора>

call <литерал>

<число>

call <команда_интерпретатора>

... и т.д. Главную опасность зависания создают именно эти числа, т.е. если порядок нарушить и записать в память код call <литерал>

<число> <число>

то первое число будет "съедено" литеральным оператором , а вот второе число интерпретатор попытается исполнить как нативную команду. Однако, гарантией что такого беспорядка в твоем коде не встретится, является компилятор. Поскольку правильный компилятор не можед сгенерировать такой байт-код, а два литерала обязан скомпилировать как call <литерал>

<число>

call <литерал>

<число>

То есть, в этом случае от твоего внимания уже не так много зависит, компилятор не выдаст опасных последовательностей байт-кода, а интерпретатор не зависнет на безопасных. Замечу, что вместо call <литерал>

<число>

компилятор имеет полное право генерить нативный код типа ldа <число>

mov A,<куда_надо>

эти команды тоже "безопасные", а выполнятся быстрее чем вызов подпрограммы литерала

Это не все возможные варианты, а пища для размышлений ;-)

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