_Loader_

Sep 13, 2003 Last reply: 22 years ago 731 Replies
12-Oct-03 17:02 Vladimir Vassilevsky wrote to Vladislav Baliasov:

Я одним письмом сразу обоим - "чтобы два раза не вставать". Тем более, что это с моей точки зрения один ответ.

OR>>> Более того.. Мне даже тяжело понять -- чем может быть хорош отдельный OR>>> GUI программатора (отдельный от среды разработки).

VB>> Hу, оболочка с hex/ascii редактором может быть полезна на предмет VB>> поковыряться с содержимым EEPROM (в том числе и "набортным" EEPROM VB>> микроконтроллера, либо с секциями данных прошивки). Hо и только, IMHO. Ну и пусть этот редактор будет в том софте, с которым человек _работает_. avreal по смыслу не предназначен для _регулярной_ ручной работы, он предназначен для встраивания в кому-какой-удобнее процесс автоматизации. Если мне надо будет поковыряться в EEPRОМ, я открою HEX-файл в MED-е. Собственно, мне за всё время это надо было только один единственный раз, в результате чего avreal научился игнорировать пробелы в HEX-файлах, комментарии в них же и (только по запросу) контрольные суммы.

Дальше пошли спекуляции, так как всё, что начинается с "если бы" -- это уже "не совсем то". Если бы мне это надо было очень часто, каждый день и по многу... Ну не знаю. Скорее всего надо было бы думать о программе в духе когда-то бегавшей (если я правильно помню имя) stl -- могла показывать бинарную информацию в нужном виде (фактически, в виде структур/записей), чтобы не ковыряться в "сырых" байтах вручную.

IMHO функцию редактирования EEPROM должна выполнять IDE программиста, аналогично тому, как можно в симуляторе посмотреть память не только в бинарном виде, но и в виде значений находящихся там переменных. Информацию о размерах (и типах, если ассемблер позволяет) неплохо бы выдёргивать из

.section .eeprom bbb: .byte 0 fff: .single 3.1415926

Итого, на мой взгляд, помещение двоичного редактора в программатор - это костыли, призванные как-то спасти ситуацию с IDE, не поддерживающими то, что надо. Хотя для этого и GUI как таковой не обязателен, текстового режима достаточно :-), визуальные редакторы появились достаточно давно... Причём это навешивание на программатор чужой ему функции редактора, при том, что в IDE уже есть редактор, в симуляторе есть двоичный редактор.

Лучше пусть IDE хорошо выполняет свои функции, а программатор не берёт на себя функции IDE. Начнётся с редактирования прошивок в программаторе, а закончится необходимостью поддерживать coff/ubrof/avrobj и симулировать кристалл :-)

VV> Есть еще одно преимущество: намного приятнее выбирать соответствующие VV> галочки в GUI, чем читать мануал Хех, а почему же тогда даже я (ни разу не запускавший пони-прог) знаю, что у него "галочка стоит -- это 0, а не то, что вы подумали" :-) Тут вот по соседству у одного проблемы с "нечтением по SPI" у 89s8252, а другой ему что он на эти грабли (???) на 90s8515 наткнулся и выяснил (!!!), что для этого надо писать в регситр SPI что-нибудь. Это я к тому, что не читать мануал вообще всё равно не выйдет.

VV> и вписывать в батник десяток фьюзов и прочих опций.

Аналогично. Я нажимаю Ctrl-F9 не в avreal-е, а в MED-е. Как я уже говорил на телесистемах: пользоваться _двумя_ GUI-программами -- редактором исходных текстов с вызовом компиляции, отслеживанием сообщений об ошибках, ... т.е. какой-никакой IDE И программатором -- мне лично неудобно.

А фьюзы я выставляю один раз на проект, когда его завожу. В MED-е в makefile пишу FUSES=-fтра-ля-ля и всё. CPU=atmega8 всё равно там указано для компилятора. Имена выходных файлов тоже в makefile присутствуют в неявном виде, иначе бы make не знал, что ему делать. Всё. Мне это *гораздо* удобнее, чем лазить каждый раз по меню отдельной программы для выбора файла и т.п. Если работать не через makefile, а через оболочку тира того же AVRstudio, то всё аналогично. Там всё равно выбирается тип кристалла, имя проекта, оболочка это всё уже знает. Вот пусть там и fuses устанавливаются, и содержимое EEPROM редактируется. Пусть, раз она INTEGRATED, занимается интерфейсом с программистом. И передаёт что надо программатору. А программатор пусть делает свою работу. Тут, правда, возникает вопрос как передать сами fuse (с процессором проще, это одно имя и его можно подставить через %CPU% или где как в командную строку tools подставляются параметры проекта). Ну так это дело в любом случае поправимое. Стал же avreal (кажется, по просьбе Алексея Бойко) поддерживать имена не только в виде 90s8515, но и at90s8515, чтобы проще было в makefile для gcc вставлять вызов.

VV> Кстати, предложение к AVREALу: фьюзы и локбиты хорошо бы показывать VV> после, а не до программирования. Хорошо.

VB>> Однако если VB>> программатор "заточен" именно под микроконтроллеры - отсутствие GUI не VB>> напрягает совершенно. Скорее даже радует :)

VV> Это просто ты - человек старой закалки :) VV> Среди новых инженеров бытует мнение, что софт без GUI бесмысленнен VV> и бесполезен. В чем-то они правы. Если имеется ввиду то, с чем человек непосредственно работает, то да, хороший UI нужен. Но avreal писался в соответствии с моими привычками в качестве тулзы нижнего уровня, не зависящей от того, что я сейчас выбрал в качестве UI. И успел пожить и под QEdit в dos-окне OS/2, сейчас живёт под MED, на работе на соседнем столе -- под AVRstudio. Было бы это возможно, если бы у него был свой собственный UI?

Wbr,

Sun Oct 12 2003 03:52, Oleksandr Redchuk wrote to "Ilia Tarasov":

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

Altera и Xilinx , имхо, делают вполне паритетную продукцию.

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

Можно, практически все специализированные устройства. Вопрос только в том, что от соответствия шаблону все зависит довольно сильно. Вот распределенная двупортовая память:

====================================================================== entity dpdistram is port (clk : in std_logic; we : in std_logic; a : in std_logic_vector(4 downto 0); dpra : in std_logic_vector(4 downto 0); di : in std_logic_vector(3 downto 0); spo : out std_logic_vector(3 downto 0); dpo : out std_logic_vector(3 downto 0)); end dpdistram; architecture syn of dpdistram is type ram_type is array (31 downto 0) of std_logic_vector (3 downto 0); signal RAM : ram_type; begin process (clk) begin if (clk'event and clk = '1') then if (we = '1') then RAM(conv_integer(a)) <= di; end if; end if; end process; spo <= RAM(conv_integer(a)); dpo <= RAM(conv_integer(dpra)); end syn; ======================================================================

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

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

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

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

OR> А почему сразу трёхадресаня система команд? "Чтобы невозможнее было"?

Чтобы упростить жизнь оптимизатору.

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

Да... Получится КА с программным управлением :)

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

Я такое уже пронаблюдал. Действительно, все так и есть, читать можно из любых регистров, и писать тоже в любой. Однако работать с таким процессором сможет только его автор :) Систему команд надо все же чем-то ограничить, иначе при последующей отладке всего устройства может появиться мешанина из правок в прикладной программе, в компиляторе/ассемблере и в самом процессоре. С Фортом именно у нас так сложилось, поэтому я и привожу его в качестве примера. А вообще в ПЛИС можно сделать практически любое процессорное устройство, в пределах разумного...

OR> Hо вот только у альтер нет распределённого ОЗУ и только OR> в самых толстых современных семействах появились сравнительно OR> мелкие блоки ОЗУ. OR> А использовать встроенный блок 128x32 или 256x16 толи как банк OR> РОH, толи как один стек -- как то жалко. OR> Хотя в NIOS-е они сделали "стек банков РОH".

