как втянуть данные в ПК?

Hello Olga.

27 Mar 05 11:23, Olga Nonova wrote to George Shepelev:

ON> Конечно не случилось бы. Ассемблеpщик, по натуpе,- экономный и очень ON> пpактичный человек. Он не даст себя увлечь "академическими ON> фантазиями". Поэтому все получается максимально эффективно по ON> компактности и быстpодействию. Пpедположим. Hо как это стыкуется с пpедыдущим высказыванием (последнее пpедложение в цитате):

8<------------------------------------------------------------------ AM> Именно поэтому, и получаются чудеса типа "заслал значение в память, чтобы AM> следующей командой его из памяти взять". Да, и гоpжусь этим! Потому как стопpоцентная надежность кода и защита от побочных эффектов. А байты, пpи нынешнем-то изобилии и быстpодействии, - чего их экономить-то? 8<------------------------------------------------------------------ Чужое мнение должно быть уважаемо, констpуктивно кpитикуемо, но в данном случае не видно "генеpальной линии".

Sergey

Reply to
Sergey Davydov
Loading thread data ...

Привет!

Sun Mar 27 2005 12:23, Olga Nonova wrote to George Shepelev:

GS>> Это вопрос качества документации, в частности комментариев в GS>> исходнике. Разумных комментариев нет - автор почти наверняка ваял GS>> халтуру... ON> В данном случае дело было не в документации и не в комментариях, а в ON> обычном для сишников "академическом" подходе к программированию. Там ON> авторы написали фрагмент программы теоритически верно, но жутко ON> неэффективно по быстродействию. А скорость, в вопросе связных задач,- ON> одна из главных вещей.

Господи, Ольга Hиколаевна, что Вы имеете против C?

ON> Конечно не случилось бы. Ассемблерщик, по натуре,- экономный и очень ON> практичный человек. Он не даст себя увлечь "академическими фантазиями". ON> Поэтому все получается максимально эффективно по компактности и ON> быстродействию.

Вы не заметили, что страдаете безапелляционным максимализмом, не утруждая себя доказательством своих более чем странных утверждений? :-)

P.S. Как бывший ассемблерщик замечу, что Ассемблер - не Панацея, весь комплекс вопросов разработки embedded-программы он, естественно, не может покрыть. Экономия - она ведь разная бывает. Можно экономить число байт, занимаемых программой, а можно экономить время ее разработки повышать ее качество. Мое IMHO простое: ниша Ассемблера именно там, где он дает максимальную выгоду - в тех 10% кода, оптимизация которого на Ассемблере оправданна. А уж витание в теоретических облаках на тему "академических фантазий" программистов - это для SU.GENERAL :-)

Юргис

Reply to
Jurgis Armanavichius

OR> (Кстати, какой-нибудь winsock даёт лазить на таком низком OR> уровне? Hадо в MSDN глянуть...).

можно использовать сторонний winpcap (порт libpcap)

Reply to
Dmitry Ponyatov

Hello, Oleksandr! You wrote to "Alexander Derazhne" snipped-for-privacy@i.com.ua> on Mon, 28 Mar 2005

00:16:19 +0000 (UTC):

OR> Девайс умеет по RS232 получать команды и отвечать на них и по OR> IDE-шнурку отдавать данные (монопольно и тупо - не как ATAPI OR> устройство, а как просто регистры с адреса такого-то).

Аа... Стало быть, вопросы полного использования полосы, конечно, снимаются.

AD>> Развести пару-тройку потоков можно и по одному AD>> байтику-заголовку в пакете, зато куча стекового сервиса оказывается AD>> не нужной: соединение OR> А потом мне скажут поцепть несколько таких на один комп. А потом OR> окажется, что надо предоставлять устройство в OEM-версии, так OR> сказать, и потенциальный покупатель будет писать основной софт сам и OR> неизвестно где и как. И всё равно попросят "что-то стандартное"

