_Loader_

Sat Oct 11 2003 20:40, Vladimir Vassilevsky wrote to Alex Kouznetsov:

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

Я сказал "_можно_ поставить Си". А из изложенных материалов напрашивается вопрос, а почему же именно Си и только его?

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

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

AK>> Программы на Форте компактнее чем на С. Как AK>> исходник компактнее, так и код в памяти занимает меньше места.

VV> Cпорное утверждение. И даже если это так, то кого это волнует. VV> Задача вмещается в поставленные рамки - значит, все отлично. VV> Проект должен быть сделан быстро. Его должно быть удобно поддерживать. VV> Все остальное - второстепенная шелуха.

Человек тебе рассказывает про _собственный_ опыт. Этот опыт говорит о том, что на Форте получаются удобные и сопровождаемые программы, которые в ряде случаев переводят софт в принципиально иной класс. Другими, совершенно независимыми людьми, при схожих методиках работы были получены аналогичные результаты.

Hello Artem.

AK> íÁ-ÁÌÅÎØËÏÅ ÄÏÐÏÌÎÅÎÉÅ - ÐÏ ÐÒÏÂÅÌØÎÙÍ ÓÉÍ×ÏÌÁÍ. á ÉÍÉ ÍÏÇÕÔ ÂÙÔØ AK> ×ÅÓØÍÁ ÒÁÚÎÙÅ ÜÌÅÍÅÎÔÙ - ÎÁÐÒÉÍÅÒ, ×ÓÅÍ ÉÚ×ÅÓÔÎÙÅ ÐÏ óÉ { }

AK> ÉÌÉ ÉÚ×ÅÓÔÎÙÅ ÐÏ äïóÕ ÓÌÅÛÉ ÉÌÉ ÉÚ×ÅÓÔÎÙÅ ÐÏ ÍÁÔÅÍÁÔÉËÅ ÓËÏÂËÉ. åÓÌÉ AK> ÕÞÅÓÔØ, ÞÔÏ ÎÁÂÏÒ ÍÏÖÎÏ ÄÉÎÁÍÉÞÅÓËÉ ÍÅÎÑÔØ, ×ÏÔ ÷ÁÍ É ÉÎÓÔÒÕÍÅÎÔ ÄÌÑ AK> ÒÁÚÂÏÒÁ ÐÏÞÔÉ ÌÀÂÏÊ ÓÔÒÏËÉ.