Альтера от Xilinx отличается вобщем-то двумя моментами. Распределенная память и внутренние Z-буферы. Xilinx делает и то, и другое, Altera - нет. У альтеры получаются меньшие задержки, но в ряде случаев без таких возможностей оказывается тяжеловато. Эти различия тоже бывают предметом Holy wars, хотя на фоне всех остальных причин выбора той или иной фирмы это все очень несущественно и влияет разве что на выбор стиля проектирования... Для альтеры я, наверное, делал бы иначе и не все бы упиралось именно в возможности распределенной памяти.

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

Оооо! :)))) Это к Ивану Макарченко (Ivan Mak), уже не помню его домашний сайт, но можно поискать на

formatting link
информацию по компьютеру "Спринтер". Именно такой процессор на альтере он и разработал, и тоже под Форт.

Hello Artem.

12 Oct 03 14:08, you wrote to me:

é ÞÔÏ, ÏÎ ÏÔÌÉÞÉÔ ÏÄÉÎ ÐÒÏÂÅÌ ÏÔ Ä×ÕÈ?

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

á ÅÓÌÉ ÎÅÔ ÔÏÇÏ, ÞÅÍ ÒÁÚÄÅÌÅÎÙ ËÏÎÓÔÒÕËÃÉÉ? ÷ ÔÏÍ ÖÅ C {} ÜÔÏ ÎÅ ÐÒÏÓÔÏ ÒÁÚÄÅÌÉÔÅÌÉ, Á ÞÁÓÔØ ÓÉÎÔÁËÓÉÓÁ.

AK> õÇÕ, É ËÏÍÐÉÌÑÃÉÑ ÔÏÖÅ?

äÁ.

AK> é ÐÏÓÌÅ ËÏÍÐÉÌÑÃÉÉ ÔÏÖÅ?

äÁ.

AK> : INTERPRET_ ( -> ) \ ÉÎÔÅÒÐÒÅÔÉÒÏ×ÁÔØ ×ÈÏÄÎÏÊ ÐÏÔÏË AK> BEGIN AK> NextWord DUP \ ÔÕÔ ×ÙÄÅÌÑÅÍ ÓÌÏ×Ï AK> WHILE AK> SFIND ?DUP \ ÔÕÔ ÅÇÏ ÎÁÈÏÄÉÍ AK> IF AK> STATE @ = \ ÚÄÅÓØ ÐÒÏ×ÅÒËÁ ËÏÍÐÉÌÉÒÏ×ÁÔØ/ÉÓÐÏÌÎÉÔØ AK> IF COMPILE, ELSE EXECUTE THEN AK> ELSE AK> S" NOTFOUND" SFIND AK> IF EXECUTE \ ÚÄÅÓØ ÒÁÚÂÏÒ ËÏÎÓÔÒÕËÃÉÊ AK> ELSE 2DROP ?SLITERAL THEN \ ÚÄÅÓØ ÒÁÂÏÔÁ Ó ÞÉÓÌÁÍÉ AK> THEN AK> ?STACK AK> REPEAT 2DROP AK> ;

AK> üÔÏ ×ÏÔ ÜÔÏ ÷Ù ÎÁÚÙ×ÁÅÔÅ ÉÎÔÅÒÐÒÅÔÁÔÏÒÏÍ?

äÁ.

AK> ëÁË ×ÉÄÉÔÅ ÉÓÐÏÌÎÑÅÔ ÎÅ ÉÎÔÅÒÐÒÅÔÁÔÏÒ, Á EXECUTE :).

éÓÐÏÌÎÑÅÔ ÉÍÅÎÎÏ ÉÎÔÅÒÐÒÅÔÁÔÏÒ, Á ÔÏ, ÞÔÏ ÏÎ ÄÌÑ ÓÏÂÓÔ×ÅÎÎÏ ÚÁÐÕÓËÁ ÉÓÐÏÌØÚÕÅÔ ÓÌÏ×Ï EXECUTE - ÅÇÏ ×ÎÕÔÒÅÎÎÅÅ ÄÅÌÏ.

AK> é ËÏÍÐÉÌÉÒÕÅÔ ÎÅ ÉÎÔÅÒÐÒÅÔÁÔÏÒ, Á COMPILE, :).

áÎÁÌÏÇÉÞÎÏ.

AK> HÅÔ, ÔÏÌØËÏ × ÓÌÏ×Á ÏÂÅÓÐÅÞÉ×ÁÀÝÉÅ ÓÅÍÁÎÔÉËÕ (IF THEN REPEAT BEGIN). AK> üÔÉ ÓÌÏ×Á ÉÚÎÁÞÁÌØÎÏ ÐÒÅÄÏÓÔÁ×ÌÅÎÙ æÏÒÔÏÍ É ÍÏÖÅÔÅ ÉÈ ÓÞÉÔÁÔØ ÞÁÓÔØÀ AK> ÉÎÔÅÒÐÒÅÔÁÔÏÒÁ :). ëÓÔÁÔÉ, ÅÓÌÉ ÂÙ óÉ ÏÔËÒÙÌÏ Ó×ÏÉ ÐÒÏÃÅÄÕÒÙ AK> ÏÂÅÓÐÅÞÉ×ÁÀÝÉÅ ÓÅÍÁÎÔÉÞÅÓËÉÊ ÁÎÁÌÉÚ, ÷Ù ÂÙ ÎÅ ÐÅÒÅÓÔÁÌÉ ÉÈ ÓÞÉÔÁÔØ AK> ÞÁÓÔØÀ ËÏÍÐÉÌÑÔÏÒÁ óÉ :).

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

÷ÙÛÅÐÒÉ×ÅÄÅÎÎÙÊ ÐÒÉÍÅÒ Ó ÌÉÛÎÉÍ DROP.

AK> ðÏÐÒÏÂÕÊÔÅ × ÐÒÉÍÅÒÅ ÓÌÏ×Ï WHILE ÐÏÍÅÓÔÉÔØ ÎÁ Ä×Å ÓÔÏËÉ ÎÉÖÅ (ÐÏÓÌÅ AK> IF) É ÐÏÓÍÏÔÒÉÔÅ ËÁË æÏÒÔ ÎÁÞÎÅÔ ÒÕÇÁÔØÓÑ.

á ÆÒÁÚÕ 'ÚÁ ÉÓËÌÀÞÅÎÉÅÍ ÔÅÈ ÓÁÍÙÈ IMMEDIATE' ×Ù ÐÒÏÉÇÎÏÒÉÒÏ×ÁÌÉ? üÔÉ ÓÌÏ×Á ÓÁÍÉ ÏÓÕÝÅÓÔ×ÌÑÀÔ ËÏÎÔÒÏÌØ. ðÏÒÏÂÕÊÔÅ ÐÅÒÅÓÔÁ×ÉÔØ 2DROP ?SLITERAL - ÞÔÏ ×ÁÍ ÓËÁÖÅÔ æÏÒÔ?

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

÷Ù ÍÏÖÅÔÅ (ÎÅÐÒÅÄÎÁÍÅÒÅÎÎÏ) ÒÁÚÒÕÛÉÔØ ×ÅÓØ ÜÔÏÔ ËÏÎÔÒÏÌØ.

AK> íÁÌÏ ÔÏÇÏ, æÏÒÔ ÐÏÚ×ÏÌÑÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ ÜÔÉ ÓÒÅÄÓÔ×Á × ËÏÎÅÞÎÏÊ AK> ÐÒÏÇÒÁÍÍÅ (× óÉ ÷ÁÍ ÄÌÑ ÓÏÚÄÁÎÉÑ ÜÔÏÇÏ ÂÌÏËÁ ÎÅÏÂÈÏÄÉÍÏ ÎÁÐÉÓÁÔØ ÅÇÏ AK> Ó ÎÕÌÑ).

óÉ ÎÅ ÐÏÍÅÝÁÅÔ Ó×ÏÊ ÓÏÂÓÔ×ÅÎÎÙÊ ËÏÍÐÉÌÑÔÏÒ Ë ËÏÍÐÉÌÉÒÕÅÍÏÊ ÐÒÏÇÒÁÍÍÅ :)

