_Loader_

Thu Oct 09 2003 22:39, Dima Orlov wrote to Ilia Tarasov:

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

:)))))))))))))))))))))))))))))))))))))))))))))

Ты и о БНФ не знаешь???? Вот этот твой вывод меня просто порадовал... примерно как когда-то ответ студента "Реактивное сопротивление - это сопротивление конденсатора, летящего со скоростью света"...

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

Hi Ilia!

IT> HÅ ÓËÁÖÕ ÐÒÏ NASA, ÎÏ ÓÌÙÛÁÌ, ËÁË ÚÁÍ. ÇÌÁ×ÎÏÇÏ ËÏÎÓÔÒÕËÔÏÒÁ "üÎÅÒÇÉÉ" IT> ËÌÑÔ×ÅÎÎÏ ÏÂÅÝÁÌ ÁËÁÄÅÍÉËÁÍ, ÞÔÏ ÂÏÌØÛÅ ÎÉËÁËÏÇÏ ÚÁÐÁÄÎÏÇÏ ÓÏÆÔÁ ÎÁ IT> íëó ÎÅ ÂÕÄÅÔ - ÔÏÌØËÏ ÓÏÂÓÔ×ÅÎÎÏÊ ÒÏÓÓÉÊÓËÏÊ ÒÁÚÒÁÂÏÔËÉ, ×ËÌÀÞÁÑ ïó É IT> ×ÓÅ ËÏÍÐÉÌÑÔÏÒÙ.

Sincerely, Vadim.

Fri Oct 10 2003 03:47, Yuriy K wrote to Ilia Tarasov:

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

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

Смотри литературу.

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

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

Это ты приводишь. А я всего лишь несколько вскрыл набухавший "нарывчик" - теперь через письмо упоминания о дОцентах, совках и ученых, которым не важен результат. И перечисления должностей и полученных плюшечек много больше наблюдается. Видимо, наболело у кого-то....

IT>> Я уже не говорю о том, что этот IT>> человек может быть и прав - как ты проверишь?

YK> Для любого человека, умеющего работать в MaxPlus ошибка очевидна.

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

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

Почему не могу? Много задач, разные требования к производительности, разная периферия. Или ты предлагаешь подход в стиле "изучив разные процессоры, пришли к выводу, что задаче лучше всего соответствует XXX, но делать будем на PIC-е, потому что больше ни на чем не умеем"?

YK> Без разницы. Я представляю, что за ассемблер у Hitachi SH, я на нем писал

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

Твой опыт - это твой опыт... Упоминанием gcc ты не открыл для меня Америки...

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

YK> Форт стоит изучить в институте, как не самый тривиальный, интересный,

Fixed

YK> но неприменимый на практики метод программирования.

А как-то твоему, программировать в таком стиле сильно лучше?