AK> ðÏÓÌÅÄÎÅÅ ÓÏ×ÓÅÍ ÎÅ ÐÏÎÑÌ :(.

AK> í-ÄÁ. ïÐÉÓÁÎÎÏÅ ÷ÁÍÉ É ÅÓÔØ ÔÏÔ ÃÉÒËÏ×ÏÊ ×ÅÌÏÓÉÐÅÄ, Ï ËÏÔÏÒÏÍ ÇÏ×ÏÒÉÌ AK> ïÒÌÏ×.

HÅÔ, ÜÔÏ É ÅÓÔØ, ÔÏ ÞÔÏ ×Ù ÄÁÌØÛÅ ÒÁÓÐÉÓÙ×ÁÅÔÅ.

AK> óÏ×ÒÅÍÅÎÎÙÅ æÏÒÔ-ÓÉÓÔÅÍÙ (ËÓÔÁÔÉ ÜÔÉÍ ÓÏ×ÒÅÍÅÎÎÙÍ ÕÖÅ ÌÅÔ ÐÏ 10) AK> ÓÍÁÈÉ×ÁÀÔ ÎÁ ÏÐÉÓÁÎÎÏÅ ÷ÁÍÉ ÔÏÌØËÏ ÐÒÏÃÅÎÔÏ× ÎÁ 5.

HÁ ×ÓÅ 100, Õ×Ù :(

AK> HÁÐÒÉÍÅÒ: æÏÒÔ-ÓÉÓÔÅÍÁ ÉÍÅÅÔ Ä×Á ÓÏÓÔÏÑÎÉÑ - ÒÅÖÉÍ ÉÓÐÏÌÎÅÎÉÑ É AK> ÒÅÖÉÍ ËÏÍÐÉÌÑÃÉÉ.

AK> ÷ ÒÅÖÉÍÅ ÉÓÐÏÌÎÅÎÉÑ ÄÅÊÓÔ×ÉÔÅÌØÎÏ ×ÓÅ ÞÔÏ ÐÒÉÛÌÏ ÉÚ ×ÈÏÄÎÏÇÏ AK> ÐÏÔÏËÁ, ÅÓÌÉ ÏÎÏ ÅÓÔØ × ÔÅËÕÝÅÍ ËÏÎÔÅËÓÔÅ, ÉÓÐÏÌÎÑÅÔÓÑ.

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

AK> ÷ ÒÅÖÉÍÅ ËÏÍÐÉÌÑÃÉÉ ×ÓÅ, ÞÔÏ ÐÒÉÛÌÏ ÉÚ ×ÈÏÄÎÏÇÏ ÐÏÔÏËÁ AK> ËÏÍÐÉÌÉÒÕÅÔÓÑ (ÅÓÌÉ ÜÔÏ ÞÉÓÌÏ ÉÌÉ ÏÂÙÞÎÏÅ ÓÌÏ×Ï ÐÒÉÓÕÔÓÔ×ÕÀÝÅÅ × AK> ÔÅËÕÝÅÍ ËÏÎÔÅËÓÔÅ),

AK> á ÐÏ ÐÏ×ÏÄÕ ÔÏÇÏ, ÞÔÏ áÌÇÏÌÏÐÏÄÏÂÎÙÈ ÑÚÙËÏ× ÍÎÏÇÏ, Á æÏÒÔ ÏÄÉÎ - ÔÁË AK> ÄÉÁÌÅËÔÏ× æÏÒÔÁ ÔÏ-ÖÅ ÍÎÏÇÏ. ðÒÉÞÅÍ ÍÎÏÇÉÅ ÉÚ ÎÉÈ ÏÔÌÉÞÁÀÔÓÑ ÄÒÕÇ ÏÔ AK> ÄÒÕÇÁ ËÁË óÉ ÏÔ ðÁÓËÁÌÑ ÉÌÉ íÏÄÕÌÙ.

Roman

Hi Ilia!

IT> äÁ Ñ É ÓÁÍ ÎÅÓËÏÌØËÏ ÕÄÉ×ÉÌÓÑ ÓÉÔÕÁÃÉÉ. ÷ÏÏÂÝÅ-ÔÏ "ÁËÁÄÅÍÉËÉ" - þÅÒÔÏË IT> É éÛÌÉÎÓËÉÊ, × ÐÒÏÛÌÏÍ ÚÁÍÙ ëÏÒÏÌÅ×Á...

Sincerely, Vadim.

Sat Oct 11 2003 23:17, Vladimir Vassilevsky wrote to Ilia Tarasov:

IT>> И так тоже бывает. А сам факт увеличения функциональности ассемблерной IT>> команды?

VV> Даже на классических SISC ЯВУ не умеют использовать всей VV> функциональности системы команд процессора.

И почему же? Не потому, что вычислительная модель языка и реализованные в процессоре решения очень далеки друг от друга?

VV> Развитие средств программирования идет по пути удаления языка VV> программирования от машины и приближения его к естественному языку. VV> Hе человек для машины, а машина для человека.

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

VV> Аппаратная реализация циклов типична для DSP. Для этого приходится VV> иметь отдельное физическое устройство cо своей памятью, обслуживающее VV> исключительно циклы. Cохранение/восстановление контекста этого VV> устройства - отдельная задача с большим оверхедом. Да и наличие VV> отдельного VV> специализированного блока на кристалле тоже не бесплатно.

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

Кстати, мы пробовали и регистровые ядра. Для них дольше создается firmware...

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

VV> Давайте не будем смешивать поточные процессоры на КА и реализацию циклов VV> в обычных процессорах c прерываниями и переключением задач.

Хорошо, не будем. Вторая задача у нас все равно решается по принципу "каждой задаче - свое ядро".

IT>> А потом обязательно от этих высокоуровневых способов уйти через IT>> компилятор к низкоуровневым? Почему нельзя процессор поднять до уровня IT>> описания задачи?

VV> 1. Потому, что задач слишком много всяких и очень разных. Hе получится VV> решить хардверно на все случаи жизни.

На все - не надо, я же не филиал Интела... :)

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

И я опять спрошу - зачем героически создавать трудности, уже имея в распоряжении все инструменты и методики работы с ними? Я понимаю - x86, массовая (еще слабо сказано) платформа. Для нее можно и постараться с оптимизирующими компиляторами и изучением методик эффективного программирования. Зачем приравнивать к нему пригоршню микроконтроллеров с разными архитектурами, растактовкой и проч.?

IT>> Внятно - вряд ли здесь. Hа Си/Паскале/ассемблере работа велась довольно IT>> долгое время. Результаты неудовлетворительные - программисты вроде бы IT>> при деле, предметники долго не получают результата.

VV> Hепонятно, ну да ладно :)

Программист? :)

IT>> Matlab+Simulink+автогенерация текстов на Си, которая активно IT>> используется в одном из КБ, где я когда-то работал. Качество средней IT>> удовлетворительности, все, кто работал, отмечают, что ресурсов для IT>> такого подхода требуется больше (но работают, поскольку им все равно IT>> зарплату платят).

VV> 1. Зарплата, помноженная на время разработки - это тоже ресурс, который VV> часто забывают посчитать.

Время разработки как раз очень большое, поскольку одна и та же задача решается за несколько итераций. На ту контору я давно махнул рукой как на источник свежих решений - MicroPC на все случаи жизни, ибо иначе не умеют....

VV> 2. Разница в потребных хардверных ресурсах на 50% как правило, VV> совершенно непринципиальна.

Принципиально то, что после неудавшейся первой итерации последует вторая, а за ней, возможно, и третья. Программист, написав программу, передаст свои требования электронщику, тот нарисует схему, далее будет разработана плата, смонтирована, запущена и передана программисту. Тот запустит на ней созданный софт и пойдет на объект. Нетривиальный объект (если только фирма не нашла тихую нишу и не занимается выпуском модификаций одного и того же изделия на разной элементной базе) внесет свои коррективы, будет пересмотрена его матмодель, это опять Simulink+Matlab, и все по кругу... (Это наблюдения людей, которые оттуда ушли).

VV> 1. Есть такая фирма Pentek, она делает спецвычислители на FPGA и DSP VV> и средства под них. Есть и много других менее известных фирм.

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