AK> ñ ÄÕÍÁÀ ÞÔÏ ÔÁËÉÍ ÓÐÏÓÏÂÏÍ ÎÅÌØÚÑ ÓÏÚÄÁÔØ ÎÉ ÏÄÎÏÊ ÕÐÒÁ×ÌÑÀÝÅÊ AK> ËÏÎÓÔÒÕËÃÉÉ (ÔÅ ÖÅ IF THEN REPEAT BEGIN CASE

íÏÖÎÏ [COMPILE] IF , ÔÏÌØËÏ ÚÁÞÅÍ?

AK> \ ( { ." S" .... ÎÉËÁË Hå AK> ËÏÍÐÉÌÉÒÕÀÔÓÑ). ïÐÑÔØ ÐÏ×ÔÏÒÑÀ, ËÏÍÐÉÌÉÒÕÅÔ (ÓËÌÁÄÙ×ÁÅÔ ÁÄÒÅÓ) ÓÌÏ×Ï AK> COMPILE, É ÏÎÏ ×ÓÔÒÅÞÁÅÔÓÑ ÄÁÌÅËÏ ÎÅ ÔÏÌØËÏ × ÉÎÔÅÒÐÒÅÔÁÔÏÒÅ.

ðÏÄ 'ËÏÍÐÉÌÑÃÉÅÊ' Ñ ÐÏÎÉÍÁÀ ÎÅ ÆÉÚÉÞÅÓËÏÅ ÓËÌÁÄÙ×ÁÎÉÅ ÁÄÒÅÓÁ, Á ÐÒÅÏÂÒÁÚÏ×ÁÎÉÅ ÞÁÓÔÉ ×ÈÏÄÎÏÇÏ ÔÅËÓÔÁ × ÏÔËÏÍÐÉÌÉÒÏ×ÁÎÎÕÀ ÐÒÏÇÒÁÍÍÕ. ëÏÎÅÞÎÕÀ ÒÁÂÏÔÕ ÄÅÌÁÅÔ COMPILE, ÎÏ ÄÒÕÇÉÅ ÓÌÏ×Á (× ÔÏÍ ÞÉÓÌÅ ÉÎÔÅÒÐÒÅÔÁÔÏÒ × ÃÅÌÏÍ) ÉÓÐÏÌØÚÕÀÔ ÅÇÏ ÄÌÑ ÐÒÏÃÅÓÓÁ ËÏÍÐÉÌÑÃÉÉ.

AK> íÎÏÇÉÅ ÕÐÒÁ×ÌÑÀÝÉÅ ËÏÎÓÔÒÕËÃÉÉ ÉÍÅÀÔ ÅÇÏ ÉÌÉ ÅÇÏ ÁÎÁÌÏÇ. é ÜÔÏ AK> ÐÒÅÄÏÓÔÁ×ÌÅÎÏ æÏÒÔ-ÓÉÓÔÅÍÏÊ ÉÚÎÁÞÁÌØÎÏ. ô.Å. ÐÏ ÓÕÔÉ ÜÔÏ ÞÁÓÔØ AK> ËÏÍÐÉÌÑÔÏÒÁ, ÎÏ ÐÒÅÄÏÓÔÁ×ÌÅÎÎÁÑ ÷ÁÍ × ÐÏÌØÚÏ×ÁÎÉÅ.

÷ÏÔ ÜÔÏ É ÐÌÏÈÏ - × æÏÒÔ ÓÉÓÔÅÍÅ ×ÓÅ ÔÁË ÔÅÓÎÏ ÐÅÒÅÍÅÛÁÎÎÏ, ÞÔÏ ÎÅÐÏÎÑÔÎÏ, ÇÄÅ ËÏÎÞÁÅÔÓÑ ÉÎÔÅÒÐÒÅÔÁÔÏÒ/ËÏÍÉÐÉÌÑÔÏÒ Á ÇÄÅ ÎÁÞÉÎÁÅÔÓÑ ÐÏÌØÚÏ×ÁÔÅÌØÓËÁÑ ÐÒÏÇÒÁÍÍÁ. ëÒÏÍÅ ÔÏÇÏ, ÐÒÅÄÏÓÔÁ×ÌÅÎÎÙÅ æÏÒÔÏÍ × ÐÏÌØÚÏ×ÁÎÉÅ ×ÏÚÍÏÖÎÏÓÔÉ ×ÅÓØÍÁ ÕÈÕÄÛÁÀÔ ÎÁÄÅÖÎÏÓÔØ ÓÉÓÔÅÍÙ × ÃÅÌÏÍ - ÐÏÌØÚÏ×ÁÔÅÌØ ÍÏÖÅÔ ÎÁÄÅÌÁÔØ ÏÛÉÂÏË, ËÏÔÏÒÙÅ ÎÅ ÔÏÌØËÏ ÐÒÉ×ÅÄÕÔ Ë ÎÅÒÁÂÏÔÏÓÐÏÓÏÂÎÏÓÔÉ ÅÇÏ ÐÒÏÇÒÁÍÍÙ, ÎÏ É ÍÏÇÕÔ ÐÒÉ×ÅÓÔÉ Ë ÎÅÒÁÂÏÔÏÓÐÏÓÏÂÎÏÓÔÉ ÓÁÍÏÇÏ æÏÒÔÁ.

AK> ú×ÕÞÉÔ ÔÁË ÖÅ ËÁË - ×ÓÅ, ÞÔÏ ××ÅÄÅÎÏ × ÐÒÏÇÒÁÍÍÕ ÓÔÁÌÏ ÐÏÂÏÞÎÙÍ AK> ÜÆÆÅËÔÏÍ ÉÓÐÏÌÎÅÎÉÑ ËÏÍÐÉÌÑÔÏÒÁ óÉ :).

÷ ËÁËÕÀ ÐÒÏÇÒÁÍÍÕ É ÞÔÏ ××ÅÄÅÎÏ? óÁÍ ËÏÍÐÉÌÑÔÏÒ ó, × ÏÔÌÉÞÉÅ ÏÔ æÏÒÔÁ, ÎÅ ÖÉ×ÅÔ Ó ËÏÍÐÉÌÉÒÕÅÍÏÊ ÐÒÏÇÒÁÍÍÏÊ ÔÅÓÎÏÊ (ÐÏÌÏ×ÏÊ) ÖÉÚÎØÀ :)

AK> íÏÖÎÏ ÐÏÓÐÏÒÉÔØ, ÞÔÏ ÏÂÁ ÄÉÁÌÅËÔÙ áÌÇÏÌÁ :).

HÅÔ, ÄÉÁÌÅËÔÙ áÌÇÏÌÁ - ÜÔÏ áÌÇÏÌ 60 É áÌÇÏÌ 68.

AK> ïÓÎÏ×ÎÙÅ ÉÈ ÏÔÌÉÞÉÑ -

ïÓÎÏ×ÎÙÅ ÉÈ ÏÔÌÉÞÉÑ - ÜÔÏ _ÒÁÚÎÙÅ_ ÑÚÙËÉ, É ÐÒÏÇÒÁÍÍÙ ÎÁ ÎÉÈ _ÒÁÚÎÙÅ_. ðÒÉ ÓÍÅÎÅ ÄÉÁÌÅËÔÁ ÏÄÎÏÇÏ ÑÚÙËÁ ÏÂÙÞÎÏ ÓÏÈÒÁÎÑÅÔÓÑ ÎÅËÏÔÏÒÏÅ ÐÏÄÍÎÏÖÅÓÔ×Ï ÓÉÎÔÁËÓÉÓÁ, ÔÁË ÞÔÏ ÎÅËÏÔÏÒÙÅ ÐÒÏÇÒÁÍÍÙ ÂÕÄÕÔ ÐÒÁ×ÉÌØÎÙÍÉ ÐÒÏÇÒÁÍÍÁÍÉ ÄÌÑ ÏÂÏÉÈ ÄÉÁÌÅËÔÏ×.