Init(); while(1){ Cycle(); printf(" Выполнен еще один цикл" }

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

YK> Клевета тебя не красит. Стыдно должно быть, вроде бы взрослый человек...

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

Hello Sergey!

Roman

... No locked doors, no windows barred

Fri Oct 10 2003 13:43, Alexey Boyko wrote to Dima Orlov:

AB> 2IT: Здесь я тоже не понял, что это значит. А кто гарантирует?

Никто не гарантирует, естественно. Гарантирует только наличие собственного движка кросс-компилятора, адаптируемого под требуемые платформы.

Fri Oct 10 2003 21:58, Ilia Tarasov wrote to Yuriy K:

YK>> úÁ ÐÏÌÞÁÓÁ ÐÒÏÃÅÓÓÏÒÎÙÅ ÑÄÒÁ ÎÅ ÒÁÚÒÁÂÁÔÙ×ÁÀÔÓÑ, ËÁËÉÅ ÕÖ ÔÕÔ ÍÎÅÎÉÑ. IT> óÍÏÔÒÉ ÌÉÔÅÒÁÔÕÒÕ.

YK>> åÓÌÉ ÔÙ ÎÅ ÍÏÖÅÛØ ÏÂßÑÓÎÉÔØ ÎÅÏÂÈÏÄÉÍÏÓÔØ ÔÁËÏÇÏ ÚÏÏÐÁÒËÁ ÐÒÏÃÅÓÓÏÒÏ× YK>> ÄÒÕÇÉÍ, ×ÏÚÎÉËÁÅÔ ÐÏÄÏÚÒÅÎÉÅ, ÞÔÏ ÔÙ ÎÅ ÍÏÖÅÛØ ÏÂßÑÓÎÉÔØ ÜÔÏ ÄÁÖÅ ÓÅÂÅ.

IT> ðÏÞÅÍÕ ÎÅ ÍÏÇÕ? íÎÏÇÏ ÚÁÄÁÞ, ÒÁÚÎÙÅ ÔÒÅÂÏ×ÁÎÉÑ Ë ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ, IT> ÒÁÚÎÁÑ ÐÅÒÉÆÅÒÉÑ. éÌÉ ÔÙ ÐÒÅÄÌÁÇÁÅÛØ ÐÏÄÈÏÄ × ÓÔÉÌÅ "ÉÚÕÞÉ× ÒÁÚÎÙÅ IT> ÐÒÏÃÅÓÓÏÒÙ, ÐÒÉÛÌÉ Ë ×Ù×ÏÄÕ, ÞÔÏ ÚÁÄÁÞÅ ÌÕÞÛÅ ×ÓÅÇÏ ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ XXX, ÎÏ IT> ÄÅÌÁÔØ ÂÕÄÅÍ ÎÁ PIC-Å, ÐÏÔÏÍÕ ÞÔÏ ÂÏÌØÛÅ ÎÉ ÎÁ ÞÅÍ ÎÅ ÕÍÅÅÍ"?

HÅ ÒÁÓÓÔÒÁÉ×ÁÊÓÑ, Ñ ÐÉËÉ ÔÏÖÅ ÎÅ ÌÀÂÌÀ. :-))) ôÒÁÔÕ ÖÅ ×ÒÅÍÅÎÉ(ÄÅÎÅÇ) ÎÁ ÉÚÕÞÅÎÉÅ ÄÅÓÑÔËÏ× ÒÁÚÌÉÞÎÙÈ ÐÒÏÃÅÓÓÏÒÏ×, ÉÈ ÏÓÏÂÅÎÎÏÓÔÅÊ É ÔÏÎËÏÓÔÅÊ ÐÒÉÍÅÎÅÎÉÑ × ÒÅÁÌØÎÏÊ ÖÉÚÎÉ ÓÞÉÔÁÀ ÇÌÕÐÏÊ.

YK>> âÅÚ ÒÁÚÎÉÃÙ. ñ ÐÒÅÄÓÔÁ×ÌÑÀ, ÞÔÏ ÚÁ ÁÓÓÅÍÂÌÅÒ Õ Hitachi SH, Ñ ÎÁ ÎÅÍ YK>> ÐÉÓÁÌ YK>> ÐÁÒÕ ÏÓÏÂÏ ÎÉÚËÏÕÒÏ×ÎÅ×ÙÈ ÐÏÄÐÒÏÇÒÁÍÍ, ËÏÔÏÒÙÅ ÎÅÌØÚÑ ÂÙÌÏ ÎÁÐÉÓÁÔØ ÎÁ YK>> ó. ôÁË ×ÏÔ, ÔÏÔ ÖÅ GCC ËÒÏÅÔ ÌÀÂÏÇÏ ÐÒÏÇÒÁÍÍÉÓÔÁ ÎÁ ÁÓÓÅÍÂÌÅÒÅ SH ËÁË YK>> ÂÙË Ï×ÃÕ.

IT> ô×ÏÊ ÏÐÙÔ - ÜÔÏ Ô×ÏÊ ÏÐÙÔ...

IT> õÐÏÍÉÎÁÎÉÅÍ gcc ÔÙ ÎÅ ÏÔËÒÙÌ ÄÌÑ ÍÅÎÑ áÍÅÒÉËÉ...

YK>> ÎÏ ÎÅÐÒÉÍÅÎÉÍÙÊ ÎÁ ÐÒÁËÔÉËÉ ÍÅÔÏÄ ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÑ.

IT> á ËÁË-ÔÏ Ô×ÏÅÍÕ, ÐÒÏÇÒÁÍÍÉÒÏ×ÁÔØ × ÔÁËÏÍ ÓÔÉÌÅ ÓÉÌØÎÏ ÌÕÞÛÅ?