В девайсе, который стоит сейчас у меня на работе два сетевых разъёма - по одному можно рулить через ip, по другому гоняются данные в своём формате. Но тут именно плотность и ненарушимость потока данных играет решающую роль.

OR> А уже сейчас в "небоевом" варианте, не на объекте, а при OR> отладке/экспериментах (когда высокая скорость не так и нужна) было OR> бы удобно просто подключить это дело в офисную сетку и по очереди OR> лазить туда то мне, то разработчику основного софта. Да, на нижнем OR> уровне можно организовать закат солнца вручную, но мне показалось, OR> что проще сразу сказать "а, IP-сь оно всё в порт".

Тут есть свои плюсы и минусы. Плюсы очевидны. Из минусов - необходимость участия администратора сетки _у_ _Заказчика_ (как ни странно, это часть оказывалось серъёзной проблемой) и зависимость от условий в общей сетке. Кто-то начнёт качать клипы и.. Нет, потом его, конечно... Ну, вобщем, он больше не будет, но допустима ли даже короткое прерывание потока? Ещё могут быть атаки, пока админ (или кто там по должности) не справится - сетка будет еле еле шевелиться. Падение ДНСа. И.т.д. Самое пикантное, это то, что всё равно потребуется или сервисный DB9 или панелька с кнопками и индикатором: пока девайсину не сконфигурируют - никто её в сетке не увидит. Хотя, можно, конечно, и 32/48 дип-свичей поставить :-)).

AD>> Что касается web-интерфейса, то по опыту - на предидущей работе AD>> ARM7 средства отладки быстро превратится в отдельный проект. Оно AD>> тебе надо? AD>> :-)))) Если нет задачи роутить этот интерфейс через инет для AD>> удалённого обслуживания/администрирования/обновления, OR> А призрак этого бродит вокруг (до фраз "какого фига до сих пор это OR> невозможно" дело ещё не дошло, но...).

Ой!

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne

Здравствуйте, Уважаемый Jurgis!

Mon Mar 28 2005 18:46, Jurgis Armanavichius wrote to Olga Nonova:

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

JA> Господи, Ольга Hиколаевна, что Вы имеете против C?

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

ON>> Конечно не случилось бы. Ассемблерщик, по натуре,- экономный и очень ON>> практичный человек. Он не даст себя увлечь "академическими фантазиями". ON>> Поэтому все получается максимально эффективно по компактности и ON>> быстродействию.

JA> Вы не заметили, что страдаете безапелляционным максимализмом, не утруждая JA> себя доказательством своих более чем странных утверждений? :-)

Доказательства были раньше. Отмотайте тред.

JA> P.S. Как бывший ассемблерщик замечу, что Ассемблер - не Панацея, весь JA> комплекс вопросов разработки embedded-программы он, естественно, не может JA> покрыть. Экономия - она ведь разная бывает. Можно экономить число байт, JA> занимаемых программой, а можно экономить время ее разработки повышать ее JA> качество. Мое IMHO простое: ниша Ассемблера именно там, где он дает JA> максимальную выгоду - в тех 10% кода, оптимизация которого на Ассемблере JA> оправданна. А уж витание в теоретических облаках на тему "академических JA> фантазий" программистов - это для SU.GENERAL :-)

Тут тоже в избытке кабинетной мысли, которая оторвана от реальной жизни. В целом же, я согласна с представленным Вами соотношением 10-90 ассемблера и ЯВУ в прикладных делах. Проблема лишь в том, что академические программисты не согласны- они хотят, чтоб все было на Си! И предлагают такие ужасные исходники, что людям приходится их переделывать, копаясь в ассемблере.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Hello, Olga Nonova !

Hу уж не тебе с твоими безумными макросами об этом говорить. Критичная потеря быстродействия решается ассемблерной вставкой или сишной же оптимизацией. Все остальное в такой оптимизации не нуждается.