VV> 2. Hаверняка эти 4GMAC требуются для какой-то примитивной низкоуровневой VV> операции, которая делается на FPGA или даже на готовом чипсете для VV> сотовой базовой станции (? GrayHill) например.

А ты следил за тредом? Я и говорил про реализацию на FPGA специализированного ядра.

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

VV> Да, недоинструментов и полуинструментов расплодилось много. Дело в том, VV> что хороший прибор стоит настоящих денег...

Дело в том, что хороший прибор покупается только при гарантии того, что нужен именно он. Я прекрасно понимаю, о чем ты говоришь, и довольно часто в реале сталкивался с таким подходом. Вплоть до того, что говорил людям "хорошо, сделайте свою раскладку цены и сроков, раз уж вы лучше меня знаете, что и как надо делать". Суммы в итоге запрашивались несусветные, техническое и программное решение предлагалось в стиле "купим где-нибудь MicroPC помощнее, а там разберемся", самое забавное, что от заказчика требовалось представить _все_ математические модели и соотношения в разрабатываемом изделии (чтобы можно было все набрать в Си). Извините... но этих соотношений в полном объеме нет даже в специальной литературе... :))) Их определение и составляет суть проводимых работ... :))) Так что будем создавать "недоинструменты и полуинструменты", пока инженеры воротят нос и ждут формул...

Кстати, как ты считаешь, использовать в проекте около 15 разных языков, из которых 3 - собственной разработки, это нормально? Я не о себе, но это тоже сотрудник исследовательской организации...

Sat Oct 11 2003 23:03, Roman Khvatov wrote to Ilia Tarasov:

IT>> Кстати, JCXZ ведь прилично способствует уменьшению числа тактов? А IT>> более мощные варианты аппаратной реализации команд цикла?

RK> Угу, только у компиляторов начинаются проблемы с восстановлением структур RK> циклов _задолго_ до выхода на уровень кодогенерации. RK> Разложить уже оптимизированный цикл в команды типа JCXZ проблем не RK> представляет :)

А прямое соответствие конструкций высокого уровня машинному коду не лучше? Зачем все-таки мучаться с ассемблером, далеким от потребностей прикладного программиста?

RK> Система команд тут не при чем - эти оптимизации делаются на уровне RK> промежуточного представления front-end'а и оптимизатора. А он обычно RK> очень далек от системы команд целевого процессора.

...... !!!!!!!!! (См. выше)

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

RK> Я имел в виду любой класический процедурный язык, так что 'почему бы и не RK> С' :)

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

IT>> Абсолютно не кажется! :) Их именно потому и целый выводок, что отличия IT>> косметические - в синтаксисе конструкций.

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

Почему не построили? Были производные, надо на forth.org.ru архивы новостей посмотреть. Впрочем, новая реализация Форта вполне может рассматриваться как производная. Стековая машина и есть стековая машина - от нее много производных не построишь. А производные от процедурных языков различаются в основном синтаксисом и иногда системой типов.

IT>> HDL вобщем-то собирательное название для "Hardware Description IT>> Languages". Так что это все же "язык описания аппаратуры". Причем IT>> конкретные трансляторы, скажем, VHDL, позволяют описывать IT>> электрические соединения на уровне обычных переменных и взаимосвязей IT>> между ними.

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

А что там особенно специфичного? Что переменные привязываются к аппаратным ресурсам? Выражения-то все равно математические. И управляющие конструкции очень схожи с конструкциями ЯВУ.

IT>> Тут много схемотехнических решений, специфичных для конкретных IT>> архитектур ПЛИС. Вкратце могу сказать, что это делается,

RK> Интересно, а как?

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

IT>> Синтаксический анализатор - слова FIND и NUMBER (или есть в словаре, IT>> или нет, но это число).

RK> Это не синтаксический анализатор - это всего навсего управление таблицей RK> символов (оно есть и в обычных компиляторах)

Эта операция просто стоит на месте синтаксического анализатора, если говорить о классическом порядке фаз компиляции. Кстати, обрати внимание - "всего-навсего управление таблицей символов"... и ничего более.

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

RK> Это отслеживает не анализатор (которого нет), а сами слова. Так что RK> контролируемая часть довольно мала :(

Хотя у этой собачки и коротенькие лапки, до пола они все же достают... :))) Это действительно не анализатор, но то, что _исполняет его функцию_. Разве не изящно - не просматривать весь текст в поисках закрывающего then для этого if, а дать возможность конструкции самой проконтролировать себя на корректность. case , например, пишется на самом Форте (800 байт текста), причем его поддержка в базовом словаре не требуется!

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

RK> Hу не настолько все плохо :)

Но времени-то требует. И человека, который уделит специальное внимание разработке этого уникального для задачи языка. У кого-то действительно есть такой опыт... кстати, качество кода, удобство и проч. там абсолютно безупречное?

IT>> Форт по крайней мере является завершенным языком для стековой машины, IT>> и многие вещи в нем не вполне тривиальны.

RK> Ага, и не вполне понятны стороннему наблюдателю :)

Например?

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

RK> Можно, можно на С написать Форт, но надо ли? Если нужен интерпретатор, то RK> есть довольно много готовых.

Просто для интереса - сколько работают в DPMI в нулевом кольце? И сколько из них позволяют делать ассемблерные вставки в нативном 32-битном коде, а также пользоваться SVGA-графикой и делать POSIX-овые вызовы? Когда я начал писать свой транслятор, требования были именно такие. Тогда я ничего не нашел, хотя и спрашивал. А сейчас что-то вдруг все заохали...

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

