Здравствуйте, x64, Вы писали:

R>>...драйверописцы...
x64> Не, ну вы слышали? Драйверописец подкрался незаметно Ололо
Скорее драйверописун

Здравствуйте, RedUser, Вы писали:

RU>Не, лучше так:
а еще лучше так

    for (int p=N-1; p>=N-nod; p--)
    {
        int i=p;
        int x = a[i];
        do 
        {
            i-=M;
            if (i<0)
                i+=N;
            int x1 = a[i];
            a[i] = x;
            x = x1;
        } while(i!=p);
    }

где nod это nod(N, M) (N — общая длинна)
может и не всегда верно, но идея рабочая

Здравствуйте, Au1, Вы писали:

Au1>Да вроде куда уж проще. Примерно в полэкрана кода, если не меньше. Только теории много выкладок получается.

Au1>PS: то есть это уже третье решение из имеющихся за O(n)?

Решение, которое придумал в свое время я, заключается в том, чтобы задвинуть меньшую половину на место, попарно переставив с тем, что там было. После чего в бывшей большей половине надо переставить то, что мы туда задвинули и то, что от большей половины осталось, для чего можно воспользоваться рекурсией. Но содержательно да, НОД получается.

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

Здравствуйте, Pzz, Вы писали:
Pzz>Самое простое решение заключается в том, чтобы зеркально перевернуть содержимое половин, а потом зеркально перевернуть весь массив.
да, кстати, самое понятное и простое — зеркальные перевороты. но это требует в два раза больше операций, чем предложенный мною. тот же O(n), но для больших массивов разница будет заметная.