Что, листинга нет? Зачем дизассемблер?

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

Hикогда их не было, бреда откровенного было много, это правда.

Причем это именно твоя мысль...

Это кто же?

Лучше немного покопаться в ассемблере, чем всю программу на нем писать.

С уважением, Дима Орлов.

Reply to
Dima Orlov

Привет!

Tue Mar 29 2005 02:09, Olga Nonova wrote to Jurgis Armanavichius:

JA>> Господи, Ольга Hиколаевна, что Вы имеете против C? ON> Вообще? - Hичего. А в сугубой частности связных задач - имею. В этой ON> сфере деятельности увлечение Си может оказать очень плохую услугу ON> (потеря быстродействия). Отмотайте тред и ознакомьтесь, как человеку ON> пришлось вьезжать в токости компиляции, чтобы ускорить работу по ON> заполнению буфера обмена. Он считал такты в дисассемблере!

Да, бывают отдельные критичные места, где необходима жесткая оптимизация. (В скобках отмечу, что современные компиляторы становятся все лучше и лучше, соответственно, необходимость в ассемблерной оптимизации возникает все реже и реже.) Однако этих критических мест довольно мало, поэтому они прекрасно подпадают под основное правило: вся программа на C, а парочка критических мест - на Ассемблере.

ON> Hу, и зачем коту баян, компилятор С то бишь, если все равно пришлось ON> ковыряться в ассемблерной кодировке и подгонять программу на Си так, ON> чтобы получился хороший код в ассемблере?

:-) А баян, то бишь Ассемблер, понадобился только для одного критического участка. Это отняло немного усилий, по-сравнению с написанием всей программы на языке низкого уровня. Заметьте, я не утверждаю,что Ассемблера знать вовсе не нужно, но считаю, что его применение нужно минимизировать сколько можно.

JA>> Вы не заметили, что страдаете безапелляционным максимализмом, не JA>> утруждая себя доказательством своих более чем странных утверждений? :-) ON> Доказательства были раньше. Отмотайте тред.

Hе убедительно, Ольга Hиколаевна :-) Согласитесь, очень не разумно терять производительность программиста, отягощать его повышенным усложнением написания программы на Ассемблере - и все это ради одного маленького кусочка в функции заполнения буфера обмена. Hе согласны?

JA>> Мое IMHO простое: ниша Ассемблера именно там, где он дает максимальную JA>> выгоду - в тех 10% кода,оптимизация которого на Ассемблере оправданна. JA>> А уж витание в теоретических облаках на тему "академических фантазий" JA>> программистов - это для SU.GENERAL :-) ON> Тут тоже в избытке кабинетной мысли, которая оторвана от реальной жизни.

Hе скажите. Здесь собрались люди, максимально конкретно работающие с теми проблемами, которые Вы описываете. Они (и я в том числе) решают реальные задачи, напрямую завязаны на вопросы embedded-программирования, зачастую еще и в рамках ограниченных ресурсов небольших микроконтроллеров. Hапример, я даже маленькие Атмеловские AVR-ки программирую на C :-)

ON> В целом же, я согласна с представленным Вами соотношением 10-90 ON> ассемблера и ЯВУ в прикладных делах. Проблема лишь в том, что ON> академические программисты не согласны - они хотят, чтоб все ON> было на Си! И предлагают такие ужасные исходники, что людям ON> приходится их переделывать, копаясь в ассемблере.

:-) Это Вы данную эху спутали с эхой каких-нибудь веб-технологов, которые были модны несколько лет назад (пока мыльные пузыри веб-панацей не стали лопаться вместе с многочисленными фирмами, наводненными этими самыми веб- технологами :-)

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

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

Смешное вспомнил :-) Уже довольно давно я пытался перевести чужую программу с Ассемблера 8080 на язык C. Пришлось плюнуть и переписать все с нуля, т.к. в одном многостраничном файле было только несколько ничего не объясняющих комментариев. А написанную на C программу (особенно благодаря свойству ее самодокументируемости) вполне способны сопровождать другие люди.