AK> ÷ÏÚØÍÉÔÅ ÔÏÔ-ÖÅ AK> nnCron(ÐÌÁÎÉÒÏ×ÝÉË) ÉÌÉ Eserv(Web ÓÅÒ×ÅÒ) ÏÂÁ ÐÒÏÉÚ×ÏÄÎÙÅ ÏÔ SPF É AK> ÐÒÅÄÏÓÔÁ×ÌÑÀÔ ×ÓÅ ÅÇÏ ÓÒÅÄÓÔ×Á (ÔÏÒÞÁÔ "ÕÛÉ æÏÒÔÁ" :) ) ÎÏ ÔÅÍ ÎÅ AK> ÍÅÎÅÅ ËÁÖÄÙÊ ÉÚ ÎÉÈ ÓÔÁÌ ÓÁÍÏÓÔÏÑÔÅÌØÎÙÍ ÐÒÏÄÕËÔÏÍ ÓÏ Ó×ÏÉÍ AK> ÓÉÎÔÁËÓÉÓÏÍ É ÚÁÄÁÞÁÍÉ.

üÔÏ _ÐÒÏÄÕËÔÙ_, Á ÎÅ ÄÉÁÌÅËÔÙ æÏÒÔÁ, ÞÕÓÔ×ÕÅÔÅ ÒÁÚÎÉÃÕ?

Roman

Sun Oct 12 2003 03:53, Oleksandr Redchuk wrote to "Artem Kamburov":

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

Вот когда так, как ты говоришь, _не_ делают, я этого уже не понимаю.

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

(Только не надо флейма про то, что "все уже есть"...)

ðÒÉ×ÅÔ Artem!

Sunday October 12 2003 14:08, Artem Kamburov wrote to Alexander Torres:

AK> ÞÔÏ AK>

AK> ë ÓÏÖÁÌÅÎÉÀ ÜÔÏÇÏ ÐÁÒÁÍÅÔÒÁ × ÄÁÔÁÛÉÔÅ ÎÅÔ (ÎÁÛÅÌ ÔÏÌØËÏ ×ÈÏÄÎÏÅ AK> ÓÏÐÒÏÔÉ×ÌÅÎÉÅ áãð - 100íïÍ)

úÎÁÞÉÔ ÈÒÅÎÏ×ÙÊ ÄÁÔÁÛÔ, ÉÌÉ ÜÔÏ ÍÏÖÅÔ ÂÙÔØ ÇÄÅ-ÔÏ × ÁÐÐÌÉËÕÛËÁÈ. ÷ 100íïÍ ×ÈÏÄÎÏÇÏ ÓÏÐÒÏÔÉ×ÌÅÎÉÑ áãð × ÍÉËÒÏËÏÎÔÒÏÌÌÅÒÅ - ÍÎÅ ÎÅ ÓÉÌØÎÏ ×ÅÒÉÔÓÑ.

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

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

formatting link
,
formatting link
, ftp://altor.sytes.net

ðÒÉ×ÅÔ Alex!

Sunday October 12 2003 14:44, Alex Kouznetsov wrote to Alexander Torres:

AK>>> ÷Ù × ÜÔÏÍ ÔÅÒÑÅÔÅ ÇÌÁ×ÎÏÅ ÐÒÅÉÍÕÕÝÅÓÔ×Ï óÉ ÎÁÄ æÏÒÔÏÍ - ÎÁÂÏÒÙ AK>>> ÂÉÂÌÉÏÔÅË ÎÁ ×ÓÅ ÓÌÕÞÁÉ ÖÉÚÎÉ :). AK>

AT>> åÓÌÉ Ï ÜÈÏÔÁÇÅ, ÔÏ "ÇÌÁ×ÎÏÅ ÐÒÅÉÍÕÝÅÓÔ×Ï óÉ" - ÜÔÏ ×ÏÚÍÏÖÎÏÓÔØ AT>> ÎÁÐÉÓÁÔØ ÎÅÞÔÏ ÔÉÐÁ: if ( (a>=b) || (c<(d-e)) ) k=a+b*c/d; else AT>> k=b*d-a; AK>

AK> ÷ _ÜÔÏÍ_ Õ ó ÎÅÔ ÎÉËÁËÏÇÏ ÐÒÅÉÍÕÝÅÓÔ×Á: AK>

a b >> = c d e - < OR AK>

AK> IF AK> a b c d */ + AK> ELSE AK> b d * a - AK> THEN AK> ðÏ ËÏÌÉÞÅÓÔ×Õ ÓÉÍ×ÏÌÏ× - ÐÒÉÍÅÒÎÏ ÔÏ ÖÅ ÓÁÍÏÅ. ðÏ ÎÁÇÌÑÄÎÏÓÔÉ - ÄÅÌÏ AK> ÐÒÉ×ÙÞËÉ É ×ËÕÓÁ.

ôÙ ÎÁÐÉÓÌ ÔÏÖÅ ÓÁÍÏÅ ÎÁ æÏÒÔÅ, ÎÏ ÐÅÒÅÄ ÜÔÉÍ ÓÐÅÃÉÁÌØÎÏ ÓËÉÐÎÕÌ ÐÒÏÄÏÌÖÅÎÉÅ ÍÏÅÊ ÆÒÁÚÙ, ÇÄÅ ÇÏ×ÏÒÉÌÏÓØ ÐÒÏ ÁÓÓÅÍÂÌÅÒ?

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

formatting link
,
formatting link
, ftp://altor.sytes.net

ðÒÉ×ÅÔ Oleksandr!

Sunday October 12 2003 15:10, Oleksandr Redchuk wrote to Alexander Torres:

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

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

OR> HÁÉÂÏÌÅÅ ÕÄÏÂÎÏ _ËÏÍÕ_? OR> "÷ ÓÒÅÄÎÅÍ ÐÏ ×ÓÅÍ ÐÏÌØÚÏ×ÁÔÅÌÑÍ"?

íÎÅ, ÎÁÐÒÉÍÅÒ :) ÷ ÂÏÌØÛÉÎÓÔ×Å ÓÌÕÞÁÅ×, Ñ ×ÙÚÙ×ÁÀ ÐÒÏÇÒÁÍÁÔÏÒ ÉÚ ËÁËÏÊ-ÎÉÂÕÄØ ÏÂÏÌÏÞËÉ - íÐÌÁÂÁ, áÓÍÅÄÁ É Ô.Ð., × ÜÔÏÍ ÓÌÕÞÁÅ ÒÁÚÕÍÅÅÔÓÑ ÎÕÖÎÁ ËÏÍÁÎÄÎÁÑ ÓÔÒÏËÁ. HÏ ÉÎÏÇÄÁ ÂÙ×ÅÔ ÎÕÖÎÏ É çõé, ÎÁÐÒÉÍÅÒ ÐÒÉ ÚÁÛÉ×ËÅ ÐÁÒÔÉÉ - ÓÞÉÔÁÔØ ËÏÌÉÞÅÓÔ×Ï ÐÒÁ×ÌØÎÏ É ÎÅÐÒÁ×ÉÌØÎÏ ÚÁÛÉÔÙÈ, ÄÅÌÁÔØ ÓÅÒÉÁÌÉÚÁÃÉÀ É Ô.Ð.

AT>> á ÅÓÌÉ ÅÝÅ É ××ÅÓÔÉ ÒÅÖÉÍ "mass production"..... AT>> HÏ ÜÔÏ ÕÖÅ ÁÐÐÁÒÁÔÎÙÈ ÐÅÒÅÄÅÌÏË ÔÒÅÂÕÅÔ. OR>

OR> ÔÁË ÏÔ×ÅÔ ÔÏÖÅ ÐÒÏÓÔÏÊ -- "á ÐÒÏÅËÔ ÎÅËÏÍÍÅÒÞÅÓËÉÊ". OR> ñ ÄÅÌÁÌ ÉÚÎÁÞÁÌØÎÏ É ÄÅÌÁÀ ÄÏ ÓÉÈ ÐÏÒ × ÏÓÎÏ×ÎÏÍ ÄÌÑ ÓÅÂÑ. OR> ëÏÍÕ ÎÅ ÎÒÁ×ÉÔÓÑ -- ÍÏÇÕÔ ×ÚÑÔØ ÐÏÎÉ-ÐÒÏÇ, ÍÏÇÕÔ ÎÁÐÉÓÁÔØ OR> ÏÂÏÌÏÞËÕ ÓÁÍÉ.

üÔÏ ÐÏÎÑÔÎÏ.

