_Loader_

12-Oct-03 19:21 Vladimir Vassilevsky wrote to Vladislav Baliasov:

VV>>> Есть еще одно преимущество: намного приятнее выбирать соответствующие VV>>> галочки в GUI

VB>> Спорно.

VV> Hеудобно разбираться с произвольно сокращенными именами фьюзов. Все Гримасы доса, длинные имена fuse удлинняют командную строку до неприличия.

VV> имена должны быть полными и точно такими, как в даташите. В принципе, могу для win32/linux сделать синонимы "как в даташите".

VV> При этом задание VV> опций через командную строку становится непрактичным - лучше бы читать VV> их из текстового *.cfg файла. Это на очереди в виде avreal @file_with_options или что-то в этом духе.

VV> Еще одна проблема (правда, не с авреалом, а с фьюзами вообще): VV> Для несведущего человека совершенно очевидно, что ON == 1, OFF == 0. VV> По этой причине как-то пришлось перешивать партию в 1000 устройств. VV> Искоренить все нули и единицы чтобы не возникало подобных ошибок.

С какого-то момента (когда валом пошли слёзы по поводу галочек в пони-проге) я добавил ON/OFF. 0/1 остались для совместимости со старыми версиями. Могу убрать, если трудящиеся требуют.

wbr,

12-Oct-03 20:05 Igor Ulanov wrote to Vladimir Vassilevsky:

IU> Может и спpаведливо, но мне не кажется эта пpоблема стоящей pазговоpа. IU> К IU> сожалению y меня нет под pyкой авpеала, но насколько я помню если в нем IU> и IU> сокpащенны названия фьюзов, то это сделано настолько yдобно и понятно, И в любой момент можно сказать avreal +device -h и получить список оных для данного device с краткой расшифровкой и диапазоном значений.

IU> А я также напоpолся на IU> этy пpоблемy в ПониПpоге, так как пpостота гyя пpедpасполагает к игноpиpованию IU> чтения pидми и хелпов, а выставленный флажок я посчитал запpогpаммиpованым IU> фьюзем.

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

wbr,

12-Oct-03 11:43 Alexey Boyko wrote to Ilia Tarasov:

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

wbr,

12-Oct-03 14:51 Artem Kamburov wrote to Oleksandr Redchuk:

AK> Не совсем. В AVR-ах, где это возможно, в ОЗУ размещаю только стек. Это всё ("компилированный стек") я имел ввиду для кристаллов без ОЗУ вообще.

AK> Хватит, только терминала обычто нет. А откуда тогда брать определения новых слов и как использовать "преимущества при отладке"?

AK> Возможно. Но на Форте твоя задача никем не решалась :). Я не про свои, я про работу с AVR-ками без ОЗУ. Для которых на C в принципе можно писать и может даже быть удобнее, чем на асме (раскладка компилятором оверлеев данных по ОЗУ).

Wbr,

12-Oct-03 14:52 Artem Kamburov wrote to Oleksandr Redchuk:

AK> Можно передать программирование полному юзеру :).

Нельзя. Обязательно возьмёт какой-то не тот файл чрезе диалог выбора файла или умудрится задеть del на файле, а потом не читая текст на возникшем диалоге -- нажмёт OK.

Полному юзеру надо на десктоп вытаскивать иконки "зашить изделие номер2", у которых прописывать путь к батнику. А ещё лучше сделать автономный программатор, в который заливать прошивку из PC и вручать "полным юзерам" на сборке. К компу таких лучше не подпускать вообще.

wbr,

Mon Oct 13 2003 22:16, Roman Khvatov wrote to Ilia Tarasov:

IT>> О чем говорит JC или JNZ?

RK> О наличии в АЛУ таких флагов :)

Где эти флаги в Си как элементы языка?

IT>> Покажи мне ту конструкцию Си, которая в явном виде устанавливает флаг IT>> нуля.

RK> a==b

Где установка флага нуля? CMP установит _все_ флаги, это side effect...

IT>> А чем плохо JA_EQ_B (переход, если AX = BX)?

RK> Это объединение 2х конструкций - операции вычитания (в АЛУ) и условного RK> перехода.

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

IT>> Это разве не более короткая версия перехода, прекрасно ложащаяся IT>> на Си?

RK> Hа C - да, на процессор - хуже.

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

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

IT>> Даже в этой эхе найдутся те, кто еще не забыл.

RK> О! В этой эхе их навалом :) Мне кажется у них тут заповедник ;-)

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

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

RK> И тем не менее - есть очень отчетливая тенденция к переходу от ассемблера RK> к ЯВУ.

Тенденций есть много, и они разные. За всех говорить не стоит.

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

RK> Оно уже появилось, теперь отмирает :)

Это твое мнение, или объективные исследования?

RK>>> Другие Форты? Это не производные, это просто другие версии. Есть RK>>> хоть один язык, построенный на основе Форта, но не Форт? IT>> Hе другие Форты, а другие языки. Lux, Onyx, еще что-то...

RK> Хм, если о Форте еще хоть что то известно, то об этих я лично даже не RK> слышал.

Joy подсказали - а я совсем забыл, и зря.... Орлов вон и про Ocaml ничего не слышал, но о чем это говорит?

IT>> Си, Паскаль, Алгол, Фортран - разные языки?

RK> Да. Программа на С не будет компилироваться Паскалем и т.д.

Они сопоставимы на уровне грамматики, а ты описываешь эффект от применения конкретных реализаций компиляторов. Это очень разные вещи.

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

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

IT>> Иначе зачем там стековый кадр

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

???????? 8-|

Ты уверен? А не все ли равно, что именно вызывать? А если ты сгенерируешь вызов функции (другой) с десятком параметров, то параметры разве будут не на стеке?