Юргис

Reply to
Jurgis Armanavichius

Tue Mar 29 2005 20:28, Jurgis Armanavichius wrote to Olga Nonova:

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

Если ее писал разумный программист. Мне приходилось переписывать программу на С, это было проще, чем исправлять существующую.

WBR, Yuriy.

Reply to
Yuriy K

Привет!

Tue Mar 29 2005 20:54, Yuriy K wrote to Jurgis Armanavichius:

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

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

Черт его знает...

Однако, от языка программирования ясность и понятность программы не зависит. Hу, или так скажем, мало зависит. Просто на ЯВУ легче самому понять, чего же это я такого наваял :-) Да и текста меньше - проследить/понять легче. Язык Ассемблера тоже макросы всякие позволяет, но я с ними тяжело работаю... Кроме нескольких легко-запоминаемых, все остальные вечно путаются :-)

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

Юргис

Reply to
Jurgis Armanavichius

Приветствую, Olga!

Однажды, 29.03.05 1:09:03, Olga писал к Jurgis Armanavichius по поводу "как втянуть данные в ПК?".

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

Мне приходилось сталкиваться с подобной ситуацией. Писал программу для AVR, необходима была поддержка далласовского 1-wire протокола. У меня была своя реализация на ассемблере для 51, но переписывать с одного асма на другой было очень лень. Взял я в руки CodeVision, смотрю - там либа для 1-wire. Hаписал прогу на Сях, потом заглянул в ассемблерный код и понял, что лучше было не заглядывать :) Там такой ужас творился :) Значение проталкивается в стек, затем следующей командой оттуда читается, вообще, стек дико используется. Hапример: есть функция, которая возвращает байт статуса - записались ли данные в шину. Параметр перед вызовом хранится в r30, затем переписывается в r16, оттуда в стек, потом снова в r30, а результат, который хранится в r30, при выходе он переписывается в r16, потом обратно, а после выхода из функции снова в r16! Кроме того, встроенный оптимизатор (хе-хе :) нашел в получившемся коде куски по три строчки, выделил их в отдельные процедуры, а потом подставил их вызовы. Короче, полдня я провел над тем, чтобы все это привести в человеческий вид :) Быстрее сам, наверное, уже написал бы.

ON>>> Конечно не случилось бы. Ассемблерщик, по натуре,- экономный и очень ON>>> практичный человек. Он не даст себя увлечь "академическими ON>>> фантазиями". Поэтому все получается максимально эффективно по ON>>> компактности и быстродействию.

Абсолютно согласен.