OR> p.s. OR>

OR> âÏÌÅÅ ÔÏÇÏ.. íÎÅ ÄÁÖÅ ÔÑÖÅÌÏ ÐÏÎÑÔØ -- ÞÅÍ ÍÏÖÅÔ ÂÙÔØ ÈÏÒÏÛ ÏÔÄÅÌØÎÙÊ OR> GUI ÐÒÏÇÒÁÍÍÁÔÏÒÁ (ÏÔÄÅÌØÎÙÊ ÏÔ ÓÒÅÄÙ ÒÁÚÒÁÂÏÔËÉ).

äÌÑ ÒÁÚÒÁÂÏÔËÉ - ÎÉÞÅÍ. äÌÑ ÏÓÔÁÌØÎÙÈ ×ÉÄÏ×Ï ×ÏÚÍÏÖÎÙÈ ÒÁÂÏÔ - ÉÎÏÇÄÁ ÍÏÇÌÏ ÂÙ É ÐÒÉÇÏÄÉÔÓÑ.

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

formatting link
,
formatting link
, ftp://altor.sytes.net

ðÒÉ×ÅÔ Artem!

Sunday October 12 2003 18:52, Artem Kamburov wrote to Oleksandr Redchuk:

AK> íÏÖÎÏ ÐÅÒÅÄÁÔØ ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÅ ÐÏÌÎÏÍÕ ÀÚÅÒÕ :).

éÍÅÎÎÏ ÔÁË ÍÙ É ÄÅÌÁÅÍ ÏÂÙÞÎÏ, ÄÌÑ ÇÏÔÏ×ÙÈ ÐÒÏÛÉ×ÏË. üÔÉÍ ÚÁÎÉÍÁÅÔÓÑ ÉÍÅÎÎÏ "ÀÚÅÒ", ÚÁÄÁÞÁ ËÏÔÏÒÏÇÏ - ×ÔÁ×ÉÔØ ÍÉËÒÏÓÈÅÍÕ × ÐÁÎÅÌØÎÕ (ÉÌÉ ÐÏÄËÌÀÞÉÔØ ËÁÂÅÌØ ISP), ÎÁÖÁÔØ ËÎÏÐËÕ É ÐÏÓÍÏÔÒÅÔØ ÎÁ ÒÅÚÕÌØÔÁÔ. äÁÌÅËÏ ÎÅ ×ÓÅÇÄÁ ÜÔÏ "ÀÚÅÒ" ×ÏÏÂÝÅ ÐÏÎÉÍÅÔ ÞÔÏ ÏÎ ÄÅÌÁÅÔ É ÚÎÁÅÔ ÞÅÍ ÜÔÏÔ "ÐÌÁÓÔÍÁÓÓÏ×ÙÊ ÖÕÞÅË" ÏÔÌÉÞÁÅÔÓÑ ÏÔ ÂÏÌÔÁ í8 :)

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

formatting link
,
formatting link
, ftp://altor.sytes.net

ðÒÉ×ÅÔ Artem!

Sunday October 12 2003 18:52, Artem Kamburov wrote to Alexander Torres:

AK> ËÏÒÏÒÙÅ AK>

AK> ðÒÉÍÅÒÎÏ ÔÁ ÖÅ ÓÉÔÕÁÃÉÑ ÐÒÉ ÐÅÒÅÈÏÄÅ At90S4433 ÎÁ AtMega8 É At90S8515 ÎÁ AK> AtMega8515. HÏ ÅÝÅ ÒÁÚ ÇÏ×ÏÒÀ - ÔÏÊ ÓÈÅÍÅ ÁÌØÔÅÒÎÁÔÉ×Á ÔÏÌØËÏ ÌÉÛÎÉÅ ÎÏÇÉ AK> ÐÒÏÃÅÓÓÏÒÁ. é ÂÒÁÔØ ÐÒÃÅÓÓÏÒ ÎÁ 1$ ÄÏÒÏÖÅ ÐÒÉ ÓÅÂÉÓÔÏÉÍÏÓÔÉ ÉÚÄÅÌÉÑ × 10$ 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

formatting link
,
formatting link
, ftp://altor.sytes.net

Sun Oct 12 2003 12:43, Alexey Boyko wrote to Ilia Tarasov:

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

Разве есть принципиальная разница, в каком конкретно языке или ОС будет использована подобная методология? gcc, кстати, это компилятор для _одного_ языка из целой серии. Как быть с Паскалем или Фортраном?

Hello Roman!

12 Oct 03 21:45, Roman Khvatov wrote to Ilia Tarasov:

RK> ðÒÏ ÁÓÓÅÍÂÌÅÒ ÕÖÅ ÄÁ×ÎÏ ×ÓÅ ÚÁÂÙÌÉ (ËÒÏÍÅ ÎÅÓËÏÌØËÉÈ ÕÐÅÒÔÙÈ ÌÉÞÎÏÓÔÅÊ RK> É Á×ÔÏÒÏ× ËÏÍÐÉÌÑÔÏÒÏ×)

HÅÕ×ÁÖÁÅÍÙÊ, ËÒÁÊÎÅ É ÎÁÓÔÏÑÔÅÌØÎÏ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÷ÁÍ ÓÌÅÇËÁ ÐÅÒÅÏÓÍÙÓÌÉÔØ ÷ÁÛ ÚÁÔÑÎÕ×ÛÉÊÓÑ ÄÅÔÓËÉÊ ÜËÓÔÒÅÍÉÚÍ. ëÏÇÄÁ ÷Ù ÓÕÍÅÅÔÅ ×ÙÊÔÉ ÉÚ ËÁÔÅÇÏÒÉÉ ÕÐÅÒÔÙÈ ÌÉÞÎÏÓÔÅÊ (Á ÓÕÍÅÅÔÅ ÌÉ? - ×ÅÒÉÔÓÑ Ó ÔÒÕÄÏÍ...), ÔÏÇÄÁ ÅÓÔØ ÎÅÎÕÌÅ×ÏÊ ÛÁÎÓ ÐÒÏÄÏÌÖÉÔØ.

73 & Cheerio! Andy.
÷ÓÅÍ ÐÒÉ×ÅÔ.

èÍ... çÏ×ÏÒÑÔ ÖÅ ÔÅÂÅ ÎÁÄÅÖÎÏÅ, Á ÔÙ "ÎÅ ×ÅÒÀ". üÔÏ ÒÅÛÅÎÉÅ ÍÅÖÄÕ ÐÒÏÞÉÍ ÐÒÏÒÁÂÏÔÁÌÏ ÎÁ 2313 (ÐÏÒÏÇ 1,5÷) Ó 98-ÇÏ ÇÏÄÁ É ÕÖÅ ÂÏÌØÛÅ ÇÏÄÁ ÎÁ Tiny26(ÐÏÒÏÇ 1÷) - Á ÜÔÏ ÂÏÌØÛÅ 10 ÔÙÓ. ÉÚÄÅÌÉÊ. áÒÔÅÍëáä

Sun Oct 12 2003 21:45, Roman Khvatov wrote to Ilia Tarasov:

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

Ты говоришь о смене суперскаляра на VLIW? Это несколько другая сторона проблемы. Я имею в виду _двустороннее_ соответствие, которое легко обеспечить хотя бы потому, что алгоритмы вобщем-то строятся на основе одних и тех же логических конструкций, которые в настоящее время поддержаны системой команд недостаточно однозначно. О чем говорит JC или JNZ? Покажи мне ту конструкцию Си, которая в явном виде устанавливает флаг нуля. А чем плохо JA_EQ_B (переход, если AX = BX)? Это разве не более короткая версия перехода, прекрасно ложащаяся на Си?

RK> Что касается Форта, то у него железо и ЯВУ сведены где то посередине, что ... RK> расстояние, но софт это не железка, его можно сделать гораздо более RK> мощным, чем любые хардверные прибамбахи.

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

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

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

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

Не другие Форты, а другие языки. Lux, Onyx, еще что-то...

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