RK> Так просили интерпретатор - вот вам интерпретатор :)

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

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

RK>> Крайне расточительно.

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

Я для альтеры на AHDL пишу, как подсел на него на MAX+II 7.0, так до сих пор и не слезу никак.

А что, из VHDL никак нельзя использовать ни встроенные блоки ОЗУ, ни распределённое 16-битовое ОЗУ в ячейках? А как же тогда с fifo, стеками, двухпортовым ОЗУ?

RK>> Одинаковый, на той же распределенной памяти.

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

Ну один регистр - понятно. Но ведь банк из 16 регистров можно уложить в ОЗУ 16x8 (16x16, или сколько там надо). Т.е. занять столько же LUT, сколько и для стека на 16 позиций той же ширины. И не надо никаких дополнительных мультиплексоров.

RK>> Hикак - используется выход одного блока памяти.

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

Для аккумуляторно-регистровой арихитектуры даже с "результат назад в регистр или в аккумулятор" достаточно однопортового ОЗУ с линиями DI/DO.

Для регистровой двухадресной достаточно двухпортового ОЗУ с одним портом на чтение и одним портом на чтение/запись. Т.е. "честного двухпортового" ОЗУ более чем достаточно.

Но вот только у альтер нет распределённого ОЗУ и только в самых толстых современных семействах появились сравнительно мелкие блоки ОЗУ. А использовать встроенный блок 128x32 или 256x16 толи как банк РОН, толи как один стек -- как то жалко. Хотя в NIOS-е они сделали "стек банков РОН". Сейчас вот подумалось -- для утилизации "лишней" памяти в блоке ОЗУ в случае стекового процессора можно было бы "раз такого стека много для одного процессора, сделаем четыре". АЛУ одно на всех. Один блок ОЗУ -- стеки данных, другой -- стеки возвратов. Разбить один блок ОЗУ на 4 части по 32x32 (64x16), старшие 2 разряда адреса подать от счётчика номера "текущего процессора". Всё глубоко конвейеризовать и отдать каждому процессору

Для ухода от мультиплексоров (ячейки и, главное, скорость) все "персональные" регистры этих 4 процессоров "закольцевать". Т.е., скажем, указатели стеков данных

Между DP1 и DP0 и между DP0 и DP3 могут быть инкременторы/декременторы, управляемые от соответствующих выходов дешифратора команд (или битов команды), между DP0 и регистром собственно адреса стека RGDP -- тоже сумматор, позволит дотянуться до К-той от верхушки позиции. Очень аккуратно придётся выписывать все пути полей команды, чтобы нужное поле команды каждого процессора подошло к соответствующему операционному узлу в нужный момент. Но поскольку везде всего один слой логики в LUT ячейки, тактовая этих узлов будет практически равна предельной для кристалла. И надо ещё посмотреть, не окажется ли, что эта частота, поделённая на 4, будет ненамного ниже, чем частота одного процессора, имеющего всё монопольно и работающего в однотактовом режиме.

wbr, === Маленькая девочка: -- Хорошо, что я не люблю помидоры! Взрослый: -- а почему? М.д. -- да если бы я их любила, мне пришлось бы их есть, а я их терпеть не могу!

AK> Из отрицательных - в основном психологические факторы. Многие из тех, AK> кто AK> привык работать на сях, изучать Форт не желают. Приводят любые доводы и AK> отговорки, вплоть до самых глупых.

С одной стороны -- неопровержимо.

С другой... Было недавно на телесистемах обсуждение вопроса "почему к avreal нет GUI". В числе прочих на полном серьёзе было высказано мнение, что либо мне лень писать такую оболочку, либо я этого не в состоянии сделать. А все аргументы, которые я привожу за то, что программатор должен быть командной строкой -- это подведение идеологической базы под это дело.

wbr,

AK>>> И про Форт знаешь давно, раньше всех присутствующих, AK>>> да и сам что-то похожее когда-то изобрел...

OR>> И _этого_ (что я сам изобрёл что-то похожее на форт) _я_ OR>> тоже не говорил. OR>> Hо это очень удобно -- приписать мне "общечеловечески некрасивые" OR>> слова и потом разбить меня в пух и прах на этом поле.

AK> "Я наступил на больной мозоль?" (c) Нет, это аллергическая реакция. Если уж взялся цитировать меня, то потрудись поискать цитаты, подтверждающие то, что ты мне приписал.

AK> Да, подтверждаю, стековый процессор и Форт-процессор - одно и то же. AK> "Стековый процессор" - это не любой процессор, у которого есть (хотя бы AK> один) AK> стек. По умолчанию под стековыми процессорами подразумеваются процессоры AK> типов AK> MS0 и ML0 по классификации Купмана, AK>

А если попадётся M*0, но без >R и R> -- это тоже форт-процессор?

А если нет DUP и DROP? Хотя на мой взгляд эти две операции не примитивы форта, а примитивы стековой архитектуры, как и add varA,varB - примитив регистровой архитектуры с развитыми методами адресации, а не примитив a += b языка С.

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

AK> Четырехбитные есть.

Тот процессор (в смысле 1-битовый процессор технологического контроллера) - это _как_бы_ SS0, но вот только у него стек - это стек данных. Глубиной 16 бит. Набор команд