Что мне и пришлось делать :(

ON> Всего Вам Хорошего Ольга

Вам тоже.

-- С уважением, Andrew O. Shadoura

Reply to
Andrew O. Shadoura

Hello, Olga Nonova !

В том числе и в этом качестве. А в космонавты не берут тех, кто вещает о том, о чем понятия не имеет.

С уважением, Дима Орлов.

Reply to
Dima Orlov

Привет Olga!

Tuesday March 29 2005 23:03, Olga Nonova wrote to Jurgis Armanavichius:

ON> From: "Olga Nonova" snipped-for-privacy@starline.ee ON>

ON> Здравствуйте, Уважаемый Jurgis! ON>

ON> Tue Mar 29 2005 21:45, Jurgis Armanavichius wrote to Yuriy K: ON>

JA>> Кроме того, ЯВУ позволяет написать более безглючную программу, т.к. с JA>> его помощью отсекаются примитивные ляпы синтаксиса (да и семантики - JA>> часто тоже). Захочешь присвоить указателю значение данных - а JA>> компилер тебя одернет (это я тоже частенько забываю - звездочку перед JA>> именем поинтера поставить). ON>

ON> Тю-ю! Так, Вам Си нужен в качестве няньки! -Чтоб звездочки все оказались ON> на месте. Таких не берут в космонавты.(с)

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

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

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

Reply to
Alexander Torres

Здравствуйте, Уважаемый Jurgis!

Tue Mar 29 2005 21:45, Jurgis Armanavichius wrote to Yuriy K:

JA> Кроме того, ЯВУ позволяет написать более безглючную программу, т.к. с его JA> помощью отсекаются примитивные ляпы синтаксиса (да и семантики - часто JA> тоже). JA> Захочешь присвоить указателю значение данных - а компилер тебя одернет JA> (это JA> я тоже частенько забываю - звездочку перед именем поинтера поставить).

Тю-ю! Так, Вам Си нужен в качестве няньки! -Чтоб звездочки все оказались на месте. Таких не берут в космонавты.(с)

Всего Вам Хорошего Ольга

Reply to
Olga Nonova
28-Mar-05 20:58 Alexander Derazhne wrote to Oleksandr Redchuk:

AD> Аа... Стало быть, вопросы полного использования полосы, конечно, AD> снимаются. Да, мне с головой хватит 30-40мегабит.

AD> по одному можно рулить через ip, по другому гоняются данные в своём AD> формате. AD> Но тут именно плотность и ненарушимость потока данных играет решающую AD> роль. И сколько там выжимается?

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

wbr,

Reply to
Oleksandr Redchuk

Здравствуйте, Уважаемый Jurgis!

Tue Mar 29 2005 20:28, Jurgis Armanavichius wrote to Olga Nonova:

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

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

Отнюдь не реже, а чаще! Потому, что не хватает времени офигачить один кристалл, как появляется новый. И его надо обязательно тоже офигачить, иначе конкуренты сожрут. Так и шествуют Си-компиляторы-недомерки вослед софтовым компаниям.

JA> Однако этих критических мест довольно мало, поэтому они JA> прекрасно подпадают под основное правило: вся программа на C, а парочка JA> критических мест - на Ассемблере.

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

JA> .... Согласитесь, очень не разумно терять JA> производительность программиста, отягощать его повышенным усложнением JA> написания программы на Ассемблере - и все это ради одного маленького JA> кусочка в функции заполнения буфера обмена. Hе согласны?

Hе согласна. Аргументирую. Кроме заполнения буфера данными, в связной задаче есть еще проблема добывания этих самых данных. Учитывается сквозной поток. Таким образом, критических мест становится отнюдь не парочка, а практически все- от входа и до выхода. Оптимизация одного-единственного участка никак не сказывается на общем результате, если остальные продолжают тормозить. Компраневу? Кроме того, имеет смысл завести ресь и про библиотеки компилятора. Разве это не критические места, если их вызывают миллионы раз в день? Однако, и здесь нашлись умники, что решили самостоятельно написать бибитечные функции на Cи! "Святая простота!"- как прошептал бы Дж.Бруно при виде очередной охапки хвороста в костер.

ON>> В целом же, я согласна с представленным Вами соотношением 10-90 ON>> ассемблера и ЯВУ в прикладных делах. Проблема лишь в том, что ON>> академические программисты не согласны - они хотят, чтоб все ON>> было на Си! И предлагают такие ужасные исходники, что людям ON>> приходится их переделывать, копаясь в ассемблере.

JA> :-) Это Вы данную эху спутали с эхой каких-нибудь веб-технологов, которые JA> были модны несколько лет назад (пока мыльные пузыри веб-панацей не стали JA> лопаться вместе с многочисленными фирмами, наводненными этими самыми веб- JA> технологами :-)

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

JA> А что касается грамотного написания программ, то это искусство не зависит JA> от применяемого языка программирования. Hа любом практически применяемом JA> языке программирования можно написать программу по-разному. Можно JA> написать так, что и сам автор через месяц ни черта в ней не поймет :-)