HÅÈÏÒÏÛÏ ÞÅÌÏ×ÅËÕ ÓÏ ÓÔÅÐÅÎØÀ(?) ÎÅ ÚÎÁÔØ ÏÓÎÏ× ÌÏÇÉËÉ. HÅ ÓÔÙÄÎÏ?

WBR, àÒÉÊ.

Fri Oct 10 2003 22:42, Vadim Rumyantsev wrote to Ilia Tarasov:

IT>> HÅ ÓËÁÖÕ ÐÒÏ NASA, ÎÏ ÓÌÙÛÁÌ, ËÁË ÚÁÍ. ÇÌÁ×ÎÏÇÏ ËÏÎÓÔÒÕËÔÏÒÁ "üÎÅÒÇÉÉ" IT>> ËÌÑÔ×ÅÎÎÏ ÏÂÅÝÁÌ ÁËÁÄÅÍÉËÁÍ, ÞÔÏ ÂÏÌØÛÅ ÎÉËÁËÏÇÏ ÚÁÐÁÄÎÏÇÏ ÓÏÆÔÁ ÎÁ IT>> íëó ÎÅ ÂÕÄÅÔ - ÔÏÌØËÏ ÓÏÂÓÔ×ÅÎÎÏÊ ÒÏÓÓÉÊÓËÏÊ ÒÁÚÒÁÂÏÔËÉ, ×ËÌÀÞÁÑ ïó É IT>> ×ÓÅ ËÏÍÐÉÌÑÔÏÒÙ.

VR> õ ÍÅÎÑ ×ÏÚÎÉËÁÅÔ ÔÏÌØËÏ ÏÄÉÎ ×ÏÐÒÏÓ: ÐÒÉޣÍ ÚÄÅÓØ ÁËÁÄÅÍÉËÉ?

WBR, àÒÉÊ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Именно так!

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

RK> 1 команда.

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

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

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

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

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

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

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

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

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

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

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

Fri Oct 10 2003 22:42, Vadim Rumyantsev wrote to Ilia Tarasov:

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

VR> У меня возникает только один вопрос: причём здесь академики?

Дело было на семинаре соответствующей секции РАН....

Sat Oct 11 2003 00:56, Yuriy K wrote to Ilia Tarasov:

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

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

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

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

4) Еще пяток книг по проектированию ПЛИС, описанию VHDL и брошюры с методическими материалы от Xilinx. Там рассматриваются непрограммируемые конечные автоматы. Их перечислить, или приведенного в принципе достаточно? Или я должен провести для тебя поиск в инете?

IT>> Почему не могу? Много задач, разные требования к производительности, IT>> разная периферия. Или ты предлагаешь подход в стиле "изучив разные IT>> процессоры, пришли к выводу, что задаче лучше всего соответствует XXX, IT>> но делать будем на PIC-е, потому что больше ни на чем не умеем"?

YK> Hе расстраивайся, я пики тоже не люблю. :-))) YK> Трату же времени(денег) на изучение десятков различных процессоров, их YK> особенностей и тонкостей применения в реальной жизни считаю глупой.

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

YK>>> Без разницы. Я представляю, что за ассемблер у Hitachi SH, я на нем YK>>> писал YK>>> пару особо низкоуровневых подпрограмм, которые нельзя было написать на YK>>> С. Так вот, тот же GCC кроет любого программиста на ассемблере SH как YK>>> бык овцу.

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

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

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

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

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

Никто никого не мучал. У нас сейчас мало кто пишет на Си, познакомившись с Фортом - там простая и понятная система целевой компиляции. Ассемблер на Форте даже школьники делали! С освоением gcc и адаптацией его под новый процессор было бы больше мучений - людям интересно другое...

YK>>> но неприменимый на практики метод программирования.

IT>> А как-то твоему, программировать в таком стиле сильно лучше?

YK> Hехорошо человеку со степенью(?) не знать основ логики. Hе стыдно?

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

Hello, Alexey Boyko !

Hello, Alex Kouznetsov !

Hello, Ilia Tarasov !