Си, Паскаль, Алгол, Фортран - разные языки? btw, они построены вовсе не для регистровой архитектуры, а как раз для стековой. Иначе зачем там стековый кадр и уже с 286-го процессора введены команды ENTER и LEAVE? Это для реализации на регистровом процессоре требуются мощные оптимизирующие компиляторы.... И еще btw, аргументы по поводу того, что gcc портируется на любой процессор, только подтверждают независимость Си от регистровой модели. Если угодно, это язык, основанный на модели _памяти_ (поскольку переменные и прочие программные объекты, характеризующие состояние программы, объявляются именно там). У процессора, выполняющего программу, скомпилированную из Си, может вообще не быть регистров, если он способен работать с операндами из памяти и записывать результат в память же...

RK> Они различаются названием языка. Если такие языки создают, а не RK> довольствуются С, то значит это кому то надо? Почему же не создают

Название - конечно, существенное отличие... :))) Но если серьезно, то над всем зоопарком процедурных языков давно делают разные надстройки метауровня. Тривиальнейший пример - Matlab, генерирующий Си. Видимо, все же накоплена критическая масса и надо двигаться дальше?

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

Да, это одно из существенных препятствий к его распространению. (И он не хорош и не плох. Лисп - хорош? Списки, функции, лямбда...)

RK> примитивную операцию, а остальное время занимающимися синхронизацией друг RK> с другом (я не знаю, как обстоит дело с языками 4го поколения - не RK> смотрел)

Handel-C - это практически обычный Си. Добавилось ключевое слово par для указания того, что следующий список операторов должен исполняться на одном и том же такте, при объявлении переменных необходимо указать их разрядность. Ушли некоторые конструкции управления. С VHDL связь довольно прямая, в автоматически генерируемом VHDL-описании отчетливо просматриваются исходные конструкции Handel-C.

RK> Ага, таким образом можно что угодно выполнить 'за такт' - если сделать RK> внутри кристала из одного такта 10, то внешне оно конечно будет RK> однотактовым, но скорости это не прибавит :(

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

RK> Это 'исполняющее функцию' размазано по всему словарю Форта. Кроме того, RK> такой способ анализа не способен произвести контроль над семантикой в RK> целом - то есть проверить, что бы if then были сбалансированны слова if и RK> then смогут, а проверить, что они не пересекутся с какой нибудь другой RK> конструкцией - нет.

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

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

К этому есть существенные основания?

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

Согласен. Поэтому и повторяю постоянно, что бросаться осваивать Форт никому не советую, но познакомиться с ним полезно. Мало ли как сложатся обстоятельства? По тем же причинам могу еще Лисп посоветовать... ;)))) Тоже в эмбеддед "не совсем лезет", тоже сложный, тоже осваивать долго, тоже нет компиляторов... :))))) Но не знать лямбду - быть "программистом-слесарем"....

RK> Язык не должен быть уникальный - он должен базироваться на чем то очень RK> хорошо известном (например на том же С или Pascal'е - кому что нравится), ~~~~~~~~~~~~~~~~~~ !!! :)))))))))

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

Знакомство с Фортом и технологией разработки целевого компилятора на нем дает прекрасные навыки "выкидывания кусков" из _любых_ языков!

RK> Так же как в Форте: Что написал - то и получил, оптимизатор отсуствует RK> (или присутсвует в самой малой степени). По удобству даст Форту 100 очков RK> вперед - сколько человек могут програмировать на С, а сколько на Форте?

У нас - на Си меньше, чем на Форте... :))))

(to be continued)

Sun Oct 12 2003 21:45, Roman Khvatov wrote to Ilia Tarasov:

RK> Сколько человек смогут понять, что здесь написано? RK> : IF COMPILE ?BRANCH HERE 2 ALLOT ; IMMIDIATE

Не знаю, сколько смогут понять с лету, но это определение слова IF

COMPILE ?BRANCH - скомпилировать ?BRANCH (оно само немедленного исполнения, так что компилировать его надо "силком") HERE - положить текущий адрес на стек

2 ALLOT - резервировать 2 байта

Итого, с учетом IMMEDIATE-флага, это слово скомпилирует код для условного перехода и выделит 2 байта для вписывания туда адреса перехода. Адрес, куда вписывать ссылку, кладется на стек словом HERE. Это для шитого кода, и без учета семантических проверок. Если пример из Баранова, то там еще должна единичка положиться на стек...

RK> Или, что понятнее для человека, не знающего ни Форт ни С: RK> a @ b @ * DUP c @ / SWAP d @ MOD + RK> или RK> a*b/c+a*b%d

(+ (/ (* a b) с)(% (* a b) d)) Против этого возражения будут?

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

(все переменные - value )

a b * c / a b * d MOD +

IT>> Просто для интереса - сколько работают в DPMI в нулевом кольце? RK> зачем им там работать?

WBINVD перед интенсивными вычислениями на некоторых машинах ускоряет их до 3 раз!.... Выполняется _только_ в нулевом кольце, иначе #GP.

IT>> И сколько из них позволяют делать ассемблерные вставки в нативном IT>> 32-битном коде, RK> _зачем_

_надо_

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

IT>> а также пользоваться SVGA-графикой и делать POSIX-овые вызовы? RK> _ЗАЧЕМ_ ???

8-) А РАЗВЕ НЕЗАЧЕМ??? Я тебя совсем не понимаю - ты предлагаешь работать, не сдвигаясь мышлением ни на йоту, при этом теряя как в производительности, так и в мощности интерфейса. SVGA для PC - еще как-то можно поспорить, хотя как ты в текстовом режиме представишь массив примерно 1000x500? Про POSIX мне совсем непонятно - что, файлы стандартно открывать нельзя? Время получить, системные ресурсы узнать? Для всего надо придумать свой стандарт? И ради чего - чтобы в тексте программы видеть любимые фигурные скобки? Так Си тоже обычно поддерживает POSIX...

RK> Если нужно все это - то нужно брать транслятор, а не искать приключений RK> на свою голову.

Я, вобщем-то, и взял транслятор....

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

8-))))

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

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

В нулевом кольце исполняются _ассемблерные_ примитивы. Адресующие в линейном пространстве обрабатываемые массивы в десятки мегабайт. То, что один раз при входе в примитив регистры заполнятся из стека, оказывает смехотворное влияние на время их выполнения. Все операции по подготовке данных и их визуализации, соответственно, влияют на производительность гораздо меньше (однако же адресация видеопамяти через линейный кадровый буфер, отображаемый в сегмент защищенного режима, не идет ни в какое сравнение с какой-нибудь graph.h). А вот насколько удобно будет управлять запуском этих примитивов, влияет на конечную ценность программы гораздо сильнее. Если компилятор сможет быстренько вбить в память последовательность вызова отлаженных примитивов, это уже очень хорошо. Если он к тому же дает возможность скомпилировать выполнение "одноразовых" вычислений - это вообще прекрасно!

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

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

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

IT>> Так почему он по своим свойствам так похож на Форт? :) RK> Это Форт на него похож :) Практически все интерпретаторы строятся на тех RK> или иных стековых машинах - так удобнее.

Мне все равно, кто на кого похож :) Главное - комплекс свойств, а не название.

IT>> Hаконец, Форт компилирует!!! RK> Для интерпретатора это неважно, а для компилятора у Форта слишком много RK> осталось от интерпретатора :)

См. выше... Какую роль это играет, если все критичное уже откомпилировано (хоть тем же Си, а лучше бы Фортраном...)? Стековые вычисления с оверхедом на не-стековых процессорах? Да плевать ни них, они все равно выполнятся в пределах долей секунды. А вот то, что интерпретатор (aka система обработки ввода пользователя) также уже скомпилирован, а не является плодом полета фантазии Сишного программера - явный плюс. Даже в Delphi/Builder программеры умудряются наворотить ошибки в интерфейсе (это при визуальных инструментах!).

IT>> А на что может быть похоже поделие на Си, RK> Оно похоже на то, что на нем написали. Hа С можно и Форт написать, или RK> это уже будет не Форт?

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

IT>> Это я пытался давать людям попробовать, RK> Hадо было давать это пробовать специалистам по компиляторам, а не RK> знатокам Форта - было бы и на С вполне нормально.

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

Hello, Alexander!