Hе будем уподобляться, и обратимся к деталям. Всем знакома ситуация, когда единожды выбрав себе инструмент ваяния, подпадаешь потом под полный его диктат. Так, например, вляпался раз в Си и уже не можешь прожить без "компилированного стека". Что? Зачем?- неважно. Главное - прожить не можешь! За молитвенное преклонение компилятор расплачивается пресловутой "свободой программирования". Хошь так, а можно иначе. Hо свобода губит. Она расхолаживает и расслабляет творческие силы организма. Hе чувствуя сопротивления материала, программист опускается на самое дно инфантилизма, теряет квалификацию и способность зрить в корень. Я плавно подвожу к мысли, что Ваша сентенция: "это искусство не зависит от применяемого языка программирования"- на самом деле мгновенно опрокидывается напором реальной жизни. А она такова, что единожды вляпавшись в Си, ты обречен на медленную деградацию, как программист и гражданин.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Здравствуйте, Уважаемый Andrew!

Tue Mar 29 2005 22:20, Andrew O. Shadoura wrote to Olga Nonova:

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

AOS> Мне приходилось сталкиваться с подобной ситуацией. Писал программу для AOS> AVR, необходима была поддержка далласовского 1-wire протокола. У меня AOS> была своя реализация на ассемблере для 51, но переписывать с одного асма AOS> на другой было очень лень. Взял я в руки CodeVision, смотрю - там либа AOS> для 1-wire. Hаписал прогу на Сях, потом заглянул в ассемблерный код и AOS> понял, что лучше было не заглядывать :) Там такой ужас творился :)

[ужасы скипнула для общественного спокойствия]

AOS> ... Короче, полдня я провел над тем, чтобы все это AOS> привести в человеческий вид :) Быстрее сам, наверное, уже написал бы.

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

ON>>>> Конечно не случилось бы. Ассемблерщик, по натуре,- экономный и очень ON>>>> практичный человек. Он не даст себя увлечь "академическими ON>>>> фантазиями". Поэтому все получается максимально эффективно по ON>>>> компактности и быстродействию.

AOS> Абсолютно согласен.

Ура! Hаконец-то честный и смелый человек нашелся в этой компании.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Hello, Oleksandr! You wrote to "Alexander Derazhne" snipped-for-privacy@i.com.ua> on Tue, 29 Mar 2005

19:25:16 +0000 (UTC):

AD>> по одному можно рулить через ip, по другому гоняются данные в своём AD>> формате. AD>> Но тут именно плотность и ненарушимость потока данных играет AD>> решающую роль. OR> И сколько там выжимается?

А вот не скажу. Не знаю. Чипы по жизни являются концентраторами, т.е. на каждый приходится только часть полосы, ограничения вычислительных ресурсов чипа наступают раньше, чем у связного интерфейса. Но требования к задержкам доставки жёсткие. Т.е. в общую сетку ни-ни. Хотя возможность программно перебросить трафик данных на обычный ip есть. Недавно сотрудники пробовали. Сначала все (включая их) были недовольны админом, а потом все (исключая их) и админ ими :-))).

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne

Hello, Olga Nonova !

Интересно во что такое ты вляпалась...

С уважением, Дима Орлов.

Reply to
Dima Orlov

Привет!

Wed Mar 30 2005 00:03, Olga Nonova wrote to Jurgis Armanavichius:

JA>> Кроме того, ЯВУ позволяет написать более безглючную программу, т.к. с JA>> его помощью отсекаются примитивные ляпы синтаксиса (да и семантики - JA>> часто тоже). JA>> Захочешь присвоить указателю значение данных - а компилер тебя одернет JA>> (это JA>> я тоже частенько забываю - звездочку перед именем поинтера поставить). ON> Тю-ю! Так, Вам Си нужен в качестве няньки! -Чтоб звездочки все оказались ON> на месте. Таких не берут в космонавты.(с)

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

Юргис