RK> Это было сделано для языков типа Паскаля для организации display RK> регистров на стеке, сейчас эти команды практически не используются (по RK> крайней мере в том объеме, в котором они задумывались)

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

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

:-/ Ничего себе определение. Применяем его к .net и видим, что ВСЕ эти языки (C++ C# VB и т.д.) - диалекты друг друга. Про фазы компиляции в определении ни слова.... (А .net использует единый промежуточный формат)

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

RK> Да, что однако не мешает применять эти языки и сами по себе.

Simulink - это хорошо или плохо? Ты сам говорил о тенденции перехода к все более высокому уровню.

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

За откровениями - в церковь... :)

RK> получил тривиальный ответ - умножаем частоту ... :(

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

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

RK> Hикто не мешает дописать своих управляющих слов с использованием того же RK> control-flow стека и непреднамеренно разрушить весь контроль в результате RK> ошибки.

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

RK> Это можно описать такой грамматикой (фрагмент):

RK> слово := ':' { элемент } ';' RK> элемент := примитив | if-конструкция | ... RK> if-конструкция := элемент 'if' { элемент } [ 'else' { элемент } ] 'then'

RK> При таком подходе компилятор сможет досконально проверить всю грамматику RK> (как синтаксис так и семантику), но пользователь не сможет расширить RK> грамматику Форта своими словами.

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

RK>>> Hе очень. Синтаксис/семантика должны проверяться в целом, а не по RK>>> отдельным элементам. IT>> К этому есть существенные основания? RK> Есть - надежность.

Композицию уже отменили?

IT>> (to be continued)

RK> Ой, а может хватит?

А как хочешь...

Mon Oct 13 2003 22:47, Roman Khvatov wrote to Ilia Tarasov:

RK>>> a*b/c+a*b%d

IT>> Кстати, в постфиксе ты все-таки вынес за скобки a*b... Почему? IT>> Стековая машина подсказала? ;)

RK> Hет, обычная CSE оптимизация.

Она следует в явном виде из отквоченного вверху?

IT>> Си делал некоторые расчеты 25-30 минут. Ассемблер под DPMI - 2-3... IT>> Разница есть? Вейвлеты, если интересно...

RK> Си под ДОС'ом, а ассемблер под DPMI? Тогда понятно, если и то и другое RK> под DPMI - то надо что то в консерватории править :)

Плюх... Watcom C - DPMI, однако. Не додумывай за меня - будут _фактические_ ошибки... ;)

IT>> Интересно, а как ты видишь взаимодействие интерпретатора и IT>> компилятора??

RK> Hикак. Могут взаимодействовать интерпретатор и _откомпилированная RK> программа_

Примером чего и является Форт-система...

IT>> В нулевом кольце исполняются _ассемблерные_ примитивы. Адресующие в IT>> линейном пространстве обрабатываемые массивы в десятки мегабайт.

RK> А почему _вся_ программа не может исполняться в нулевом кольце? И для RK> чего ее нужно обязательно интерпретировать?

Не знаю, у тебя опять странные проекции. Она вся там и исполняется, а интерпретируются скрипты. Для них прикажешь специально выделить V86 и работать только там? Чтобы откомпилированному коду было не обидно?

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

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

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

IT>> См. тикль, например. Очень разумная альтернатива RAD-монстрам...

RK> Монстры они не из за того, что компилированные :)

Дааа??? :) И Дельфи генерирует hello, world в сотню килобайт, чтобы проверить качество поверхности винчестера? :))))

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

RK> Вообще то меня больше интересует как он будет работать у пользователя - а RK> у него он явно будет работать медленнее. И где пользователь будет брать RK> сам тикль? Я понимаю, что в Интернете он лежит чуть ли не на каждой RK> файловой помойке, но заставлять пользователя лазить по Интернету и RK> выкачивать все, что захочется использовать программе я считаю в первую RK> очередь неуважением к самому пользователю.

Опять флейм, притом отдельный. Я тебе про принципиальные подходы говорю...

IT>> Гмм... Высокая производительность при обработке больших массивов IT>> данных плюс возможность показать результаты в высоком разрешении и IT>> цветах плюс возможность без перекомпиляции задавать свой порядок IT>> действий. Странные требования?

RK> Ты искал интерпретатор (как сам сказал), для него - странные. Тебе нужно RK> было искать библиотеку для работы с графикой + компилятор для DPMI + RK> скриптовый язык общего назначения.

Я не искал интерпретатор и не говорил такого. Я искал _систему_, обладающую перечисленными свойствами. Ты уже перечислил _ТРИ_ системы (которые, btw, должны быть удобно стыкуемыми), я говорю, что они прекрасно заменяются одной.

RK> Hе надо всех Сишных программеров считать полными дебилами :) В конце RK> концов 'система обработки ввода пользователя' тоже написана человеком.

Для полностью компилируемых программ эта система не является частью языка. Соответственно, она автоматически попадает в разряд "прикладных программ". Что там наворочено - еще надо разобраться...

IT>> Даже в Delphi/Builder программеры умудряются IT>> наворотить ошибки в интерфейсе (это при визуальных инструментах!). RK> Такие програмеры :( Hе надо на них равняться.

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

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

Специалист - он всегда специалист. И фразу "только писать надо обязательно на Си" (ассемблере, форте, паскале) от него услышать практически невозможно. Есть разные инструменты, разные подходы и разные критерии их оптимальности. Можно разговаривать о том, как _этот_ инструмент применить в _этих_ условиях, но это не должно быть предметом флейма ("не знаю, я тут и не в России, и другими задачами занимаюсь, но это все чушь, мне она не нужна, у меня и так зарплата XX k$...")

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