load bit store bit page pagenumber ( переключение страниц битовой памяти ) add++ ( B A -- A and B ) add-+ ( B A -- not A and B) add+- ( и так далее ) add-- or++ or-+ or+- or-- end ( обменять ОЗУ-зону I/O-битов с модулями УСО, перейти к адресу 0 )

Скажешь, это не процессор, а программируемый автомат? Если да, то мне придётся только повторить твоё "А... Опять спор о терминах". Во всей документации на систему этот ТЭЗ назывался Processor Card.

wbr,

p.s. Ещё немного -- хоть и из переписки других, но мои ответы тут тебе, а не IT и RK.

IT> Мне кажется, что с теоретической точки зрения IT> над стеком может быть надстроена система команд, не включающая в себя IT> базовые операции, предусмотренные в Форте. Или "включающая в себя не все". Или часть из них придётся сооружать из нескольких команд процессора.

IT> В этом случае стековый процессор не будет IT> являться Форт-процессором. А раз "с теоретической точки зрения может", то "практически не встречал" не есть синонимом "не может быть".

IT> Если же возможности стековой машины позволяют IT> реализовать транслятор Форта, то это Форт-процессор. Возможно, так... Т.е. форт-процессор, это невиртуальная стековая машина, полностью отвечающая форту по набору примитивов и позволяющая запустить форт на себе.

RK> Мне кажется, что такой вещи, как Форт-процессор вообще не существует. RK> Форт это RK> не язык програмирования и не тип архитектуры, а _система_ програмирования. RK> И если из этой системы убрать любую часть - она перестанет быть Форт RK> системой. То RK> есть процессор для Форта нельзя рассматривать в отрыве от того, что RK> будет на нем крутиться. Вот!

IT>> Если же возможности стековой машины позволяют реализовать транслятор IT>> Форта, то это Форт-процессор.

RK> Практически на любой стековый процессор можно поставить Форт. RK> Hа любой не стековый процессор можно поставить Форт. И для вообще любого процессора можно соорудить ЦК, который будет готовить для него исполняемый файл для достаточно широкого класса форт-программ.

AK> стека не менее 200 байт, не говоря уж об остальных ресурсах. Еле-еле все AK> вместе влезло на H8S. Узнай разницу в цене между ПИКом и H8S, и спроси AK> себя - на что эти деньги потрачены?

Кстати, хотел уже когда-то спросить, но всё не решался... А сейчас вот под шумок спрошу.

Артём объяснил, почему он пишет для однокристалок на асме, а не на форте.

AK> вроде как указал - средняя задача и выше. Вот в 8515 или Мега8 уже можно AK> развернуться, а в 2313, Тини12, Тини15, Тини26 необходим полный контроль AK> за кодом и любой отсебятины со стороны компилятора допускать нельзя.

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

А почему тобой для H8S пишется не на форте? Кристалл ведь достаточно толстый, даже небольшая RTOS, AFAIR, влезла. Можно было бы зарядить в ПЗУ ядро форта, в ОЗУ складывать только свежеотлаживаемые слова, по мере отладки переписывать в ПЗУ.

Я что-то не понял?

wbr,

DO> Оказалось, что ты просто трепло. В 74 Пике нет 200байтового стека, и DO> написать такой драйвер он ну никак не мог.

Дима, ну нельзя же аж так невнимательно читать. Разве что только при большом желании.

Мне, например, при прочтении "случая из практики" ничего другого кроме

Тот коллега написал на С тот же протокол, что AK делал на асме для PIC16C74. Но _не_для_ PIC, а для H8S. Где оно и заняло эти 200 байт на стеке.

и в голову не пришло.

DO> При реализации одного и того же алгоритма на DO> С и на ассемблере перерасход ОЗУ - максимум пара байт (если не бит).

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

AK> Ась как загнул - понял с третьего раза :).

AK> А кто сказал, что на мелких задачах (<1к асм кода) форт компактнее асма? AK> Я же AK> вроде как указал - средняя задача и выше. Вот в 8515 или Мега8 уже можно AK> развернуться, а в 2313, Тини12, Тини15, Тини26 необходим полный контроль AK> за кодом и любой отсебятины со стороны компилятора допускать нельзя. Тут ведь важно не сколько конкретно заняло, в влезло/не влезло и сколько осталось на расширение. Ну и "гистерезис" работает, о котором я писал в другом треде. Т.е. пороги asm|c|c++ не жесткие и не "мгновенные". Я вот недавно в тини26 одну приблуду засовывал. Лет 5-6 назад я такое писал бы безусловно на асме. Потому что в основном на нём и писал. Сейчас написал на C. Потому, что сейчас в основном на нём пишу. Заняло что-то около 1k из двух имеющихся. По прикидке даже если туда затолкать разжатие ADPCM, то всё равно останется достаточно много свободного места. Если бы оно было написано на асме -- то было бы ощутимо меньше, поскольку многие переменные разложились бы в регистры "навсегда", кое-что просто совсем по-другому писалось бы. Но оно с запасом влезло и так, меньшего кристалла с нужными возможностями всё равно нет (у tiny15 мало ног). Кстати, кажется есть таки C-компилятор, который генерирует код для "беспамятных" 90s1200, t15. Да, это "не совсем С", но я и так не использую функций с переменным числом аргументов и рекурсию. В этом коде нельзя будет использовать и указатели. Хотя где-то я на 90s1200 пользовался адресацией регистров через Z, так что... Зато С-компилятор может построить дерево вызовов и локальные переменные разместить в на регистрах в перекрытием, использовать оверлеи данных, "компилированный стек" вместо "нормального". И это может оказаться проще, чем вручную отслеживать когда какой регистр свободен, а проигрыш по коду будет небольшой. Или вообще не будет, так как хороший С-компилятор может ещё и подсчитать, к какой переменной сколько раз надо применять операции, которые возможны только на верхних регистрах, и "правильно" разложит дерево по регистрам.