HÕ É ÚÁÞÅÍ ×ÅÓØ ÜÔÏÔ ÎÅÌÅÐÙÊ ×Ù×ÏÄÏË ÐÒÏÃÅÓÓÏÒÏ×, ×ËÌÀÞÁÑ ÓÁÍÏÄÅÌØÎÙÅ, ×ÍÅÓÔÏ ÔÒÁÄÉÃÉÏÎÎÏ ÐÒÉÍÅÎÑÀÝÉÈÓÑ × ÜÔÉÈ ÏÂÌÁÓÔÑÈ DSP?

HÅÔ, Ñ ÓÔÁÒÁÀÓØ ÉÓËÁÔØ ÔÏ ÒÅÛÅÎÉÅ, ËÏÔÏÒÏÅ ÔÒÅÂÕÅÔ ÍÅÎØÛÉÈ ÚÁÔÒÁÔ ÄÅÎÅÇ, ÓÉÌ, ×ÒÅÍÅÎÉ. äÌÑ ÕÐÒÁ×ÌÅÎÉÑ ÄÉÓÐÌÅÑÍÉ ÅÓÔØ ÍÁÓÓÁ ÇÏÔÏ×ÙÈ É ÎÅ ÄÏÒÏÇÉÈ ÒÅÛÅÎÉÊ. úÁÞÅÍ ÒÏÖÁÔØ Ó×ÏÅ?

Hello, Ilia Tarasov !

HÁÐÉÓÁÔØ state mashine ÎÁ ó É ËÏÍÐÉÌÑÉÒÏ×ÁÔØ ÄÌÑ ÒÁÚÎÙÈ ÐÒÏÃÅÓÓÏÒÏ× ÞÔÏÂÙ ÐÏÓÍÏÔÒÅÔØ ÒÅÚÕÌØÔÁÔ - ×ÉÄÉÍÏ ÓÌÉÛËÏÍ ÓÌÏÖÎÁÑ ÄÌÑ ËÁÎÄÉÄÁÔÁ × ÄÏËÔÏÒÁ ÚÁÄÁÞÁ.

Hello, Ilia Tarasov !

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Sat Oct 11 2003 01:49, Ilia Tarasov wrote to Yuriy K:

YK>>>> úÁ ÐÏÌÞÁÓÁ ÐÒÏÃÅÓÓÏÒÎÙÅ ÑÄÒÁ ÎÅ ÒÁÚÒÁÂÁÔÙ×ÁÀÔÓÑ, ËÁËÉÅ ÕÖ ÔÕÔ ÍÎÅÎÉÑ. IT>>> óÍÏÔÒÉ ÌÉÔÅÒÁÔÕÒÕ.

YK>> ðÒÉ×ÏÄÉ ÉÓÔÏÞÎÉË ÉÎÆÏÒÍÁÃÉÉ. ó ÐÒÉÍÅÒÁÍÉ.

IT> üÈ, ÎÕ ÞÔÏ Ö ÔÙ ÍÅÎÑ Ë ËÎÉÖÎÏÍÕ ÛËÁÆÕ ÐÏÇÎÁÌ? :)

IT> 1) HÕ ×ÏÔ, ÎÁÐÒÉÍÅÒ: âÒÏÄÉÎ ÷.â., ëÁÌÉÎÉÎ á.÷. óÉÓÔÅÍÙ ÎÁ IT> ÍÉËÒÏËÏÎÔÒÏÌÌÅÒÁÈ É âéó ÐÒÏÇÒÁÍÍÉÒÕÅÍÏÊ ÌÏÇÉËÉ. í.: éÚÄ-×Ï üëïí, 2002 IT> ÓÔÒ. 245: òÁÚÄÅÌ "ðÒÏÅËÔ áìõ RISC ÍÉËÒÏËÏÎÔÒÏÌÌÅÒÁ". "... × ÜÔÏÍ IT> ÐÁÒÁÇÒÁÆÅ ÂÕÄÅÔ ÐÒÏÄÅÍÏÎÓÔÒÉÒÏ×ÁÎÁ ×ÏÚÍÏÖÎÏÓÔØ ÒÅÁÌÉÚÁÃÉÉ ÎÁ ðìéó IT> EPF8282ALC84 ÁÒÉÆÍÅÔÉËÏ-ÌÏÇÉÞÅÓËÏÇÏ ÕÓÔÒÏÊÓÔ×Á (áìõ) IT> RISC-ÍÉËÒÏËÏÎÔÒÏÌÌÅÒÏ× ÔÉÐÁ PIC16 ÆÉÒÍÙ MicroChip. ëÒÏÍÅ ÒÅÁÌÉÚÁÃÉÉ IT> ÆÒÁÇÍÅÎÔÁ áìõ, ÐÒÏÅËÔ ×ËÌÀÞÁÅÔ ÉÎÔÅÒÆÅÊÓ ××ÏÄÁ ÄÁÎÎÙÈ Ó ÐÅÒÅËÌÀÞÁÔÅÌÑ IT> ÍÁËÅÔÁ É ×Ù×ÏÄÁ ÎÁ ÕÓÔÒÏÊÓÔ×Ï ÏÔÏÂÒÁÖÅÎÉÑ..."