AT> ÐÏÎÑÌ - "ËÏÌÉÞÅÓÔ×Ï õáòôÏ×", ÉÌÉ ÇÏ×ÏpÑ ÏÂÏÂÝÅÎÎÏ - "ËÏÌÉÞÅÓÔ×Ï É AT> ËÁÞÅÓÔ×Ï ÎÁÂÏpÔÎÏÊ ÐÅpÉÆÅpÉÉ" - ÄÌÑ ÜÈÏÔÁÇÁ ÉÍÅÅÔ _ÐÅp×ÏÓÔÅÐÅÎÎÏÅ AT> ÚÎÁÞÅÎÉÅ_, É ×Ï ÍÎÏÇÏ ËpÁÔ ×ÁÖÎÅÅ ÞÅÍ ÓÉÓÔÅÍÁ ËÏÍÁÎÄ (ÉÚ-ÚÁ ËÏÔÏpÏÊ

ôÁËÉ ÄÁ. ëÏÇÄÁ ÌÅÐÉÔØ ÞÔÏ-ÔÏ, ÞÅÇÏ ×Ï×ÎÕÔpÑÈ ÎÅÔÕÔÉ, ÎÅ ÐÏ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏÊ ÛÉÎÅ - ÓÅpÄÃÅ ËpÏרÀ ÏÂÌÉ×ÁÅÔÓÑ...

Best regards, // óÁÄÉÓØ, pÁÓÓÌÁÂØÓÑ É ÉÈ ÔpÕÐÙ Yurij. // ÐpÏÐÌÙ×ÕÔ ÍÉÍÏ ÔÅÂÑ ÐÏ pÅËÅ. :) (c) DVK

Hello, Artem!

AK> óÉ ËÁË ÓÁÍÏÓÔÏÑÔÅÌØÎÙÊ ÑÚÙË (ÂÅÚ ÂÉÂÌÉÏÔÅË, ÂÅÚ ÐÏÄÄÅpÖËÉ ËpÕÐÎÙÍÉ AK> ËÏÍÐÁÎÉÑÍÉ, ÂÅÚ ËÕpÓÏ× ÏÂÕÞÅÎÉÑ, ÂÅÚ ÇpÏÍÁÄÎÏÇÏ ÞÉÓÌÁ ÐpÏÇpÁÍÍÉÓÔÏ×) AK> ÔÏÖÅ ÎÏÎÓÅÎÓ :)

÷pÁËÉ. âÕÔÌÏÁÄÅpÙ É ÍÏÎÉÔÏpÙ pÁÓÐpÅËpÁÓÎÏ ÐÉÛÕÔÓÑ ÎÁ óÑÈ. é ÎÉËÁËÁÑ ápÍÉÑ óÐÁÓÅÎÉÑ ÉÚ ÎÅÉÓÞÉÓÌÉÍÙÈ óÉ-ÐpÏÇpÁÍÍÅpÏ× ÐpÉ ÜÔÏÍ ÚÁ ÐÌÅÞÁÍÉ ÎÅ ÓÔÏÉÔ, É ÄÁÖÅ ËÕpÓÏ× ÎÉËÁËÉÈ ÐpÉ ÜÔÏÍ ÐÏÓÅÝÁÔØ ÎÅ ÎÕÖÎÏ - ×ÏÔ ×ÅÄØ ÚÁÓÁÄÁ...

Best regards, // ñ pÕÓÓËÉÊ ÂÙ ÎÁÈ... ÚÁÐpÅÔÉÌ ÂÙ ÚÁ ÔÏ, Yurij. // ÞÔÏ ÎÁ ÎÅÍ pÁÚÇÏ×ÁpÉ×ÁÌ ìÅÎÉÎ

Hello, Alex!

AK>> ÏÓÏÂÅÎÎÏ ÅÓÌÉ ÃÅÌÅ×ÏÊ ÐpÏà - æÏpÔ-ÐpÏÃÅÓÓÏp.

RK> é ÇÄÅ ÏÎÉ?

AK> HÅÐÏÌÎÙÊ ÓÐÉÓÏË ËpÅÍÎÉÅ×ÙÈ ÎÁ

formatting link
÷ÉpÔÕÁÌØÎÙÅ ÐpÏÃÅÓÓÏpÙ × ×ÉpÔÕÁÌØÎÏÍ ÐpÏÓÔpÁÎÓÔ×Å :-)

Best regards, // ÷ ÎÅËÏÔÏpÙÅ ÇÏÌÏ×Ù ÍÙÓÌÉ ÐpÉÌÅÔÁÀÔ Yurij. // ÌÉÛØ ÚÁÔÅÍ, ÞÔÏÂÙ ÎÁÇÁÄÉÔØ :-)

Hello Ilia.

12 Oct 03 22:40, you wrote to me:

AB>> ðÏÒÔÉÒÏ×ÁÔØ gcc ÇÏÒÁÚÄÏ ÌÅÇÞÅ, ÞÅÍ ËÁÖÅÔÓÑ. ïÓÏÂÅÎÎÏ, ÅÓÌÉ AB>> ÓÉÎÔÅÚÉÒÏ×ÁÔØ ÐÒÏÃÅÓÓÏÒ ÓÁÍÏÍÕ, ÐÏÄÇÏÎÑÑ ÅÇÏ ÐÏÄ gcc. (ôÉÐÁ AB>> ËÁÖÄÏÍÕ insn × rtl - ÏÄÎÁ ËÏÍÁÎÄÁ ÐÒÏÃÅÓÓÏÒÁ) IT> òÁÚ×Å ÅÓÔØ ÐÒÉÎÃÉÐÉÁÌØÎÁÑ ÒÁÚÎÉÃÁ, × ËÁËÏÍ ËÏÎËÒÅÔÎÏ ÑÚÙËÅ ÉÌÉ ïó IT> ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÎÁ ÐÏÄÏÂÎÁÑ ÍÅÔÏÄÏÌÏÇÉÑ?

HÅÔ. HÏ gcc ÌÕÞÛÅ ÞÅÍ ÆÏÒÔ (ÜÔÏ ÉÍÈÏ, ÓÐÏÒÉÔØ ÎÅ ÂÕÄÕ ;) )

IT> gcc, ËÓÔÁÔÉ, ÜÔÏ ËÏÍÐÉÌÑÔÏÒ IT> ÄÌÑ _ÏÄÎÏÇÏ_ ÑÚÙËÁ ÉÚ ÃÅÌÏÊ ÓÅÒÉÉ. ëÁË ÂÙÔØ Ó ðÁÓËÁÌÅÍ ÉÌÉ æÏÒÔÒÁÎÏÍ?

æÏÒÔÒÁÎ ÔÕÄÁ ×ÈÏÄÉÔ, Ó ÐÁÓËÁÌÅÍ ×ÒÏÄÅ ÍÕÔÉÌÉ ÞÔÏ-ÔÏ, ÎÏ ÔÁË É ÎÅ ÎÁÍÕÔÉÌÉ. á ÚÁÞÅÍ ÔÅÂÅ ÆÏÒÔÒÁÎ ÉÌÉ ÐÁÓËÁÌØ? òÁÄÉ ÐÒÉÎÃÉÐÁ?

Alexey

Hello Artem.

12 Oct 03 17:52, you wrote to Oleksandr Redchuk:

ëÓÔÁÔÉ, ÄÁ. éÎÏÇÄÁ ÔÁË ÚÁÄÁÌÂÙ×ÁÅÔ, ËÏÇÄÁ ÐÉÛÕ ÏÄÎÕ ÐÒÏÇÒÁÍÍÕ, Á ÍÎÅ ÐÒÉÎÏÓÑÔ ÄÒÕÇÕÀ ÚÁÐÁÑÎÎÕÀ ÐÌÁÔÕ, É ÐÒÏÓÑÔ ÚÁÐÒÏÇÒÁÍÍÉÒÏ×ÁÔØ. üÔÏ ÎÁÄÏ ÏÔÒÙ×ÁÔØÓÑ, ×ÓÐÏÍÉÎÁÔØ ÇÄÅ ÐÒÏÛÉ×ËÁ É ÐÅÒÅËÌÀÞÁÔØ ÒÁÚßÅÍÙ É ÔÁË ÄÁÌÅÅ.