AK> Можно, конечно AK> сделать целевой Форт-асм, но это будет все равно асм, Ну С вроде как сделали (если это мне не приснилось), причём он таки С, хоть и ограниченный, а не асм. Почему с фортом так нельзя? Впрочем, C в данном случае легче. При укладке дерева аргументы каждой подпрограммы ложатся в конкретные регистры в положении "максимально глубоком" для данной подпрограммы. При вызове вместо традиционного занесения в стек просто заносится в эти регистры, потом при необходимости переносится в другие регистры для другой подпрограммы. Сделать то же самое в ЦК форта можно, но "наступив на горло собственной песне".

AK> Скорость написания и отладки существенно увеличивается на системах с AK> терминалом AK> (где можно запустить полноценную Форт-систему) - для меня это персоналка. Ну так и в упомянутой 8515 развернуться-то вроде бы и есть где, но засунуть форт в неё боюсь будет трудновато. Маловато места для создаваемого словаря. А вот на С у меня для 90ы4433 скорость написания и отладки выросла по сравнению с асмом. Причём обработку рамки SLIP я вообще не писал с нуля -- дёрнул из проекта на BorlandC (там на другом конце был MCS51 и эта часть была на асме) и слегка модифицировал (побайтная работа в ISR вместо прохода указателем по прочитанному из hComm куску). Ну а уж работу с u16 ref[6]; u32 light[3]; u32 level[3]; flash float corr_coeffs[4] = { ну тут числа всякие были }; так и вообще на С было проще написать, чем на асме. И влезло в 90s4433.

Ну так что, нашлось место, где по твоему мнению форт не даёт выиграша перед асмом, а С по моему мнению дал? :-)))))

wbr,

AS> И они в чем то правы. Шитый код был давно. Потом пришел форт и другие [...] AS> идея о шитом коде она как правило базируется на Форте - как наиболее AS> продвинутом в данном направлении. Возможно. Собственно, я с тобой не очень и спорю, твоё "как правило" оставляет возможность меня, а безальтернативное "шитый код -- это форт или его имитация" говорит что я не существую. "почувствуйте разницу".

AS> Неправда это. Компьютеры тех давних времен имели машинный язык не очень AS> то AS> приспособленный для шитого кода. Когда же начали появляться те самые AS> "программисты AS> на асме" (то есть с появлением мелкопроцессоров, ибо для старых больших AS> машин AS> эти "пна" назывались просто программистами или системщиками) то форт уже AS> существовал и плоды свои приносил. Это _можно_ назвать недостатком образования. У нас на радиофизическом факультете весной 1980 года один семестр "как-бы-программирования" был на алголе и вычпрактикум летом в пакетном режиме afair, на M4030-1. А потом ничего на эту тему не было (ну не кибернетики) до распределения по лабораториям на курсовой, где и можно было на живом компе поработать (кому на каком повезло). У нас на СОУ-1 в наличии был асм и фортран, по возможности предпочтение отдавалось асму. Несколько позже появились ДВК, там уже был ещё и С и паскаль. Форт-то в это время существовал, но у нас его не было и я о нём не слышал, узнал о нём уже в начале 90-х, когда на PC пересел (см выше про то, как это можно назвать, но тем не менее). Но при этом шитый (в меру, так как при писании на ассемблере нет нужды мелкие редко повторяющиеся действия писать в виде подпрограмм и только при "оптимизации" вставлять их по месту) код как-то сам собой возник при желании сократить объёмы. Честно говоря, я не считаю себя прям таким выдающимся, что вот мне в голову пришло что-то такое, что другим не могло. Именно поэтому выше в "ДОЛЖНА была родиться" есть выделение большими буквами.

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

wbr,

Hi Roman,

Sat Oct 11 2003 23:23, Roman Khvatov wrote to Alex Kouznetsov:

AK>> У языка Форт есть несколько преимуществ: AK>> -- Компилятор с Форта намного проще, чем компилятор с С,

RK> И намного хуже в плане оптимизаций.

Обоснуй.

Современные быстрые Форты без особого труда уделывают большинство С компиляторов. Пример с SPF и VC7 я приводил, есть и другие примеры.

RK> Или для Форта это неважно - RK> програмист и так на нем оптимально пишет, вместо оптимизатора :) ?

AK>> особенно если целевой проц - Форт-процессор.

RK> И где они?

Неполный список кремниевых на

AK>> Программы на Форте пишутся и отлаживаются примерно в 2-3 раза быстрее AK>> чем на С.

RK> Да ну? Есть реальные примеры?

Начни, скажем, с этого:

AK>> -- Программы на Форте компактнее чем на С.

RK> Видимо потому что сильно меньше по функциональности :)

Я уже говорил, от противников Форта каких только глупостей не услышишь...

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