IT> 2) áËÉÍÏ× ï.å. äÉÓËÒÅÔÎÁÑ ÍÁÔÅÍÁÔÉËÁ: ÌÏÇÉËÁ, ÇÒÕÐÐÙ, ÇÒÁÆÙ. í: ìâú, IT> 2001. þÁÓÔØ 3.4 òÅÛÅÎÉÑ ÚÁÄÁÞ ÐÏ ÔÅÏÒÉÉ ËÏÄÉÒÏ×ÁÎÉÑ, Á×ÔÏÍÁÔÏ× É ÑÚÙËÏ× IT> Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ ÇÒÁÆÏ×.

IT> 3) ðÒÉÍÅÒ ÐÒÏÃÅÓÓÏÒÎÏÇÏ ÑÄÒÁ ÉÚ ÓÔÁÎÄÁÒÔÎÏÊ ÐÏÓÔÁ×ËÉ ËÏÍÐÉÌÑÔÏÒÁ Handel-C IT> ÆÉÒÍÙ Celoxica. úÁÎÉÍÁÅÔ ÓÍÅÛÎÏÊ ÏÂßÅÍ ÔÅËÓÔÁ, ÄÅÌÁÌÓÑ ÅÝÅ ÄÌÑ ×ÅÒÓÉÉ IT> 2.1, ËÏÔÏÒÁÑ ×ÙÛÌÁ ÇÏÄÁ Ä×Á ÎÁÚÁÄ.

IT> 4) åÝÅ ÐÑÔÏË ËÎÉÇ ÐÏ ÐÒÏÅËÔÉÒÏ×ÁÎÉÀ ðìéó, ÏÐÉÓÁÎÉÀ VHDL É ÂÒÏÛÀÒÙ Ó IT> ÍÅÔÏÄÉÞÅÓËÉÍÉ ÍÁÔÅÒÉÁÌÙ ÏÔ Xilinx. ôÁÍ ÒÁÓÓÍÁÔÒÉ×ÁÀÔÓÑ ÎÅÐÒÏÇÒÁÍÍÉÒÕÅÍÙÅ IT> ËÏÎÅÞÎÙÅ Á×ÔÏÍÁÔÙ.

IT> éÈ ÐÅÒÅÞÉÓÌÉÔØ, ÉÌÉ ÐÒÉ×ÅÄÅÎÎÏÇÏ × ÐÒÉÎÃÉÐÅ IT> ÄÏÓÔÁÔÏÞÎÏ? éÌÉ Ñ ÄÏÌÖÅÎ ÐÒÏ×ÅÓÔÉ ÄÌÑ ÔÅÂÑ ÐÏÉÓË × ÉÎÅÔÅ?

YK>>>> ÎÏ ÎÅÐÒÉÍÅÎÉÍÙÊ ÎÁ ÐÒÁËÔÉËÉ ÍÅÔÏÄ ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÑ. IT>>> á ËÁË-ÔÏ Ô×ÏÅÍÕ, ÐÒÏÇÒÁÍÍÉÒÏ×ÁÔØ × ÔÁËÏÍ ÓÔÉÌÅ ÓÉÌØÎÏ ÌÕÞÛÅ?

YK>> HÅÈÏÒÏÛÏ ÞÅÌÏ×ÅËÕ ÓÏ ÓÔÅÐÅÎØÀ(?) ÎÅ ÚÎÁÔØ ÏÓÎÏ× ÌÏÇÉËÉ. HÅ ÓÔÙÄÎÏ?