мой алгоритм плох тем, что при большом массиве будут большие прыжки и сплошных кэш промахи, а в этом случае
Pzz>Решение, которое придумал в свое время я, заключается в том, чтобы задвинуть меньшую половину на место, попарно переставив с тем, что там было. После чего в бывшей большей половине надо переставить то, что мы туда задвинули и то, что от большей половины осталось, для чего можно воспользоваться рекурсией. Но содержательно да, НОД получается.
кэш промахов становится сильно меньше и он на больших массивах будет заметно быстрее (вот где знание ассемблера и архитектуры вообще пригодилось!

Здравствуйте, __kot2, Вы писали:

__>кэш промахов становится сильно меньше и он на больших массивах будет заметно быстрее (вот где знание ассемблера и архитектуры вообще пригодилось!

Ну чё, еще какую-нибудь задачку подкинуть?

Здравствуйте, gear nuke, Вы писали:


Я бы добавил более реальные приложения где ассемблер используется:
1. Конечно embedded system. Часть BSP пишется как правило на асемблере. Эта часть начальный start up когда происходит иницилизация процесора и часть перефирии. Рынок на embedded system довольно большой и знание асемблера будет хорошим skills.
2. Расширение BIOS, например PXE, не говоря о самом BIOS. На самом BIOS рынок конечно очень маленький, но на расширение BIOS побольше.
3. Разные экзотические проэкты где надо знание ассемблера. Я пару лет назад встречал обьявление в dice по поводу специалиста который должен быть expert in assembler. Я обратил внимание на это обьявление потому что зарплата там начиналась с цифры которая была в 1.5 раза больше чем средняя на рынке. Самое интересное что позиция была в Манхетене.

Здравствуйте, eagersh, Вы писали:

E>1. Конечно embedded system. Часть BSP пишется как правило на асемблере. Эта часть начальный start up когда происходит иницилизация процесора и часть перефирии. Рынок на embedded system довольно большой и знание асемблера будет хорошим skills.
Какого ассемблера? MIPS, ARM, SH?

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

E>2. Расширение BIOS, например PXE, не говоря о самом BIOS. На самом BIOS рынок конечно очень маленький, но на расширение BIOS побольше.
Он умирает. Дальше будет EFI, где можно писать на нормальных языках.

E>3. Разные экзотические проэкты где надо знание ассемблера. Я пару лет назад встречал обьявление в dice по поводу специалиста который должен быть expert in assembler. Я обратил внимание на это обьявление потому что зарплата там начиналась с цифры которая была в 1.5 раза больше чем средняя на рынке. Самое интересное что позиция была в Манхетене.
Очень редко такое встречается на практике.

Здравствуйте, eagersh, Вы писали:

E>Я бы добавил более реальные приложения где ассемблер используется:
E>1. Конечно embedded system. Часть BSP пишется как правило на асемблере. Эта часть начальный start up когда происходит иницилизация процесора и часть перефирии. Рынок на embedded system довольно большой и знание асемблера будет хорошим skills.

Я писал BSP для линуха на ARM'е. Ассемблера там было строк сто. Мне вполне хватило полистать полдня руководство по ARM'овскому ассемблеру и поглядеть, чего генерирует gcc для того или иного сишного кода, чтобы с этим ассемблером справиться. Разумеется, после того, как линух на этом камне взлетел, я этот ассемблер благополучно забыл. Так что писание BSP не требует глубоких знаний ассемблера, но понимание того, как в принципе работает процессор, очень помогает.

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

E>2. Расширение BIOS, например PXE, не говоря о самом BIOS. На самом BIOS рынок конечно очень маленький, но на расширение BIOS побольше.

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

Здравствуйте, Pzz, Вы писали:

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

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

Здравствуйте, gear nuke, Вы писали:

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

GN>Зачем что-то переставлять? Другими словами, каково практическое применение?

Я не помню. Но как-то понадобилось

Здравствуйте, IID, Вы писали:

IID>Нашёл, блин, чем похвастаться, гы! DDKшные примеры кишат ошибками и индусо-кодом может только чуть менее чем семплы в MSDN.
Просто любопытно, какие samples из релизов WDK (6001.18002 и 7600.16385.0)на Ваш взгляд относятся к данной категории?

Здравствуйте, Relati, Вы писали:

R>Не так давно испытала в себе желание заняться низким уровнем и сейчас радостно обнимаюсь с книжкой по Ассемблеру.
Не надо обниматься с книжкой, это все ненужная сублимация. Обниматься надо с человеком, мужчиной или женщиной — по личным предпочтениям.

"Когда я был в первом классе, ко мне подошел старшеклассник и предложил писать с ним программу на Бейсике. Я стал отказываться, но он меня заставил. С тех пор я пишу программы только на Бейсике. Иногда, когда родители уходят, мы собираемся группой по 6-8 ребят и пишем программы на Бейсике вместе.
Год назад я познакомился с девушкой, и она предложила мне писать программу на Паскале. У меня ничего не вышло: меня стошнило и потом долго болела голова.
Зовут меня Валерий Павлович, в сентябре мне исполнится 47 лет. Моя жизнь сломана.

Я обращаюсь в первую очередь к взрослым: объясните своим детям, какие опасности подстеригают их в школе, на улице, в гостях. Расскажите, что с ними могут сделать взрослые дяди с нарушенной психикой. Только не нужно слишком запугивать — дети очень впечатлительны, у них могут сложиться комплексы, которые будут потом мешать в их взрослой жизни."

Здравствуйте, Relati, Вы писали:

R>Не так давно испытала в себе желание заняться низким уровнем и сейчас радостно обнимаюсь с книжкой по Ассемблеру.
R>Хотелось бы узнать, на сколько сложно не сильно опытному программисту найти работу в области низкоуровневого? И какие соопутствующие темы имеет смысл подтянуть? Имею С/С++ ный опыт 2 года.
R>Из просмотренных предложений о работе нашла лишь одну вакансию явно предполагающую джуниора, получается что — нужны исколючительно гуру, а для новичков места нет?

R>В общем, как вы думаете имеет смысл соваться в эту область?

почтиай соседнюю ветку "рабоыт нет или только кажется" и высказывания господина мъщ..... (дальше ник не помню, множество рандомных букв, полагаю это что-то значит в машинных кодах) и поймешь зачем нужен. зарплата в 100+ К покажется мелочью....

а так, реально.... не нужен он никому, разве что для себя интересно.

Здравствуйте, Relati, Вы писали:

после 16 лет писания на разных ассемблерах успешно работаю на С/С++/С#. Реально понадобилась и была написана функция поиска поддампа в дампе, аналогичная strstr(..) из 10 строк и кусочки зашиты программ от взлома. Под линухом ассемблер совсем другой, так что код получился непереносимым. По поводу скорострельности — компилятор от МС часто использует регистры для работы с пл.точкой, так что код получается эффективнее, чем простой ручной ассемблер. Для драйверов — это под 98 нужен был переходной код на асме. Да и сам асм без глубокого знания архитектуры CPU и всех регистров (для 486, Р1, AMD их список отличается, старшие модели уже не смотрел) — никому не нужный. Для однокристалок коротенькие коды фильтров — на асме.

В общем — сейчас это неперспективная область. Разработчик на асме по другому мыслит и это часто мешает — стараюсь побыстрее забыть все асмы (ну кроме AVR ).

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, eagersh, Вы писали:

E>>1. Конечно embedded system. Часть BSP пишется как правило на асемблере. Эта часть начальный start up когда происходит иницилизация процесора и часть перефирии. Рынок на embedded system довольно большой и знание асемблера будет хорошим skills.
C>Какого ассемблера? MIPS, ARM, SH?
Я писал пару назад для PowerPC.

C>В embedded-разработке сейчас ассемблер нужен лишь немного чаще, чем в остальных ситуациях.

E>>2. Расширение BIOS, например PXE, не говоря о самом BIOS. На самом BIOS рынок конечно очень маленький, но на расширение BIOS побольше.
C>Он умирает. Дальше будет EFI, где можно писать на нормальных языках.
Я писал про текущий рынок.

E>>3. Разные экзотические проэкты где надо знание ассемблера. Я пару лет назад встречал обьявление в dice по поводу специалиста который должен быть expert in assembler. Я обратил внимание на это обьявление потому что зарплата там начиналась с цифры которая была в 1.5 раза больше чем средняя на рынке. Самое интересное что позиция была в Манхетене.
C>Очень редко такое встречается на практике.
Но бывает что очень надо такого уровня специалист.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, eagersh, Вы писали:

E>>Я бы добавил более реальные приложения где ассемблер используется:
E>>1. Конечно embedded system. Часть BSP пишется как правило на асемблере. Эта часть начальный start up когда происходит иницилизация процесора и часть перефирии. Рынок на embedded system довольно большой и знание асемблера будет хорошим skills.

Pzz>Я писал BSP для линуха на ARM'е. Ассемблера там было строк сто. Мне вполне хватило полистать полдня руководство по ARM'овскому ассемблеру и поглядеть, чего генерирует gcc для того или иного сишного кода, чтобы с этим ассемблером справиться. Разумеется, после того, как линух на этом камне взлетел, я этот ассемблер благополучно забыл. Так что писание BSP не требует глубоких знаний ассемблера, но понимание того, как в принципе работает процессор, очень помогает.

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

E>>2. Расширение BIOS, например PXE, не говоря о самом BIOS. На самом BIOS рынок конечно очень маленький, но на расширение BIOS побольше.

Pzz>А там-то чего на ассемблере писать? 100 строк стартапного кода, который позволяет дальше писать на Си?
У нас в проэкте написан IP/ARP/UDP stack. Было сильное ограничение по памяти.

Здравствуйте, eagersh, Вы писали:

E>>>1. Конечно embedded system. Часть BSP пишется как правило на асемблере. Эта часть начальный start up когда происходит иницилизация процесора и часть перефирии. Рынок на embedded system довольно большой и знание асемблера будет хорошим skills.
C>>Какого ассемблера? MIPS, ARM, SH?
E>Я писал пару назад для PowerPC.
А я под MIPS в режиме little endian. Вот в этом и проблема.

E>>>2. Расширение BIOS, например PXE, не говоря о самом BIOS. На самом BIOS рынок конечно очень маленький, но на расширение BIOS побольше.
C>>Он умирает. Дальше будет EFI, где можно писать на нормальных языках.
E>Я писал про текущий рынок.
Ну вот и нет особого смысла туда соваться — перспектив мало.

C>>Очень редко такое встречается на практике.
E>Но бывает что очень надо такого уровня специалист.
Таких специалистов не зря мало.

Здравствуйте, eagersh, Вы писали:

Pzz>>А там-то чего на ассемблере писать? 100 строк стартапного кода, который позволяет дальше писать на Си?
E>У нас в проэкте написан IP/ARP/UDP stack. Было сильное ограничение по памяти.

Насколько сильное?

В упомянутом мной AVR'е было лишь 4К памяти для программы и 128 байт для данных. Причем когда я начинал, я думал, там 256 байт, а о том, что их в два раза меньше, узнал, когда стек неожиданно для меня наехал на мои переменные

Здравствуйте, egaron, Вы писали:

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

мыщъх. в машинных кодах ничего не значит. щ и ш я путаю, потому как не отличаю их на слух, а запомнить написание всех слов без ворда — памяти не хватает. поэтому стал писать мыЩь чтобы не ломать голову есть там палка или нет. потом добавил палку и к Ь, так пояивлся мыщъ, ну а х это сокращение от х. в смысле хвост. и он у меня есть.

> и поймешь зачем нужен. зарплата в 100+ К покажется мелочью....
эээ... а при чем тут ассемблер? тут скорее реверсинг. и даже реверсинг тут третий лишний. на ассемблере мне уже давно программировать не приходилось, и даже последние антиотладочные приемы разрабатывались на полностью переносимом си с использованием только стандартных библиотек, и потому работающих как под вынем (32 и 64 бита) так и под никсами, что экономит фирме кучу бабла по сравнению с асмом, т.к. код не нужно переписывать каждый раз заново.

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

Здравствуйте, мыщъх, Вы писали:

М> у асма есть своя ниша из которой его никто не вытеснит и которая весьма востребована.

Угу. Для вещей вроде "__asm__ __volatile__ ("rep; nop" : : );" самое оно