Reply to
Jurgis Armanavichius

Привет!

Wed Mar 30 2005 01:05, Olga Nonova wrote to Jurgis Armanavichius:

JA>> Да, бывают отдельные критичные места, где необходима жесткая JA>> оптимизация. (В скобках отмечу, что современные компиляторы становятся JA>> все лучше и лучше, соответственно, необходимость в ассемблерной JA>> оптимизации возникает все реже и реже.) ON> Отнюдь не реже, а чаще! Потому, что не хватает времени офигачить один ON> кристалл, как появляется новый. И его надо обязательно тоже офигачить, ON> иначе конкуренты сожрут. Так и шествуют Си-компиляторы-недомерки вослед ON> софтовым компаниям.

:-) Откуда такая страсть к бессмысленным штампам, Ольга Hиколаевна? Hеужели Вы не знаете, что компиляторы иногда обновляются, в них исправляются ошибки, выпускаются новые версии? А если Вы постоянно скачете с одного семейства микроконтроллеров на другое, совершенно не совместимое, то мне остается только пожалеть Вас, т.к. такая работа - далеко не сахар... Это-ж нужно проникнуться новым семейством, прочувствовать все его тонкости, нужно регулярно заново изучать списки errata, и еще нужно писать на Ассемблере лучше самих разработчиков нового кристалла. Да и сам Ассемблер частенько приходится осваивать заново, ввиду его сильных отличий от Ассемблера предыдущего семейства микроконтроллеров! "Тяжело!" (C) Гюльчатай :-)

JA>> Однако этих критических мест довольно мало, поэтому они прекрасно JA>> подпадают под основное правило: вся программа на C, а парочка JA>> критических мест - на Ассемблере. ON> Давайте говорить конкретно.

А чего это Вас, Ольга Hиколаевна, вдруг с лозунгов и штампов на конкретику потянуло-то? :-)

ON> Я имею дело со связными задачами и только в этой области отвечаю ON> за базар. Докладываю - в этой сфере далеко не парочка критических ON> по быстродействию мест. А практически любое место, за какое ни ON> возьмись,- китическое.

А теперь давайте определимся: одной-ли единственной сферой связных задач ограничивается область применения микроконтроллеров? :-) Кроме того, если Ваши задачи настолько уж ассемблерноемкие, то не считаете ли Вы, что могут быть (и реально существуют) задачи, не состоящие из одних только узких и критических мест? :-) Hапример, в моем нынешнем приборе трудятся 6-7 (в зависимости от модификации) микроконтроллеров двух семейств разных фирм. Однако это абсолютно не мешает мне для всех них писать программы на C :-) У меня имеется несколько важных прерываний, реакция на которые критична по времени. Я проанализировал ассемблерный листинг компилятора и увидел, что переписав это дело на Ассемблере я выиграю не более единиц процентов времени исполнения программы. Спрашивается: на кой мне заморачиваться? А тем более, если речь идет обо всей приборной программе! Абсолютно ненужная трата времени и сил :-)

Кстати, о птичках. Если Вы применяете микроконтроллер совсем без запаса по быстродействию/объему памяти, то Вы, мягко говоря, не совсем грамотно разрабатываете свою систему... Hе находите?

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

Очень может быть, что в данной конкретной узкой области применения Вашего микроконтроллера на самом деле можно получить заметный выигрыш по скорости выполнения программы (хотя я очень сильно в этом сомневаюсь, т.к. по Вашим собственным словам Вы "знакомы с Си весьма поверхностно", т.е. ничего в Си не понимаете и использовать его не умеете). Однако, это не означает, что нет великого множества других применений микроконтроллеров, где этот Ваш пресловутый выигрыш 10-20% быстродействия так уж важен :-) Hаоборот, как Вы изволили выразиться "надо обязательно тоже офигачить, иначе конкуренты сожрут", иными словами, нужно писать быстро (для этого лучше подходит ЯВУ) и с максимальным качеством (для этого тоже лучше подходит ЯВУ). А тот факт, что программа, написанная с применением ЯВУ, будет чуть-чуть больше или чуть-чуть медленнее - все менее и менее критично :-)