Alexey

Hello everybody.

12 Oct 03 21:05, Igor Ulanov wrote to Vladimir Vassilevsky:

IU> 12 ïËÔ 03 20:21, Vladimir Vassilevsky -> Vladislav Baliasov:

VV>> HÅyÄÏÂÎÏ pÁÚÂÉpÁÔØÓÑ Ó ÐpÏÉÚ×ÏÌØÎÏ ÓÏËpÁÝÅÎÎÙÍÉ ÉÍÅÎÁÍÉ ÆØÀÚÏ×. VV>> ÷ÓÅ ÉÍÅÎÁ ÄÏÌÖÎÙ ÂÙÔØ ÐÏÌÎÙÍÉ É ÔÏÞÎÏ ÔÁËÉÍÉ, ËÁË × ÄÁÔÁÛÉÔÅ. ðpÉ VV>> ÜÔÏÍ ÚÁÄÁÎÉÅ ÏÐÃÉÊ ÞÅpÅÚ ËÏÍÁÎÄÎyÀ ÓÔpÏËy ÓÔÁÎÏ×ÉÔÓÑ ÎÅÐpÁËÔÉÞÎÙÍ VV>> - ÌyÞÛÅ ÂÙ ÞÉÔÁÔØ ÉÈ ÉÚ ÔÅËÓÔÏ×ÏÇÏ *.cfg ÆÁÊÌÁ.

èÏÞÕ ÐÒÅÄÌÏÖÉÔØ ÔÁËÏÊ ÐÏÄÈÏÄ (ÍÎÅ ÏÎ ËÁÖÅÔÓÑ ÉÄÅÁÌØÎÙÍ): 1) ðÒÏÇÒÁÍÍÁÔÏÒ ÚÁÐÕÓËÁÅÔÓÑ Ó ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÉ É ÂÅÒÅÔ ×ÓÅ ÎÁÓÔÒÏÊËÉ Ó ÎÅÅ ÖÅ ÉÌÉ ÉÚ .cfg ÆÁÊÌÁ (ÁÌØÔÅÒÎÁÔÉ×ÏÊ ÍÏÇ ÂÙ ÂÙÔØ ÐÒÏÇÒÁÍÍÁÔÏÒ × ×ÉÄÅ ActiveX ÏÂßÅËÔÁ + ÏÂ×ÅÒÔËÁ ÄÌÑ ÎÅÇÏ × ×ÉÄÅ ÕÔÉÌÉÔÙ ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÉ) 2) åÓÔØ ÏÔÄÅÌØÎÙÊ GUI, ËÏÔÏÒÙÊ ÐÏÚ×ÏÌÑÅÔ ÕÓÔÁÎÏ×ÉÔØ ×ÓÅ ÎÁÓÔÒÏÊËÉ É ÌÉÂÏ ÚÁÐÕÓÔÉÔØ ÐÒÏÇÒÁÍÍÁÔÏÒ, ÌÉÂÏ ÓÏÚÄÁÔØ .bat É/ÉÌÉ .cfg ÆÁÊÌ ÄÌÑ ÚÁÐÕÓËÁ ÐÒÏÇÒÁÍÍÁÔÏÒÁ Ó ÜÔÉÍÉ ÎÁÓÔÒÏÊËÁÍÉ.

IU> íÏÖÅÔ É ÓÐpÁ×ÅÄÌÉ×Ï, ÎÏ ÍÎÅ ÎÅ ËÁÖÅÔÓÑ ÜÔÁ ÐpÏÂÌÅÍÁ ÓÔÏÑÝÅÊ IU> pÁÚÇÏ×ÏpÁ. ë ÓÏÖÁÌÅÎÉÀ y ÍÅÎÑ ÎÅÔ ÐÏÄ pyËÏÊ Á×pÅÁÌÁ, ÎÏ ÎÁÓËÏÌØËÏ Ñ IU> ÐÏÍÎÀ ÅÓÌÉ × ÎÅÍ É ÓÏËpÁÝÅÎÎÙ ÎÁÚ×ÁÎÉÑ ÆØÀÚÏ×, ÔÏ ÜÔÏ ÓÄÅÌÁÎÏ IU> ÎÁÓÔÏÌØËÏ yÄÏÂÎÏ É ÐÏÎÑÔÎÏ, ÞÔÏ Ñ ÎÅ ÏÂpÁÔÉÌ ÎÁ ÜÔÏ ×ÎÉÍÁÎÉÅ.

ìÕÞÛÅ, ÅÓÌÉ ÏÎÉ ÂÕÄÕÔ ÎÅ ÓÏËÒÁÝÅÎÎÙÍÉ É Ó ÈÏÔÑ ÂÙ ÍÉÎÉÍÁÌØÎÙÍ help'ÏÍ (× GUI)

IU> é ×ÏÏÂÝÅ, ÂÁÔÎÉË Ó ËÌÀÞÉËÁÍÉ × ÈyÄÛÅÍ ÓÌyÞÁÅ ÐÉÛÅÔÓÑ ÐÏÄ ËÁÖÄÙÊ IU> ÐpÏÅËÔ, É Ñ ÚÄÅÓØ ÎÅ ×ÉÖy ÏÓÏÂÙÈ ÐpÏÂÌÅÍ Ó ×ÙÄÅÌÅÎÉÅÍ ÐÑÔÉ ÍÉÎyÔ ÄÌÑ IU> ÎÁÐÉÓÁÎÉÑ ÂÁÔÎÉËÁ.

GUI ÓÄÅÌÁÅÔ ÔÁËÏÊ ÂÁÔÎÉË ÚÁ 5 ÓÅËÕÎÄ :)

VV>> åÝÅ ÏÄÎÁ ÐpÏÂÌÅÍÁ (ÐpÁ×ÄÁ, ÎÅ Ó Á×pÅÁÌÏÍ, Á Ó ÆØÀÚÁÍÉ ×ÏÏÂÝÅ): VV>> äÌÑ ÎÅÓ×ÅÄyÝÅÇÏ ÞÅÌÏ×ÅËÁ ÓÏ×ÅpÛÅÎÎÏ ÏÞÅ×ÉÄÎÏ, ÞÔÏ ON == 1, OFF VV>> == 0. ðÏ ÜÔÏÊ ÐpÉÞÉÎÅ ËÁË-ÔÏ ÐpÉÛÌÏÓØ ÐÅpÅÛÉ×ÁÔØ ÐÁpÔÉÀ × 1000 VV>> yÓÔpÏÊÓÔ×. éÓËÏpÅÎÉÔØ ×ÓÅ ÎyÌÉ É ÅÄÉÎÉÃÙ ÞÔÏÂÙ ÎÅ ×ÏÚÎÉËÁÌÏ VV>> ÐÏÄÏÂÎÙÈ ÏÛÉÂÏË.

üÔÏ ÔÏÖÅ _ÄÏÌÖÎÏ_ ÂÙÔØ ÏÔÒÁÖÅÎÏ × GUI.

IU> üÔÏ ËÓÔÁÔÉ ÞÉÓÔÏ ÇyÅ×ÁÑ ÐpÏÂÌÅÍÁ. ÷ Á×pÅÁÌÅ ÎÅ×ÏÚÍÏÖÎÏ IU> ÚÁÐpÏÇpÁÍÉpÏ×ÁÔØ ËÏÎÔpÏÌÌÅp ÎÅ ÐpÏÞÉÔÁ× pÉÄÍÉ, × ËÏÔÏpÏÍ ÞÅÔËÏ IU> ÏÂßÑÓÎÅÎÏ, ÞÔÏ ÐpÏÉÓÈÏÄÉÔ Ó ÆØÀÚÁÍÉ, ÔÅÍ ÂÏÌÅÅ, ÞÔÏ ×ÏÚÍÏÖÎÏ ÓÔÁ×ÉÔØ IU> ÆÌÁÖËÉ off/on.

÷ÏÏÂÝÅ ÔÏ ÈÏÞÅÔÓÑ ÞÉÔÁÔØ ÐÏÍÅÎØÛÅ :)

Roman

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required