IT> ôÙ ÎÅ ÏÔ×ÅÔÉÌ ÎÁ ×ÏÐÒÏÓ... :)))

IT> ôÁË ×ÓÅ-ÔÁËÉ, ÔÏÔ ËÕÓÏË, ËÏÔÏÒÙÊ ÔÙ IT> ÓËÉÐÎÕÌ, ÏÎ ËÁË, ÎÁ Ô×ÏÊ ×ÚÇÌÑÄ? ðÒÏÓÔÏ ÆÏÒÍÁÌØÎÏ ÕËÁÖÉ, ÞÔÏ × ÎÅÍ ÎÅ IT> ÔÁË. üÔÏ ×ÁÖÎÏ.

IT> Init(); IT> while(1){ IT> Cycle(); IT> printf(" ÷ÙÐÏÌÎÅÎ ÅÝÅ ÏÄÉÎ ÃÉËÌ" IT> }

WBR, àÒÉÊ.

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

IT> ëÓÔÁÔÉ, JCXZ ×ÅÄØ ÐÒÉÌÉÞÎÏ ÓÐÏÓÏÂÓÔ×ÕÅÔ ÕÍÅÎØÛÅÎÉÀ ÞÉÓÌÁ ÔÁËÔÏ×?

CÍÏÔÒÑ ÎÁ ËÁËÏÍ ÐÒÏÃÅÓÓÏÒÅ. HÁ ÓÕÐÅÒÓËÁÌÑÒÎÙÈ x86 ÓÐÏÓÏÂÓÔ×ÕÅÔ Õ×ÅÌÉÞÅÎÉÀ ÞÉÓÌÁ ÔÁËÔÏ×.

II> á ÂÏÌÅÅ IT> ÍÏÝÎÙÅ ×ÁÒÉÁÎÔÙ ÁÐÐÁÒÁÔÎÏÊ ÒÅÁÌÉÚÁÃÉÉ ËÏÍÁÎÄ ÃÉËÌÁ? ðÒÏÂÌÅÍÙ. åÓÌÉ ÃÉËÌ ÒÅÁÌÉÚÏ×ÁÎ ÁÐÐÁÒÁÔÎÏ, ÔÏ ÏÔÒÁÂÏÔÁÔØ ÐÒÅÒÙ×ÁÎÉÅ × ÐÒÏÃÅÓÓÅ ×ÙÐÏÌÎÅÎÉÑ ÔÁËÏÇÏ ÃÉËÌÁ ÎÅÐÒÏÓÔÏ. ïÓÏÂÅÎÎÏ ÅÓÌÉ ÜÔÏ ÐÅÒÅËÌÀÞÅÎÉÅ ÚÁÄÁÞ Ó ×ÌÏÖÅÎÎÙÍÉ ÁÐÐÁÒÁÔÎÙÍÉ ÃÉËÌÁÍÉ.

IT> HÁÐÒÉÍÅÒ, ÞÔÏ ÍÏÖÎÏ ÓËÁÚÁÔØ Ï ÓÉÓÔÅÍÅ ËÏÍÁÎÄ, ËÏÔÏÒÁÑ ÎÁÉÂÏÌÅÅ ÐÏÌÎÏ IT> "ÐÒÉÌÅÇÁÅÔ" Ë ÔÉÐÉÞÎÙÍ ÏÐÅÒÁÃÉÑÍ ÁÂÓÔÒÁËÔÎÏÊ ×ÙÞÉÓÌÉÔÅÌØÎÏÊ ÍÁÛÉÎÙ, IT> ÒÅÛÁÀÝÅÊ ÚÁÄÁÞÕ?

CÕÝÅÓÔ×ÕÅÔ N ÓÐÏÓÏÂÏ× ÏÐÉÓÁÔØ ÁÌÇÏÒÉÔÍ ÚÁÄÁÞÉ ÐÏÌØÚÕÑÓØ ÏÐÅÒÁÃÉÑÍÉ ÔÏÊ ÉÌÉ ÉÎÏÊ ×ÙÞÉÓÌÉÔÅÌØÎÏÊ ÍÁÝÉÎÙ c ÔÏÊ ÉÌÉ ÉÎÏÊ ÓÔÏÉÍÏÓÔØÀ ÒÁÚÌÉÞÎÙÈ ÏÐÅÒÁÃÉÊ. éÚ ÓÐÏÓÏÂÏ× ÉÎÔÅÒÅÓÎÙ ÔÏÌØËÏ ×ÙÓÏËÏÕÒÏ×ÎÅ×ÙÅ É ÏÂÝÅÐÒÉÎÑÔÙÅ.

RK>> äÁÖÅ ÎÁ æÏÒÔ ÐÒÏÃÅÓÓÏÒ ÍÏÖÎÏ ÐÏÓÔÁ×ÉÔØ ÎÏÒÍÁÌØÎÙÊ ó RK>> ËÏÍÐÉÌÑÔÏÒ, Ó ÔÏÞËÉ ÚÒÅÎÉÑ ÓÏÐÒÏ×ÏÖÄÁÅÍÏÓÔÉ É ÞÉÔÁÅÍÏÓÔÉ ÐÒÏÇÒÁÍÍ ÜÔÏ RK>> ÂÕÄÅÔ ÌÕÞÛÅ, ÞÅÍ æÏÒÔ

IT> HÕ ÓÌÁ×Á ÂÏÇÕ, ÄÏÂÒÁÌÉÓØ ÎÁËÏÎÅÃ-ÔÏ ÄÏ ÔÁËÏÇÏ ×Ù×ÏÄÁ!!! :)))) äÁ, IT> ÐÏÌÎÏÓÔØÀ ÓÏÇÌÁÓÅÎ. éÍÅÎÎÏ ÔÁË É ÒÁÂÏÔÁÅÍ ÓÅÊÞÁÓ.

