Здравствуйте Sergey, Вы писали:
S>Здравствуйте Andir, Вы писали:
ВГ>>>Квантовая теория — это для разработчиков камней А если серьезно, то как тот же Шумахер может настроит свой болид, НЕ ЗНАЯ, как работают тормоза, подвеска, и т.д. ? A>>Не должен он его настраивать, не должен. Это не его профессиональная область.
S>Ну так настраивает же. Вместе с механиками, естественно.
Здравствуйте Владимир Гренадеров, Вы писали:
ВГ>Здравствуйте Mr-Twister, Вы писали:
MT>>Не покажусь ли я эгоистом , но может на RSDN сделать ветку по ассемблеру ? ВГ>Скорее надо сделать этакий FAQ — ведь профессионально писать на асме сейчас будут немногие ВГ>А так начинающий С++ программист сможет наконец понять, что же такое этот таинственный стэк, и как его переполнить
Здравствуйте Хитрик Денис, Вы писали:
ХД>Здравствуйте Eugene, Вы писали:
ХД>В сторону: В плане сравнения с Шумахером, мне кажется больше подойдёт знание не термодинамики, а механики в плане обтекаемости машины, её устойчивости в поворотах etc., при этом с привлечением знаний, выработанных профессионалами в своих областях: в области конструирования ДВС, дизайна кузова (в плане той же обтекаемости и устойчивости). То есть они дают определённую исходную информацию и сам болид, обладающий этими известными характеристиками, а Шумахер как професионал, должен извлечь из этого аппарата и его данных наименьшее время на круге.
Шумахер — не компьютер, а просто гонщик. Может, конечно, он и вникает в суть физического процесса, почему именно на изношенной резине машина хуже держит трассу и чем дождевая резина от "сухой" отличается. Но я в этом искренне сомневаюсь! Мое мнение, раз уж вы зацепили эту тему, — представления Шумахера о болиде весьма поверхностны. Они ему и не нужны: он "мыслит" другими категориями. "Машина не держит трассу в повороте", "руль излишне пуст или излишне нагружен" и т.д. и т.п. А вот почему это происходит и как это поправить — это уже задача инженеров. Понять Шумахера и сделать так как надо. Неправда ли, очень похоже на программистов и постановщиков задач?
Здравствуйте Dr_Sh0ck, Вы писали:
DS>Здравствуйте Mishka<T>, Вы писали:
MT>>Не думаю, что Шумахеру позволяют руками лезть в мотор, там без него есть профи по настройке болидов.
DS>Так сейчас болид целиком напихан всякими компьютерами. Куда не ткни — везде процесоры. а Шумахер-то ассемблера не знает . Так вот ему инженеры и не дают туда лазить
Жаль баллов 100 не могу поставить за "а Шумахер-то ассемблера не знает"!!!
[skipped]
TL>А зачем ему все это? Если ему надо запрограммировать рассчет квантовой теории или биологической реакции — зачем ему соваться в COM и т.п.? И зачем ему проектировать распределенные вычисления? Может пусть этим программист занимается? Пусть и создает срдество для реализации "абстрактных моделей и алгоритмов" без привязки к конкретному компьютеру. Слабо?!
Почти готов согласиться. "Почти" — потому, что правильного ответа на этот вопрос не существует. Истина может рождаться в споре. Т.е. мы здесь сейчас пытаемся ее родить
P.S. Но все-таки согласись, что знание ассемблера вряд ли помешает
Здравствуйте Dr_Sh0ck, Вы писали:
DS>Здравствуйте The Lex, Вы писали:
DS>[skipped]
TL>>А зачем ему все это? Если ему надо запрограммировать рассчет квантовой теории или биологической реакции — зачем ему соваться в COM и т.п.? И зачем ему проектировать распределенные вычисления? Может пусть этим программист занимается? Пусть и создает срдество для реализации "абстрактных моделей и алгоритмов" без привязки к конкретному компьютеру. Слабо?!
DS>Почти готов согласиться. "Почти" — потому, что правильного ответа на этот вопрос не существует. Истина может рождаться в споре. Т.е. мы здесь сейчас пытаемся ее родить
DS>P.S. Но все-таки согласись, что знание ассемблера вряд ли помешает DS>
Не согласюсь! И не только потому, что "Баба Яга против". А еще потому что ассемблер очень часто может выступать "лишними знаниями", сбивать человека на другой способ мышления. И по-моему этот способ мышления очень часто далек от рационального.
Разумеется, большинство из нас, кого можно назвать "старичками", или по крайней мере "дядьками" (ничего, что я и себя сюда причислил? ), в свое время изучали ассемблер и даже смотрели на осцилограммы работы 8088 в пошаговом режиме. Некоторые и сейчас смотрят и это ни в коей мере не является признаком их "замшелости" — просто работа у них такая. Но вот нужно ли это молодым?
По-моему ассемблер и все что с ним связано на данном этапе развития ПО и средств его разработки очень далеко отстоят от реальных задач и понятий, которыми оперируют эти задачи. И ближе он не станет. У ассемблера осталась ниша — низкоуровневая разработка разного рода "железа". Да и то только для того, чтобы реализовывать некоторые конкретные, четко определенные, "чисто железные" функции. Так как логику программы все равно удобнее писать на C или C++.
Разумеется это все всего лишь мое злобное нескромное мнение.
Здравствуйте Mr-Twister, Вы писали:
MT>Изучая Си, кто то написал мне в одном из ответов: Учи ассемблер поможет. MT>Интересно поинтерисоваться, стоит ли учить этот язык (с виду не простой), или достаточно ограничиться Си и в будущем Си++ ?
В общем программист должен знать логику работы компьютера хотябы в общих чертах(как выполняются операции, как формируется адрес, как хранятся файлы на диске и т.д.) Изучить это можно несколькими путями — один из них изучить ассемблер, хотябы поверхностно. В полном объеме он большинству и не нужен. Но ассемблер можно и не изучать, эти знания все равно прийдут при более углубленном изучении С( ага! Операнды в функцию передаются через стек. А что такое стек? А как? и пошло поехало — это к примеру ).
К томуже, но это только мое личное мнение, в рамках познавательной деятельности, можно разделить на две категории:
1. Люди не могут идти далее до тех пор, пока до мелочей не изучат тот материал, на котором базируется последующий.
2. Люди, которым достаточно знать то, что необходимо для выполнения задачи.
Вот и получается написал ты с=a+b; и сидишь недоумеваешь каким образом компьютер выполняет эти операции, а если b отрицательное число? И не можешь двинуться дальше — тогда ознакамливайся с аасемблером.
В общем учить ассемблер не нужно, но в той или иной степени его знает каждый программист. Вот и решай сам как тебе быть бегло ознакомится с ним в полном объеме( это не один и не два дня) или по мере необходимости. Но ознакомиться все равно прийдется.
Здравствуйте User99, Вы писали:
U>Здравствуйте Mr-Twister, Вы писали:
MT>>Изучая Си, кто то написал мне в одном из ответов: Учи ассемблер поможет. MT>>Интересно поинтерисоваться, стоит ли учить этот язык (с виду не простой), или достаточно ограничиться Си и в будущем Си++ ?
U>В общем программист должен знать логику работы компьютера хотябы в общих чертах(как выполняются операции, как формируется адрес, как хранятся файлы на диске и т.д.) Изучить это можно несколькими путями — один из них изучить ассемблер, хотябы поверхностно. В полном объеме он большинству и не нужен. Но ассемблер можно и не изучать, эти знания все равно прийдут при более углубленном изучении С( ага! Операнды в функцию передаются через стек. А что такое стек? А как? и пошло поехало — это к примеру ).
Ну стек... А при чем тут ассемблер?
U>Вот и получается написал ты с=a+b; и сидишь недоумеваешь каким образом компьютер выполняет эти операции, а если b отрицательное число? И не можешь двинуться дальше — тогда ознакамливайся с аасемблером.
Тогда "бросай ружье и всплывай" — никакой ассемблер уже не поможет...
U>В общем учить ассемблер не нужно, но в той или иной степени его знает каждый программист. Вот и решай сам как тебе быть бегло ознакомится с ним в полном объеме( это не один и не два дня) или по мере необходимости. Но ознакомиться все равно прийдется.
Здравствуйте Mr-Twister, Вы писали:
MT>А языки Си и С++ просто переедут на другую систему и не поменяют свой синтаксис.
На мой взгляд, человеку, "всласть" попрограммировавшему на ассемблере, гораздо проще понять всю красоту, лаконичность и удобство сначала структурных (которыми, собственно, и являются современные ассемблеры), а потом и объектно-ориентированных языков и сред. Вопросов типа "а зачем различаются строчные и заглавные буквы", "почему разделяются struct и class" становится существенно меньше.
Так что я считаю, что "путь гуру" обязательно проходит (обычно в начале) через "джунгли Ассемблера".
Здравствуйте Mishka<T>, Вы писали:
MT>Здравствуйте Mr-Twister,
MT>Я б советовал ерундой не заниматься, а тихо мирно переходить на IL из .NET. Мы всё равно все там будем, а это и есть тот самый ассемблер, но новый.
Новое — не значит лучшее (фу, как банально ;) ), а насчёт "того самого" — скорее не согласен.
MT>Ассемблер — простой язык, а вот то, как работает компьютер, к ассемблеру мало относится, поэтому тот же ассемблер на разных платформах сильно отличается. Если Microsoft всё таки правы со своей идеей .NET-a, то IL — это хороший выбор, поскольку он будет переносим на разные платформы и плюс к тому же он стандартизован.
Насколько я разобрался в IL, практически все данные там идут через стек. На мой взгляд, это довольно неэффективная организация. IMHO, IL потребуется только разработчикам компиляторов под .net и тем, кто хочет полной минимизации кода и нереализованных в языке конструкций, а всё остальное подомнёт под себя C# и компания.
А уж если нужно чего-то действительно быстродейственное написать (собственно, для чего ещё ассемблером пользоваться?) то IL в любом случае проиграет в быстроте native ассемблеру, использующему многообразие регистров и распределение по конвейерам. Для примера попробуйте реализовать достаточно неочевидный алгоритм на IL, а потом дизассемблируйте сгенерированный ngen код.
Здравствуйте The Lex, Вы писали:
TL>По-моему ассемблер и все что с ним связано на данном этапе развития ПО и средств его разработки очень далеко отстоят от реальных задач и понятий, которыми оперируют эти задачи. И ближе он не станет. У ассемблера осталась ниша — низкоуровневая разработка разного рода "железа". Да и то только для того, чтобы реализовывать некоторые конкретные, четко определенные, "чисто железные" функции. Так как логику программы все равно удобнее писать на C или C++.
Чего все на железе зациклились — я вот, например, для фотошопа фильтры на досуге пишу, и ММХ утилизирую достаточно сильно, причем я сомневаюсь, что какой-либо компилятор, каким бы он интеллектуальным ни был, сделает это лучше чем я вручную, а те, кто 3д-движки разрабатывает, а те кто защиты разрабатывает с примененим полиморфизма, самомодификации, да и много можно придумать...
Естественно, это требует достаточно высокой квалификации, но все таки... TL>Разумеется это все всего лишь мое злобное нескромное мнение.
Хе-хе, а это мое не менее скромное
В моей практике мне как-то встретилась задача оптимизации отрисовки лабиринта в одной DOOM-образной игре. После применения ASM и технологии MMX у меня FPS подскочил с 40 до 140. При этом я переписал всего два цикла и потратил на это всего около 3.5 часов. Так что мне кажется, что ASM знать надо. А заодно и методы оптимизации под современные процессоры. (В том числе и MMX)
Мне самому достаточно много приходится общаться с программерами, и независимо от того, на каком языке они сейчас пишут, замечаешь, что люди, знающие ассемблер и в свое время писавшие даже минимальные ассемблерные программы гораздо лучше понимают "как же все это на самом деле работает" и от них получаешь меньше "странных" вопросов. Наоборот же, народ, пришедший на С++ со скриптовых языков типа VB или перл, достаточно тяжело вникает, особенно в такие понятия как указатели. А если надо сделать что то сложнее обычного класса, тогда вообще начинается "ОЙ". Это примерно как дамы, которые ездят на автомобиле, но не могут в нем найти свечи зажигания, при условии, что в некоторых моделях их может и не быть Хотя у них (не у дам, см пред. предложение ) зачастую с логикой дела получше обстоят, нежели у человека, совсем не знакомого с регулярными выражениями.
И при приеме на работу я лично интересуюсь знанием ассемблера (не именно i8086, а просто знанием любого, хоть i8080 или Z80), это гарантирует минимальный уровень грамотности. Независимо от того, что делает человек именно сейчас, и на чем он пишет обычно.
Мне же лично нравится знать ассемблер просто потому, что я понимаю, как это работает там глубоко внутри на самом деле, а также помогает отлавливать баги на основе тех же значений в стеке... Заметьте, знать, а не писать на нем.
Но опять же, это просто личные наблюдения, возможно, вызванные спецификой решаемых задач. Флейм по этому постингу устраивать не надо, отвечать все равно не буду А вообще — знание любого языка программирования не только добавляет немного ++'ов к резюме отдельно взятого человека, но и помогает ему решать поставленную задачу наиболее оптимально.
Всем спасибо за внимание и успехов в программинге (и изучении ассемблера).
Здравствуйте, Lonely Dog, Вы писали:
LD>В моей практике мне как-то встретилась задача оптимизации отрисовки лабиринта в одной DOOM-образной игре. После применения ASM и технологии MMX у меня FPS подскочил с 40 до 140. При этом я переписал всего два цикла и потратил на это всего около 3.5 часов. Так что мне кажется, что ASM знать надо. А заодно и методы оптимизации под современные процессоры. (В том числе и MMX)
учитывая то, как бурно развивается сегодня индустрия графических акселераторов....
Графика (а тем более риалтайм) — это совсем другая сфера, чем прикладное и даже некоторое системное программирование. При программировании риалтайм графики раньше использовали
— ручное выравнивание полей структур
— насильственное приведение типов (указатили кастятся к int-у за милую душу)
— грубые вычисления с фиксированной точкой (иногда использовалась фиксированная точка 8.8 или даже 12.4 ! Зато в два байта влезает, в одном регистре — два числа )
— void* указатели
— код на C и только на C, поскольку нельзя доверять C++овскому управлению памятью, из-за него может всё в неподходящий момент заттормоззитььсяяя ^_^.
— никакой нафик инкапсуляции и полиморфизьма ! Процедурный подход спасёт мир !
— ну, и на фоне этого свинства полировка критичных участков кода на асме (чтоб на один прохд цикла текстурирования уходило тактов по пять по шесть ^_^) выгляд вполне естественной забавой.
В Watcom C (был такой самый лучший компилятор под DOS) была такая штучка — #pragma, можно было мешать макросы, написанные на асме с C-шным кодом, так во втором Doom-е местами такая лапша была... Когда в модуле #pragma больше чем C-шного кода...
Так вот. А сейчас игрушки (и демки) пишут на C++ ^_^
Здравствуйте, Lonely Dog, Вы писали:
LD>В моей практике мне как-то встретилась задача оптимизации отрисовки лабиринта в одной DOOM-образной игре. После применения ASM и технологии MMX у меня FPS подскочил с 40 до 140. При этом я переписал всего два цикла и потратил на это всего около 3.5 часов. Так что мне кажется, что ASM знать надо. А заодно и методы оптимизации под современные процессоры. (В том числе и MMX)
Да, ещё забыл сказать.
Intel — ДЕРЬМО !!!!!
Только для того, чтобы понять это, надо изучать ассемблер ^__________^
Здравствуйте, Mr-Twister, Вы писали:
MT>Изучая Си, кто то написал мне в одном из ответов: Учи ассемблер поможет. MT>Интересно поинтерисоваться, стоит ли учить этот язык (с виду не простой), или достаточно ограничиться Си и в будущем Си++ ?
Чем больше знаешь тем проще... всё таки ассемблер основа.
MT>Мои мысли. Техника движется. Вроде как не стоит на месте. Значит и процессоры, тоже меняются, и возможно в скором необозримом будущем, схема работы процессора может поменять свою структуру . Тобишь будет не ассемблер , а что то другое , работающее по другим принципам и механизмам, отличающихся от процессоров Интел. MT>А языки Си и С++ просто переедут на другую систему и не поменяют свой синтаксис.
Боюсь, что когда процессоры настолько изменяться что там исчезнет ассемблер (не измениться набор команд, а именно исчезнет) то и С++ там уже жить не будет...
А если серьезно, то как тот же Шумахер может настроит свой болид, НЕ ЗНАЯ, как работают тормоза, подвеска, и т.д. ? 
, но может на RSDN сделать ветку по ассемблеру ? 
ICQ#: 198114726
Не хочешь — заставим! 