Sun Oct 12 2003 03:52, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR> А почему тобой для H8S пишется не на форте?

Велено было писать на це, "для совместимости" и пр. Я дисциплинированный человек, подчиняюсь приказам. Даже глупым.

OR> Кристалл ведь достаточно OR> толстый, даже небольшая RTOS, AFAIR, влезла.

Небольшая самодельная влезла, на це написал.

OR> Можно было бы зарядить в ПЗУ ядро форта, OR> в ОЗУ складывать только свежеотлаживаемые OR> слова, по мере отладки переписывать в ПЗУ.

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

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

Sunday October 12 2003 02:05, Artem Kamburov wrote to Alexander Torres:

AK> þÔÏ ÚÎÁÞÅÔ "ÔÁËÉÅ ÞÕ×ÓÔ×ÉÔÅÌØÎÙÅ" :). òÅÞØ Ï ×ÅÒÈÎÅÊ ÐÌÁÎËÅ ÕÒÏ×ÎÑ ÎÕÌÑ. AK> õÍÅÎØÛÅÎÉÅ ÅÅ ÎÁ ÐÏÌ ×ÏÌØÔÁ ÜË×É×ÁÌÅÎÔÎÏ ÕÍÅÎØÛÅÎÉÀ ÷ ÐÏÌÔÏÒÁ ÒÁÚÁ (0,7 - AK> ÐÏÞÔÉ × Ä×Á). ëÒÏÍÅ ÔÏÇÏ, ÅÍËÏÓÔÉ ÒÁÚÒÑÖÁÀÔÓÑ ÐÏ ÜËÓÐÏÎÅÎÔÅ, Á ÏÎÁ ÞÅÍ AK> ÎÉÖÅ ÔÅÍ ÐÏÌÏÖÅ. ÷ÏÔ É ÐÏÌÕÞÁÅÔÓÑ "ÞÕ×ÓÔ×ÉÔÅÌØÎÏÓÔØ" :(.

AK> åÓÌÉ ÁÌØÔÅÒÎÁÔÉ×Á - ÞÅÔÙÒÅ ÌÉÛÎÉÅ ÎÏÇÉ ÐÒÏÃÅÓÓÏÒÁ, Ñ ÐÒÅÄÐÏÞÅÌ ÂÙ ×ÙÌÉÚÁÔØ AK> ÓÈÅÍÕ É ÐÒÏÇÒÁÍÍÕ :-|.

AK> èÍ... åÓÌÉ Ñ ÐÒÉÄÕ Ë ÛÅÆÕ É ÓËÁÖÕ, ÞÔÏ ×ÏÔ ÎÁÄÏ ÐÒÉÏÂÒÅÓÔÉ ÐÒÉÂÏÒ, AK> ÂÌÁÇÏÄÁÒÑ ËÏÔÏÒÏÍÕ ×ÏÚÍÏÖÎÏ ×ÅÓØ ÐÒÏÃÅÓÓ ÒÁÚÒÁÂÏÔËÉ ÓÉÓÔÅÍÙ ÓÔÁÎÅÔ ËÏÒÏÞÅ AK> ÎÁ ÎÅÄÅÌÀ, ÏÎ ÍÅÎÑ ÎÅ ÐÏÊÍÅÔ :-\. åÍÕ ÂÕÄÅÔ ÐÒÏÝÅ ÏÐÌÁÔÉÔØ (ÐÏÄÏÖÄÁÔØ) ÜÔÉ AK> ÓÅÍØ ÄÎÅÊ ÞÅÍ ËÕÐÉÔØ ÜÍÕÌÑÔÏÒ.

AK>

AK> õ ÎÁÓ, ×ÅÒÏÑÔÎÏÓÔØ ÕÓÐÅÈÁ ÓÉÓÔÅÍÙ ÐÒÏÃÅÎÔÏ× ÎÁ 50 ÚÁ×ÉÓÉÔ ÏÔ ÔÏÇÏ, AK> ÐÏÎÒÁ×ÉÔÓÑ ÌÉ ÏÎÁ ÕÓÔÁÎÏ×ÝÉËÁÍ (ÎÅ ÏËÁÖÅÔÓÑ ÌÉ ÓÌÉÛËÏÍ "ÎÁ×ÏÒÏÞÅÎÎÏÊ" É AK> "ÔÑÖÅÌÏÊ"). ðÏÜÔÏÍÕ ÞÅÍ ÒÁÎØÛÅ ÓÉÓÔÅÍÁ ÐÏÐÁÄÅÔ Ë ÎÉÍ × ÒÕËÉ, ÔÅÍ ÒÁÎØÛÅ ÍÙ AK> ÐÏÌÕÞÉÍ ÏÃÅÎÏÞÎÙÊ ÒÅÚÕÌØÔÁÔ É ÐÒÉ ÎÅÏÂÈÏÄÉÍÏÓÔÉ ÍÏÖÅÍ ÓÉÓÔÅÍÕ ÐÏÄÐÒÁ×ÉÔØ AK> (ËÓÔÁÔÉ, ÉÎÏÇÄÁ ÏÎÉ ÄÁÀÔ ÄÅÌØÎÙÅ ÓÏ×ÅÔÙ).

AK> ðÏÌÎÏÓÔØÀ ÓÏÇÌÁÓÅÎ.

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

Sunday October 12 2003 03:52, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR> âÙÌÏ ÎÅÄÁ×ÎÏ ÎÁ ÔÅÌÅÓÉÓÔÅÍÁÈ ÏÂÓÕÖÄÅÎÉÅ ×ÏÐÒÏÓÁ "ÐÏÞÅÍÕ Ë avreal ÎÅÔ OR> GUI". ÷ ÞÉÓÌÅ ÐÒÏÞÉÈ ÎÁ ÐÏÌÎÏÍ ÓÅÒأÚÅ ÂÙÌÏ ×ÙÓËÁÚÁÎÏ ÍÎÅÎÉÅ, ÞÔÏ ÌÉÂÏ ÍÎÅ OR> ÌÅÎØ ÐÉÓÁÔØ ÔÁËÕÀ ÏÂÏÌÏÞËÕ, ÌÉÂÏ Ñ ÜÔÏÇÏ ÎÅ × ÓÏÓÔÏÑÎÉÉ ÓÄÅÌÁÔØ. á ×ÓÅ OR> ÁÒÇÕÍÅÎÔÙ, ËÏÔÏÒÙÅ Ñ ÐÒÉ×ÏÖÕ ÚÁ ÔÏ, ÞÔÏ ÐÒÏÇÒÁÍÍÁÔÏÒ ÄÏÌÖÅÎ ÂÙÔØ ËÏÍÁÎÄÎÏÊ OR> ÓÔÒÏËÏÊ -- ÜÔÏ ÐÏÄ×ÅÄÅÎÉÅ ÉÄÅÏÌÏÇÉÞÅÓËÏÊ ÂÁÚÙ ÐÏÄ ÜÔÏ ÄÅÌÏ.

HÁÉÂÏÌÅÅ ÕÄÏÂÎÏ - ËÏÇÄÁ ÐÒÏÇÒÁÍÍÁÔÏÒ ÕÍÅÅÔ É ÔÁË É ÔÁË.

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

Sat Oct 11 2003 21:43, Ilia Tarasov wrote to Yuriy K:

IT>>> ëÒÏÍÅ ÒÅÁÌÉÚÁÃÉÉ ÆÒÁÇÍÅÎÔÁ áìõ YK>> óÔÒÁÎÎÏ, ÞÔÏ ÔÙ ÎÅ ÐÏÎÉÍÁÅÛØ ÒÁÚÎÉÃÙ ÍÅÖÄÕ ÐÒÏÃÅÓÓÏÒÎÙÍ ÑÄÒÏÍ É YK>> ÆÒÁÇÍÅÎÔÏÍ áìõ.

IT> ñ ÔÅÂÅ ÎÁËÉÄÁÌ ÐÅÒ×ÏÅ ÐÏÐÁ×ÛÅÅÓÑ ÎÁ ÄÁÎÎÕÀ ÔÅÍÕ.

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

IT> ðÒÉ×ÏÖÕ: proc.c ÉÚ ÐÒÉÍÅÒÏ× Handel-C 2.1 ÏÔ Celoxica. òÁÚÍÅÒ ÆÁÊÌÁ ÞÔÏ-ÔÏ IT> ÏËÏÌÏ 8 ËÂ. ðÒÏ HDL ÞÅÔ×ÅÒÔÏÇÏ ÐÏËÏÌÅÎÉÑ É ÉÈ ×ÏÚÍÏÖÎÏÓÔÉ ÎÁÊÄÉ ÍÁÔÅÒÉÁÌÙ IT> ÓÁÍÏÓÔÏÑÔÅÌØÎÏ.

IT>...> ñ, ×ÉÄÉÛØ ÌÉ, ÉÍÅÎÎÏ ÚÁ ÐÏÌÞÁÓÁ ÐÒÏÅËÔÉÒÏ×ÁÌ É ÚÁÏÄÎÏ ÏÓ×ÁÉ×ÁÌ IT>...> ÐÒÏÃÅÓÓÏÒÎÙÅ ÑÄÒÁ × ðìéó ÐÏ ÏÂÝÉÍ ÔÒÅÂÏ×ÁÎÉÑÍ.

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

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

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

YK>> ëÏÍÐÉÌÉÒÏ×ÁÔØÓÑ ÎÅ ÂÕÄÅÔ, ÐÏÜÔÏÍÕ É ÏÂÓÕÖÄÁÔØ ÎÅÞÅÇÏ.

IT> HÕ ÔÁË ÜÔÏ ×ÓÅ ÖÅ ÓËÏÍÐÉÌÉÒÕÅÔÓÑ æÏÒÔÏÍ, ÐÏÓËÏÌØËÕ ËÕÓÏË ÎÁÐÉÓÁÎ ÉÍÅÎÎÏ IT> ÎÁ ÎÅÍ.

IT> éÔÏÇÏ ÔÙ ÍÎÅ ÔÁËÖÅ ÎÁÄÏÅÌ,

IT> É Ñ ÐÒÏÓÔÏ ÎÅ ÈÏÞÕ ÎÅÕ×ÁÖÉÔÅÌØÎÏ IT> ÏÔÎÏÓÉÔØÓÑ Ë ÐÉÓØÍÁÍ, ÇÄÅ ÍÎÅ ÓÏ×ÅÔÕÀÔ "ÉÇÎÏÒÉÒÏ×ÁÔØ ËÏÌÂÁÓÎÙÈ IT> ÜÍÉÇÒÁÎÔÏ×"...

WBR, àÒÉÊ.