IT> ÷ÏÂÝÅÍ-ÔÏ Õ ÎÁÓ ÓÌÏÖÉÌÓÑ ÎÅÓËÏÌØËÏ ÉÎÏÊ ÐÏÄÈÏÄ. HÁÉÂÏÌÅÅ ËÒÉÔÉÞÎÙÊ ËÕÓÏË IT> ËÏÄÁ (Á ÏÎ, ËÁË ÐÒÁ×ÉÌÏ, ÄÏ×ÏÌØÎÏ ÎÅÂÏÌØÛÏÊ) ×ÙÐÉÓÙ×ÁÅÔÓÑ × ÔÅÒÍÉÎÁÈ IT> ÁÂÓÔÒÁËÔÎÏÊ ÍÁÛÉÎÙ.

MathLab.

IT> úÁÔÅÍ ÜÔÏ ÐÒÉÍÅÒÑÅÔÓÑ Ë ÓÉÓÔÅÍÅ ËÏÍÁÎÄ ËÏÎËÒÅÔÎÏÇÏ IT> ÐÒÏÃÅÓÓÏÒÁ.

MathLab ÉÌÉ C/asm. ÷ÐÏÌÎÅ ÄÏÓÔÁÔÏÞÎÏ ÄÌÑ ÏÃÅÎËÉ.

IT> åÓÌÉ ÎÅ ÌÅÚÅÔ ÐÏ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ, ÔÏ ËÏÍÐÉÌÑÔÏÒ ÕÖÅ ÎÉÞÅÍ IT> ÎÅ ÐÏÍÏÖÅÔ (ÎÁÐÏÍÉÎÁÀ, ÞÔÏ ÏÔ ËÏÎÅÞÎÏÇÏ Á×ÔÏÍÁÔÁ ÉÄÔÉ ÏÞÅÎØ ÐÒÏÓÔÏ - ÜÔÏ IT> ÎÅ ÐÏÌÕÉÎÔÕÉÔÉ×ÎÙÊ ÐÏÄÈÏÄ ÁÓÓÅÍÂÌÅÒÝÉËÁ, ËÏÔÏÒÙÊ ÄÅÊÓÔ×ÉÔÅÌØÎÏ ÍÏÖÅÔ IT> ÞÔÏ-ÔÏ ÐÒÏÐÕÓÔÉÔØ). HÏ ÅÓÌÉ ÅÓÔØ ÏÐÉÓÁÎÉÅ ëá É ÈÏÒÏÛÏ ÏÓ×ÏÅÎÙ ðìéóÙ, IT> ÔÏ...?

VLV

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

Saturday October 11 2003 01:49, Ilia Tarasov wrote to Yuriy K:

YK>> ôÒÁÔÕ ÖÅ ×ÒÅÍÅÎÉ(ÄÅÎÅÇ) ÎÁ ÉÚÕÞÅÎÉÅ ÄÅÓÑÔËÏ× ÒÁÚÌÉÞÎÙÈ ÐÒÏÃÅÓÓÏÒÏ×, YK>> ÉÈ ÏÓÏÂÅÎÎÏÓÔÅÊ É ÔÏÎËÏÓÔÅÊ ÐÒÉÍÅÎÅÎÉÑ × ÒÅÁÌØÎÏÊ ÖÉÚÎÉ ÓÞÉÔÁÀ YK>> ÇÌÕÐÏÊ. IT>

IT> HÕ Á ËÔÏ ÓËÁÚÁÌ, ÞÔÏ _Ñ_ ÉÚÕÞÁÀ "×ÅÓØ ÜÔÏÔ ÚÏÏÐÁÒË", ÐÒÉÞÅÍ ÐÏÓÔÏÑÎÎÏ? þÔÏ IT> ÓÄÅÌÁÎÏ ÎÁ ÏÐÒÅÄÅÌÅÎÎÏÍ ÜÔÁÐÅ, ÏÔÈÏÄÉÔ ÎÁ ×ÔÏÒÏÊ ÐÌÁÎ. ñ × ËÕÒÓÅ ÏÓÎÏ×ÎÙÈ IT> ÎÏ×ÏÓÔÅÊ × ÏÂÌÁÓÔÉ ÜÌÅËÔÒÏÎÉËÉ É ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÑ É ÉÍÅÀ ÐÏÌÎÏÅ IT> ÐÒÅÄÓÔÁ×ÌÅÎÉÅ Ï ÉÎÔÅÒÅÓÕÀÝÉÈ ÍÅÎÑ ÐÒÏÃÅÓÓÏÒÎÙÈ ÁÒÈÉÔÅËÔÕÒÁÈ. HÏ ÎÅ ÎÁ IT> ÕÒÏ×ÎÅ ÖÅ "ÓËÏÌØËÏ UART Õ ÜÔÏÇÏ PIC-Á"...

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

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

IT>> åÓÌÉ ÎÅ ÌÅÚÅÔ ÐÏ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ, ÔÏ ËÏÍÐÉÌÑÔÏÒ ÕÖÅ ÎÉÞÅÍ IT>> ÎÅ ÐÏÍÏÖÅÔ (ÎÁÐÏÍÉÎÁÀ, ÞÔÏ ÏÔ ËÏÎÅÞÎÏÇÏ Á×ÔÏÍÁÔÁ ÉÄÔÉ ÏÞÅÎØ ÐÒÏÓÔÏ - IT>> ÜÔÏ ÎÅ ÐÏÌÕÉÎÔÕÉÔÉ×ÎÙÊ ÐÏÄÈÏÄ ÁÓÓÅÍÂÌÅÒÝÉËÁ, ËÏÔÏÒÙÊ ÄÅÊÓÔ×ÉÔÅÌØÎÏ IT>> ÍÏÖÅÔ ÞÔÏ-ÔÏ ÐÒÏÐÕÓÔÉÔØ). HÏ ÅÓÌÉ ÅÓÔØ ÏÐÉÓÁÎÉÅ ëá É ÈÏÒÏÛÏ ÏÓ×ÏÅÎÙ IT>> ðìéóÙ, ÔÏ...? VV>

VV> þÅÍ ÖÅ ×Ù ×ÓÅ-ÔÁËÉ ÚÁÎÉÍÁÅÔÅÓØ? áÌÇÏÒÉÔÍÁÍÉ ÕÌØÔÒÁÚ×ÕËÏ×ÏÊ ÌÏËÁÃÉÉ, VV> ÒÁÚÒÁÂÏÔËÏÊ ËÏÍÐÉÌÑÔÏÒÏ× ÉÌÉ ÒÁÚÒÁÂÏÔËÏÊ ÐÒÏÃÅÓÓÏÒÏ×? þÔÏ Ñ×ÌÑÅÔÓÑ VV> ËÏÎÅÞÎÙÍ ÐÒÏÄÕËÔÏÍ?

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com