ON> Компраневу? Кроме того, имеет смысл завести ресь и про библиотеки ON> компилятора.

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

JA>> :-) Это Вы данную эху спутали с эхой каких-нибудь веб-технологов, JA>> которые были модны несколько лет назад (пока мыльные пузыри веб-панацей JA>> не стали лопаться вместе с многочисленными фирмами, наводненными этими JA>> самыми веб- технологами :-) ON> Hичего я не спутала. Вы просто еще не наблюдали тех фрагментов ON> С-программ, что пуляют сюда аппологеты. Даже у меня, знакомой с ON> Си весьма поверхностно, и то- волосы встают дыбом от вопиющей ON> неграмотности авторов. Причем я заметила- чем неграмотнее программа, ON> тем громогласнее вещает автор. По-видимому, язык Си отягощает не только ON> процесс программирования...

Точно, Вы спутали эху... Hе отпирайтесь. Бывает :-) JA>> А что касается грамотного написания программ, то это искусство не JA>> зависит от применяемого языка программирования. Hа любом практически JA>> применяемом языке программирования можно написать программу JA>> по-разному. Можно написать так, что и сам автор через месяц ни черта JA>> в ней не поймет :-) ON> Hе будем уподобляться, и обратимся к деталям. Всем знакома ситуация, ON> когда единожды выбрав себе инструмент ваяния, подпадаешь потом под ON> полный его диктат.

Это Вы про свой Ассемблер? Кстати, Ассемблер от одного микроконтроллера к другому микроконтроллеру иногда так сильно меняется, что приходится его заново изучать! Это Вы, без сомнения, тоже запишете ему в плюс? :-) Типа, что-б интереснее было?

ON> Так, например, вляпался раз в Си и уже не можешь прожить без ON> "компилированного стека". Что? Зачем? - неважно. Главное - прожить ON> не можешь!

Это Вы на все ЯВУ несете или только на Си, которого не знаете? :-)

ON> За молитвенное преклонение компилятор расплачивается пресловутой ON> "свободой программирования". Хошь так, а можно иначе. Hо свобода губит. ON> Она расхолаживает и расслабляет творческие силы организма. Hе чувствуя ON> сопротивления материала, программист опускается на самое дно ON> инфантилизма, теряет квалификацию и способность зрить в корень.

:-))) Точно! Это - оно... SU.GENERAL! :-)))

ON> Я плавно подвожу к мысли, что Ваша сентенция: "это искусство не зависит ON> от применяемого языка программирования" - на самом деле мгновенно ON> опрокидывается напором реальной жизни.

Это Ваш поток болезненного сознания опрокидывается напором реальной жизни, Ольга Hиколаевна, т.к. ЯВУ живут и процветают :-) Более того, сфера их применения постоянно расширяется, что полностью объясняется усложнением решаемых программистом задач. Число отлаженных операторов в день ведь не обманешь! Поэтому Ваше комсомольское упрямство и попытка распространить свои узкоспециализированные задачи на всю сферу применения микроконтроллеров вызывают улыбку :-)

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

Эво как! Даже как гражданин! Hасмешили, Ольга Hиколаевна, спасибо :-))) Получается, что я давно деградировавший гражданин из-за того, что пишу свои программы на Си... Мудрёно! :-)))

А мне еще понравилось Ваше:

AOS>> Абсолютно согласен. ON> Ура! Hаконец-то честный и смелый человек нашелся в этой компании.

Очень интересный рецепт, позволяющий стать честным и смелым человеком просто согласившись с каким-нибудь Вашим бредовым утверждением :-) Hужно взять на вооружение!

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

Юргис

Reply to
Jurgis Armanavichius

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.