Как часто вы используете ассемблер?

Цитата AndNot @ 30.03.08, 16:28

Те устройства, на 8086, пошли в серию

Всмысле их снова штампуют или я чето не понял

Ну процессоры аля пентиум 166 выпускают и до сих пор, правда не в таких количествах. Одно из применений - встраиваемые технологии. К примеру, коммутационное поле большой ЭАТС основывается на нескольких слабеньких пнях, не обязательно, но на практике наблюдал - КС Siemens EWSD.
Хотя в последнее время заметил, что в области автоматизации все больше применяются ARMы - архитектура проще, нету пережитков обратной совместимости ну и т.д.

Barbosman верно сказал, но старье применяется еще шире. И объяснение этому простое, оно доступно по цене и производительность для многих задач вполне приемлема.
А 8086 видел в продаже не более года назад, в магазине радиоэлектроники Выходит, что выпускают.

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

Так например считаю писать GUI "офисное" приложение для работы с БД на ассемблере - изврат, на С++ - нецелесообразно, зато на VB / VB.Net - оптимально.
В то же время писать драйвер на ассемблере - нецелсообразно, на C++ - оптимально.
Писать прошивку для AVRки на C++ - нецелесообразно, на ассемблере - оптимально (только для слабых AVRок)

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

ИМХО ассеблер знать обязательно! Только зная ассемблер можно грамотно писать программы, в том числе на ЯВУ.
А чаще всего используется ассемблер только для реверсинга.

Сообщение отредактировано: KillerXX7 - 29.07.08, 12:07

Цитата KillerXX7 @ 29.07.08, 12:05

В то же время писать драйвер на ассемблере - нецелсообразно, на C++ - оптимально.

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

Цитата KillerXX7 @ 29.07.08, 12:05

В то же время писать драйвер на ассемблере - нецелсообразно, на C++ - оптимально.

Уверен? По твоему оптимально писать драйвер для работы с железом на языке, у которого отсутствуют средства для работы с этим самым железом??????

AndNot
Помойму оптимальнее писать драйвера на Си. У него есть макро средства классы и прочее. Что позволяет работать с портами в виде port[]
Или Write()/Read(). Порты отоброженные в память тоже используются как массивы.
Я незнаю как вы на ассемблере будете писать драйвера. Железо такое сложное стало. Это не однна две команды как было раньше. Это одна две функции которые нужно вызвать чтобы сделать элементарное действие.

Насчет Си согласен Просто я не понимаю тех, кто пытается впихнуть плюсы везде где не нужно
А железо и раньше было разным, как простым, так и сложным. Но ведь писали и на асме. Да и сишный код зачастую получается сложнее, нежели асмовский. Сравни те же драйвера для PS/2 мышей под винду. Сишный код выглядит просто ужасно и раздут по самое нехочу. На ассемблере тот же код выглядит более наглядным и понятным.

Цитата Pavia @ 29.07.08, 15:37

У него есть макро средства классы и прочее. Что позволяет работать с портами в виде port[]

Это Pascal В Си - inportb()/outportb() и т.д.
Для Memory Mapped просто обращение через указатели.

Цитата Pavia @ 29.07.08, 15:37

Я незнаю как вы на ассемблере будете писать драйвера. Железо такое сложное стало. Это не однна две команды как было раньше. Это одна две функции которые нужно вызвать чтобы сделать элементарное действие.

Лёгко Ничего настолько сложного там нет.

Цитата cppasm @ 30.07.08, 07:34

Это Pascal В Си - inportb()/outportb() и т.д.

К слову сказать это даже не средства Си, а "самопальные" расширения отдельных компиляторов Причем при переносе сорсов под разные компиляторы именно на in(out)port() и возникали проблемы, поскольку не во всех компиляторах эти функции совпадают.

Цитата Pavia @ 29.07.08, 15:37

Железо такое сложное стало.

Вспомнился случай. Одно предприятие купило хитрый девайс, но в целях экономии не купили доп. плату, для его подключения к компьютеру и софт к ней, то есть съекономили порядка 50000 рубликов (точно уже не помню). После некоторых ухищрений девайс подключили к COM-порту. Но вот загвоздка, ихи ITешники попробовали написать распознание поступающих пакетов, но обломали зубки, поскольку сами пакеты имели различную структуру, длину и вообще не имели каких либо признаков начала и конца, да и приходили в самое неожиданное время, причем могли приходить даже сериями Код вышел громоздкий и временами глючил, временами пропускал пакеты, а то и серии, пока не смог распознать начало какого либо пакета. Да и читабельность у него, из-за множества IF и CASE была мягко говоря на нуле. Тогда и попросили меня, по старой дружбе. Идею использовать Си отбросил сразу же, поскольку очень быстро начинал путаться в коде, из-за огромного количества различных вариантов действий. Попытался свести логику программы в таблицу, но нужна была очень заумная таблица, с элементами разной длины и структуры, к тому же нужно было как то задавать в ней переходы, в зависимости от условий. На Си получилось нечто такое страшное, что захотелось застрелиться. А вот на асме все пошло настолько гладко, что на все ушло половина дня. Причем кода вышло - кот наплакал И вот уже несколько лет нет ни одного сбоя или рассинхронизации.
Ну нет таких языков, которые приспособлены для всего, Си в том числе. И когда начинают утверждать, что на Си писать драйвера легко и просто, то поневоле хочется поправить, что задачи бывают разные. И порой встречаются такие, которые на асме решаются быстрее и намного проще, нежели на чем либо другом. Примеров знаю массу.

Сообщение отредактировано: AndNot - 30.07.08, 10:16

Цитата AndNot @ 30.07.08, 10:12

К слову сказать это даже не средства Си, а "самопальные" расширения отдельных компиляторов Причем при переносе сорсов под разные компиляторы именно на in(out)port() и возникали проблемы, поскольку не во всех компиляторах эти функции совпадают.

В частности поэтому эти функции присутствуют в kernelAPI. Только называются иначе, чтоб не путались.

Писал на асме MMX,SSE оптимизации, ибо не видел, что бы компилятор сам такое делал.

P.O.D, тут где-то это уже было. Проще говоря, компилятор сам это делать умеет, только не каждый и только если специально разрешить. Но получается не очень. Сам посуди: для того, чтобы преобразовать простую обработку данных, записанную у тебя в программе обычными конструкциями, в стиль SIMD, требуется его для начала реверсить; какой же интеллект следует вложить в оптимизатор, чтобы он мог это делать эффективно? Обычно предлагают в подобных случаях компилятору помогать - вводят специальные типы данных и для специальных случаев intrinsic функции. У Intel Compiler, к примеру, во скока всего: dvec.h, emmintrin.h, fvec.h, ivec.h, mmintrin.h, pmmintrin.h, sse2mmx.h, tmmintrin.h, xmm_func.h, xmmintrin.h.

Пишу почти всегда только на ассемблере

Цитата AndNot @ 29.07.08, 16:54

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

Если ты имешь ввиду иенно плюсовые навороты, то пожалуй +1 Но если брать С именно как С (по синтаксису и функционалу), то ИМХО плюсы поудобней будут. Да и "современней" в любом случае.