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

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

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

R>В общем, как вы думаете имеет смысл соваться в эту область?
Можно попробовать вирусного аналитика в Dr. Web. Там как раз и ассемблер нужен, и опыт в C\C++ пригодится.
Подтянуть нужно внутреннее устройство ОС, формат исполняемых файлов.

Никуда не нужен.
Там, где требуется ассемблер — низкоуровневое\системное программирование, реверсинг — ожидают крутых спецов в этих областях (реверсинг, системное программирование), а ассемблер там — это как само собой разумеющееся бесплатное приложение к этим скиллам.

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

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

В вирусные аналитики можно...

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

_U_>Никуда не нужен.
_U_>Там, где требуется ассемблер — низкоуровневое\системное программирование, реверсинг — ожидают крутых спецов в этих областях (реверсинг, системное программирование), а ассемблер там — это как само собой разумеющееся бесплатное приложение к этим скиллам.

Подтверждаете мои опасения(

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

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

R>>В общем, как вы думаете имеет смысл соваться в эту область?
T>Можно попробовать вирусного аналитика в Dr. Web. Там как раз и ассемблер нужен, и опыт в C\C++ пригодится.
T>Подтянуть нужно внутреннее устройство ОС, формат исполняемых файлов.

Да, и в drweb и касперского смотрела вакансии ))) на это пока ориентируюсь.
Но! Меня немного напрягает, что например, потратив какое-то время подтягивая нужные темы я могу пролететь мимо желаемой вакансии(по самым разным причинам от — "мы закрываем набор" до "просто не день Бэкхема") и получится, что никакой альтернативы нет.

Еще вроде нужны драйверописцы, но тут похоже нужно будет немного другие темы подтягивать в поддержку.

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

A>В вирусные аналитики можно...

На это пока и ориентируюсь... ) Но вирусных аналитиков надо едва-едва, к тому же нифига не ясно насколько гуру им нужны или готовы брать и обучать. И куда можно будет податься, если не сростется по какой-то причине.
Т.е. расширить кругозор в эту область может и полезно будет. Но не продвинет к цели — поиску интересной работы.

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

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

Программисту (т.е., человеку, который пишет программы) надо знать ассемблер в таком объеме, чтобы понимать на концептуальном уровне, во что его программа превращается после того, как над ней поработал компилятор. И тут важнее не исчерпывающее знание системы команд, а понимание, опять же, на концептуальном уровне, как работает процессор. К примеру, важнее понимать, что такое memory barrier и синхронизация кешей, чем знать, как это выразить на ассемблере собственными руками.

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

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

В общем, уметь читать ассемблер невредно, но не обязательно уметь это делать со скоростью процессора

Бывают еще всякие виды деятельности, которые требуют лучшего понимания ассемблера, но при этом не являются, собственно, программированием. Например, reverse engineering или анализ вирусов. Там умение читать ассемблер может оказаться значительно полезнее.

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

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

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

R>На это пока и ориентируюсь... ) Но вирусных аналитиков надо едва-едва, к тому же нифига не ясно насколько гуру им нужны или готовы брать и обучать. И куда можно будет податься, если не сростется по какой-то причине.

Как вам кажется, после какого количества проанализированных вирусов вас начнет от них тошнить? Я бы больше трех точно не выдержал

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

Pzz>Как вам кажется, после какого количества проанализированных вирусов вас начнет от них тошнить? Я бы больше трех точно не выдержал

Вы разрушаете мою веру в светлую работу рыцарей, защищающих простых пользователей от злобных вирусов, так и норовящих угробить систему

Думаете от этого может тошнить больше, чем от рутинного баг-фикса?

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

Pzz>>Как вам кажется, после какого количества проанализированных вирусов вас начнет от них тошнить? Я бы больше трех точно не выдержал

R>Вы разрушаете мою веру в светлую работу рыцарей, защищающих простых пользователей от злобных вирусов, так и норовящих угробить систему

Это не лыцари. Это скорее ассенизаторы

R>Думаете от этого может тошнить больше, чем от рутинного баг-фикса?

Ну, я думаю, кроме рутиного баг-фикса есть много другой работы.

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

Ну в том, что это полезно — я даже не сомневаюсь ))) Очень радуюсь, когда светлеют некоторые моменты, которые при отладке ранее просто проходили мимо.

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

Вот с такой ситуацией как раз сталкивалась ) Только библиотеки не системные, а закрытые индуские, что только усугубляет ситуацию...

Pzz>В обшем и целом, умение программировать универсально
Умение программировать, конечно универсально в целом, а вот когда доходит до конкретики — неплохо бы знать пачку библиотек и поюзать в работе конкретный язык пару лет

Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )

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

R>>Думаете от этого может тошнить больше, чем от рутинного баг-фикса?

Pzz>Ну, я думаю, кроме рутиного баг-фикса есть много другой работы.

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

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

Ну в том, что это полезно — я даже не сомневаюсь ))) Очень радуюсь, когда светлеют некоторые моменты, которые при отладке ранее просто проходили мимо.

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

Вот с такой ситуацией как раз сталкивалась ) Только библиотеки не системные, а закрытые индуские, что только усугубляет ситуацию...

Pzz>В обшем и целом, умение программировать универсально
Умение программировать, конечно универсально. В целом. А вот когда доходит до конкретики — неплохо бы знать пачку библиотек и поюзать в работе конкретный язык пару лет

Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )

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

Pzz>>Ну, я думаю, кроме рутиного баг-фикса есть много другой работы.

R>Значит я возможно, где-то не там смотрю... потому что по моему опыту — рутинного баг-фиксинга как раз много( по крайне мере в больших компаниях.

Ну, начинающему трудно найти работу...

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

Ищите, такие места есть. Многие большие компании, типа Интела и Гугля, сознательно набирают неопытных но талантливых студентов "на вырост" — при наличии ресурсов, в т.ч. временнЫх, это более надежный способ получить квалифицированного специалиста, чем попытаться найти готового. Поработаете годика два за умеренную зарплату, но зато уму-разуму научитесь.

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

Pzz>>В обшем и целом, умение программировать универсально
R>Умение программировать, конечно универсально. В целом. А вот когда доходит до конкретики — неплохо бы знать пачку библиотек и поюзать в работе конкретный язык пару лет

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

Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,

Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

R>Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )

Учитесь программировать — т.е., писать новый код. Совершенно не важно, в какой области. Важно, чтобы сложность кода росла по мере обучения (сложность не в смысле вычурность, а в смысле сложность и объем задач, которые вы способны решать).

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

Проблема в том, что "низкий уровень" это далеко не только асм. А обниматься лучше с любимым мужем и ребёнком, правда.

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

Очень сложно, — системщики-джуниоры, как правило, никому не нужны. Если только в подмастерья к кому, но пойди найди ещё желающего тратить на это своё время.

R>И какие соопутствующие темы имеет смысл подтянуть? Имею С/С++ ный опыт 2 года.

Сами по себе C и асм ничего не дают, если только ты не собираешься компиляторы писать или в разного рода malware ковыряться. Определись со своей специализацией, потому что ты не сможешь быть "просто низкоуровневым разработчиком". Это обусловлено тем, что каждая из специализаций сама по себе достаточно объёмна: например, человек всю жизнь писавший драйвера для чипсетов nVidia не сможет с разбегу "въехать" в сетевой стек Windows, ему в любом случае понадобиться какое-то время. Равно как и человек, всю жизнь писавший компиляторы, вряд ли осилит написание драйвера-фильтра файловой системы. Т.е. определись сначала с теми задачами, которые привлекают тебя больше всего, и развивай в себе умение решать их и только их, это более эффективная стратегия, чем попытки освоить много и сразу.

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

Если ты не понимаешь чётко, что делаешь и зачем тебе это, если не чувствуешь, что "лежит душа" к этому, — то однозначно не надо. Как ни крути, всё же это весьма объёмная область и нужно быть готовым к тому, что можешь не стать здесь "гуру" даже и через 5 лет.

R>...драйверописцы...

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

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

R>Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )

Pzz сказал все абсолютно верно.

Знание ассемблера само по себе вряд ли принесет тебе работу и много денег. Точнее, такие работы, где кроме ассемблера ничего не нужно, существуют, но их мало, и ориентироваться на них не стоит.

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

Важность ассемблера, как дополнительного умения, зависит от твоей основной работы. Знание ассемблера более важно, если ты программируешь в ядре или на Win32 API и менее важно, если ты пишешь бизнес логику на джаве.

Стоит ли заниматься ассемблером вообще?

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

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

R>Подтверждаете мои опасения(
Немного из жизни.

Так сложилось, что ассемблер был моим практически первым языком программирования. На практике несколько раз приходилось подключать нестандартный принтер к компу, делал это на ассемблере (это было во времена DOS). На высокоуровневые языки и высокоуровневые вещи смотрел свысока — это типа не работа для настоящих мужчин, круче меня только скалы, я нахожусь на самом низком уровне и могу все. Кроме ассемблера уважал Си, Си++, но меня крайне беспокоил огромный размер исполняемого файла после компиляции . Соответственно хотел становиться именно системным программистом. Судьба сложилась так, что этому не удалось сбыться — каждый раз, когда я менял работу, меня брали на совершенно новый язык. И вот на практике оказалось, что в большинстве случаев важно не знание низкого уровня (под низцим уровнем я часто подразумеваю сам язык программирования), а именно умение программировать, умение так спроектировать, чтобы изменяющиеся требования реализовывать с минимальными усилиями. И важным скилом оказывается умение эти трубования предугадать.
Ну и далее, делят тут народ смотрю вещи так же, как делил раньше я. Кто занимается системными вещами — тот презирает прикладной уровень. И наоборот. А на деле то именно при разработке особой разницы то нет. API различается, в одном случае это порты контроллера, и надо в нужной последовательности к ним обратиться чтобы достичь результата, во втором случае это набор функций ядра ОС, а в ьретьем случае под API подразумевается набор сущностей предметной области, выраженное через классы и методы, которые тоже в нужный момент надо дернуть в определенной последовательности. Приемы программирования те же, разница в том, что у системщиков предметная область меняется незначительно со временем, за счет чего они могут позволить себе ее знать гораздо лучше.
По поводу ассемблера. Знать полезно всегда. Чем больше языков и подходов знаешь, тем лучший ты программист, тем лучше ты потенциально сможешь программировать на любом языке, хоть и на собеседованиях эти взгляды не разделяют, а считают основным знание своего языка. Тот, кто знает ассемблер, при необходимости мысленно всегда сможет спуститься на уровень процессора и мысленно представить, во что превратится его код. При этом вполне будет уметь выслить высокоуровневыми абстракциями. Тот, кто о низком уровне не знает, будет ограничен исключительно своим языком. Но, так как он не способен спуститься ниже уровня языка, он может не понимать почему язык спроектирован именно так, а не иначе. Он вынужден практически вызубривать некоторые особенности языка, вместо того, чтобы понять принципы. Знание принципов освобождает от необходимости запоминания мелких деталей.

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



Pzz>Кроме того, большая часть низкоуровневой работы, навроде писания драйверов, интересна только первые три раза, а потом, как руку набьете, обнаружите, что это довольно скучная рутина.
Вы имеете ввиду написание драйверов на Windows? Если да, то вы меня повеселили. Это можно сказать более или мение для одного типа драйвера но если переходишь на другой тип драйвера то приходится многое изучать сначала. И изучать в основном по примерам с WDK которые плохо документированны и часто buggy.И конечно собирать по крохам информацию с разных форумах, которых к сожелению не так много. Не говоря о том что програмировать для Windows kernel просто тяжело потому что Microsoft все пытается сделать чтобы ограничить свободу в design and development. Ну а programming for file system и filter file system и остальными типами Windows driverы это полностью два различных мира. На OSR даже существуют различный форум для file system drivers.
Ну а если надо сделать какое нибудь не стандартное решение, которое выходит за понимание Microsoft что можно делать на Windows на системном уровне, то начинается такое веселье и такая "рутина" что мозги плавяться.

Pzz>Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,

Pzz>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

static void interchange_equal_blocks(int *b1, int *b2, unsigned int len)
{
    int tmp, *p1 = b1, *p2 = b2;

    for (; p1 < b1 + len; ++p1, ++p2)
    {
        tmp = *p1;
        *p1 = *p2;
        *p2 = tmp;
    }
}

void interchange_blocks(int *b1, unsigned int b1_len, int *b2, unsigned int b2_len)
{
    if (b1_len < b2_len)
    {
        interchange_equal_blocks(b1, b2, b1_len);
        interchange_blocks(b2, b1_len, b2 + b1_len, b2_len - b1_len);
    }
    else if (b1_len > b2_len)
    {
        interchange_equal_blocks(b1, b2, b2_len);
        interchange_blocks(b1 + b2_len, b1_len - b2_len, b2, b2_len);
    }
    else interchange_equal_blocks(b1, b2, b1_len);
}

Не, лучше так:

void interchange_blocks(int *ptr, unsigned int b1_len, unsigned int b2_len)
{
    if (b1_len < b2_len)
    {
        interchange_equal_blocks(ptr, ptr + b1_len, b1_len);
        interchange_blocks(ptr + b1_len, b1_len, b2_len - b1_len);
    }
    else if (b1_len > b2_len)
    {
        interchange_equal_blocks(ptr, ptr + b1_len, b2_len);
        interchange_blocks(ptr + b2_len, b1_len - b2_len, b2_len);
    }
    else interchange_equal_blocks(ptr, ptr + b1_len, b1_len);
}

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

Pzz>Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,

Pzz>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

You make my day(c) Этой задачкой ))) Есть школьный вариант... завести второй массив )
Но вообще, как я поняла, point в том, чтобы сразу ставить элемент на нужное место... ) Пока в процессе...( но в целом грустно... давно я таки в своем баг-фиксе с алгоритмами не сталкивалась(

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

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

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

x64>Если ты не понимаешь чётко, что делаешь и зачем тебе это, если не чувствуешь, что "лежит душа" к этому, — то однозначно не надо. Как ни крути, всё же это весьма объёмная область и нужно быть готовым к тому, что можешь не стать здесь "гуру" даже и через 5 лет.

Если бы мне это не было интересно — я бы и не задумалась даже. Но интересно что в области творится... чужие мнения, а не через мои "розовые очки" ))))

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

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

Pzz>Ищите, такие места есть. Многие большие компании, типа Интела и Гугля, сознательно набирают неопытных но талантливых студентов "на вырост" — при наличии ресурсов, в т.ч. временнЫх, это более надежный способ получить квалифицированного специалиста, чем попытаться найти готового. Поработаете годика два за умеренную зарплату, но зато уму-разуму научитесь.

Дык как бэ уже и не студент((( Но все равно спасибо! буду стараться найти что-то интересное...

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

R>You make my day(c) Этой задачкой ))) Есть школьный вариант... завести второй массив )

Ну еще одно наивное решение заключается в том, чтобы крутить массив по кругу, пока он не станет в правильное положение. А с конечной дополнительной памятью и за время O(n) слабо решить?

R>Но вообще, как я поняла, point в том, чтобы сразу ставить элемент на нужное место... ) Пока в процессе...( но в целом грустно... давно я таки в своем баг-фиксе с алгоритмами не сталкивалась(

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

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

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

Типов виндузовых драйверов существует конечное количество.

E>И изучать в основном по примерам с WDK которые плохо документированны и часто buggy.И конечно собирать по крохам информацию с разных форумах, которых к сожелению не так много. Не говоря о том что програмировать для Windows kernel просто тяжело потому что Microsoft все пытается сделать чтобы ограничить свободу в design and development. Ну а programming for file system и filter file system и остальными типами Windows driverы это полностью два различных мира. На OSR даже существуют различный форум для file system drivers.

Если бы я не написал ни одного вендового драйвера, возможно ваши слова произвели бы на меня впечатление

Документация, да, так себе. Документации о том, как писать линуксные драйвера, вообще не существует в природе. Однако писать драйвера для линуха не слишком сложно.

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

Микрософтовское понимание мира, при всех его недостатках, является Тьюринг-полным. Поэтому всё, что требуется, можно сделать, не выходя за его пределы

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

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

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

Pzz>Типов виндузовых драйверов существует конечное количество.

И вы писали все типы драйверов?
Я ежедневно мониторю главные форумы по Windows drivers. В основном конечно OSR так как там много крутится людей с Microsoft. Вернее они принимают часто участие в дискусиях. А принимают потому что очень часто даже MVP не могут ответить на некоторые вопросы.Только люди с Microsoft, которые знают определенные и специфичные детали, могут ответить.


E>>И изучать в основном по примерам с WDK которые плохо документированны и часто buggy.И конечно собирать по крохам информацию с разных форумах, которых к сожелению не так много. Не говоря о том что програмировать для Windows kernel просто тяжело потому что Microsoft все пытается сделать чтобы ограничить свободу в design and development. Ну а programming for file system и filter file system и остальными типами Windows driverы это полностью два различных мира. На OSR даже существуют различный форум для file system drivers.

Pzz>Если бы я не написал ни одного вендового драйвера, возможно ваши слова произвели бы на меня впечатление

Я как то раз был на семинаре OSR "File system drivers" который читает Tony Manson. Это довольно крутой специалист в своей области так как он часто консультирует Microsoft.Он расказывал что он несколько лет подряд читал этот курс в Европе и эти несколько лет на этом курсе были люди с одной голандской фирмы. Эта фирма планировала сделать какой то проэкт связанный с файл систем. Консультантов из US они не хотели брать, наверное считали что дорого. Пытались сделать все своими силами за меньшую европейскую зарплату. Рассказ он закончил тем что этот проэкт небыл закончен по нехватке квалификации. Вы случайно не в Голландии живете?

Pzz>Документация, да, так себе. Документации о том, как писать линуксные драйвера, вообще не существует в природе. Однако писать драйвера для линуха не слишком сложно.
Потому что source code. А это все.
E>>Ну а если надо сделать какое нибудь не стандартное решение, которое выходит за понимание Microsoft что можно делать на Windows на системном уровне, то начинается такое веселье и такая "рутина" что мозги плавяться.

Pzz>Микрософтовское понимание мира, при всех его недостатках, является Тьюринг-полным. Поэтому всё, что требуется, можно сделать, не выходя за его пределы
Вопрос только за какое время и какими силами

Pzz> А с конечной дополнительной памятью и за время O(n) слабо решить?

Точно O(n), а не O(nLogn) ?

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

Pzz>> А с конечной дополнительной памятью и за время O(n) слабо решить?

M>Точно O(n), а не O(nLogn) ?

Про уже приведенное здесь решение не возьмусь утверждать, но существует решение, которое очевидно O(n)

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

Pzz>>Типов виндузовых драйверов существует конечное количество.

E>И вы писали все типы драйверов?

Нет конечно. А что, неужели их все же существует бесконечное количество?

E>Я ежедневно мониторю главные форумы по Windows drivers. В основном конечно OSR так как там много крутится людей с Microsoft. Вернее они принимают часто участие в дискусиях. А принимают потому что очень часто даже MVP не могут ответить на некоторые вопросы.Только люди с Microsoft, которые знают определенные и специфичные детали, могут ответить.

Ну, если бы бумажка MVP автоматически делала человека волшебником...

Pzz>>Если бы я не написал ни одного вендового драйвера, возможно ваши слова произвели бы на меня впечатление

E>Я как то раз был на семинаре OSR "File system drivers" который читает Tony Manson. Это довольно крутой специалист в своей области так как он часто консультирует Microsoft.Он расказывал что он несколько лет подряд читал этот курс в Европе и эти несколько лет на этом курсе были люди с одной голандской фирмы. Эта фирма планировала сделать какой то проэкт связанный с файл систем. Консультантов из US они не хотели брать, наверное считали что дорого. Пытались сделать все своими силами за меньшую европейскую зарплату. Рассказ он закончил тем что этот проэкт небыл закончен по нехватке квалификации. Вы случайно не в Голландии живете?

Нет, не в Голландии. Мне приходилось как-то иметь дело с крутыми специалистами из US. Настолько крутыми, что один из написанных ими драйверов входит в состав виндового DDK в качестве примера. Я написал драйвер для некоторой железяки под линух, а у них заказали "профессионально написанный" драйвер под венду, а мой выдали в качестве документации. В общем, эти бедолаги решили спортировать мой, вместо того, чтобы свой написать, и этот проект так бы и закончился по нехватке ихней квалификации, если бы я сдуру не взялся помочь им удержать ихний драйвер на плаву. Это был мой первый вендовый драйвер, жалко, что не последний

Pzz>>Микрософтовское понимание мира, при всех его недостатках, является Тьюринг-полным. Поэтому всё, что требуется, можно сделать, не выходя за его пределы
E>Вопрос только за какое время и какими силами

Надо иметь очень серьезные причины, чтобы плыть, программируя под венду, против течения — венда будет очень сопротивляться. К сожалению, большинство людей пытается плыть против течения не потому, что это им действительно надо, а потому, что им ошибочно кажется, что сделав все не как велено, они в чём-то упростят себе жизнь.

x64>Драйверописец

Сразу вспомнил одного персонажа .

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

Pzz>Ну еще одно наивное решение заключается в том, чтобы крутить массив по кругу, пока он не станет в правильное положение. А с конечной дополнительной памятью и за время O(n) слабо решить?

И вот кто-то здесь думает, что я прямо и скажу "слабо"? Пока думаю... )

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

Почему не получится? О_о у меня получилось... ) только работает не для всех случаев Вот поэтому пока и в процессе

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

Pzz> Мне приходилось как-то иметь дело с крутыми специалистами из US. Настолько крутыми, что один из написанных ими драйверов входит в состав виндового DDK в качестве примера.

Аааааааааа

Нашёл, блин, чем похвастаться, гы! DDKшные примеры кишат ошибками и индусо-кодом может только чуть менее чем семплы в MSDN.

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

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

Имеет смысл заниматься своим делом, а какое оно — вряд ли кто то лучше тебя знает. В 93м один умник мне рассказал, что ассемблер нигде не нужен, и я поверил

Где он точно не нужен — это разработка драйверов. И вообще любой development на ассемблере экономически не выгоден уже несколько лет, с тех пор как появилось 64 бита для default platform. Знаю всего 2-3 случая когда недостаточно С.

Где нужно знание ассемблера:

1. Более глубокое понимание С (как диалекта ассемблера ). ИМХО полезно почитать "Дизайн и эволюция" Страуструпа и "Алгоритмические трюки" Генри Уоррена. Востребовано во всех сферах применения языка. Может значительно упростить отладку. Вы писали, что занимаетсь отладкой — можно развиваться в этом направлении, по-моему хороших специалистов меньше, чем нужно, а у женщин потенциально должно лучше получаться.

2. Reverse code engineering. Это нужно всегда, как знания COBOL сейчас Думаю, что пик спроса будет после массового перехода на упровляемые ОС, так что время учиться есть но нужно еще понимать, что это дело всё лучше автоматизируется.
Номинально RCE — создание понятных человеку исходников по бинарному файлу без его запуска, а junior пишет код по готовым спецификациям, коих здесь нет... Возможно это соответствует вирусному аналитику, который изучает сэмплы как чёрный ящик, логируя побочные эффекты API мониторами (созданными старшими коллегами). Детально изучается небольшой % малвари, но это может быть очень ресурсоёмким и сложным процессом.
Учиться можно так же в отладчике, дебажа свой софт без исходного кода. Рости можно до уровня архитектора, чем и является RE в общем.

3. Защита от предыдущего пункта (а в силу сходных методов и автоматизация RCE). Самое перспективное и сложное направление. Трансляторы (дизассемблеры), виртуальные машины, изоморфы, DRM, watermarking, MITM атаки, NP-полные проблемы... ассемблер в этом списке идет маловажной деталью ближе к концу, после интуиции Тема очень многогранна, не знаю, существуют ли всеобъемлющие гуру. Видел вакансии непосредственно у разработчиков протекторов, можно поискать работу и в смежных областях.

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

Имеет смысл подтянуть ассемблер для всяких-разных архитектур, например, ARM, и податься в embedded. Там знание ассемблера довольно часто
нужно, правда тоже не как основной скилл.

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

Pzz>Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,

Pzz>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

Что-то мне подсказывает, что перестановка распадается на X = НОД(N,M) циклов одинаковой длины с примерно регулярной структурой, т.е. что числа a1, a2, ..., aX принадлежат разным циклам. Доказывать этот факт лень, но если это получится доказать, то решение должно быть таким:

0. Выводим формулу для индекса новой позиции по старой позиции. Не сложно.
1. Запоминаем стартовый индекс очередного цикла (изначально, 1).
2. Переставляем число, на которое смотрим на свое место по формуле из (0), а число с нового места запоминаем где-то.
3. Повторяеем 2, пока не придем в начало цикла из (1).
4. Если еще не все числа переставлены (считаем количесво операций сделаных в п.2), то увеличиваем стартовый индекс на 1 и переходим к (1).

Ну, конечно, стоит отсечь сразу всякие вырожденные случаи типа M<=0, N<=0, M>=N превратить в (M mod N), N.

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

Pzz>>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

Au1>Что-то мне подсказывает, что перестановка распадается на X = НОД(N,M) циклов одинаковой длины с примерно регулярной структурой, т.е. что числа a1, a2, ..., aX принадлежат разным циклам. Доказывать этот факт лень, но если это получится доказать, то решение должно быть таким:

Есть решение гораздо проще, и еще одно решение, совсем тривиальное.

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


Pzz>Есть решение гораздо проще, и еще одно решение, совсем тривиальное.

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

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

Здравствуйте, 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" : : );" самое оно

R>Еще вроде нужны драйверописцы, но тут похоже нужно будет немного другие темы подтягивать в поддержку.

Ассемблер в большинстве драйверов практически не применяется.

E>Вы имеете ввиду написание драйверов на Windows? Если да, то вы меня повеселили. Это можно сказать более или мение для одного типа драйвера но если переходишь на другой тип драйвера то приходится многое изучать сначала. <...>
E>Ну а если надо сделать какое нибудь не стандартное решение, которое выходит за понимание Microsoft что можно делать на Windows на системном уровне, то начинается такое веселье и такая "рутина" что мозги плавяться.

Позвольте с вами не согласиться. Да, я уже давно шашек в руки не брал, но по ситуации 99-2004 годов драйверы под винду (а тогда с ними было всё веселее, ибо существовала не только WDM, но и legacy *.vxd — вот уж где помойка-то была натуральная) писались без особых сложностей. И, реально, набив руку на сетевом NDIS-хукинг драйвере, без проблем получилось сделать и intermediate, и даже кое-какие допилки к miniport для SCSI. Честно сказать, слабо верится, что с тех пор что-то значительно изменилось.

IID>Нашёл, блин, чем похвастаться, гы! DDKшные примеры кишат ошибками и индусо-кодом может только чуть менее чем семплы в MSDN.

Подтверждаю. Впрочем, на то они и примеры, чтобы над ними подумать, и НЕ делать, как в них написано.

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

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

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

U>Угу. Для вещей вроде "__asm__ __volatile__ ("rep; nop" : : );" самое оно
знать асм это одно, программировать на нем это другое. а без знания асма очень мало что можно вообще сделать. типичная стуация: релиз падает с воплем о критической ошибке, отладочная версия работает нормально, попытка добавки отладочной печати так же магическим образом нейтрализует ошибку. и что мы без асма делать будем? да и потом (и об этом уже говорили выше) не зная как все это устроено на низком уровне и во что превращается откомпилированный код -- сложно писать по уму и от души. вот от такого незнания мы до сих пор имеем кучу переменных размером в байт от которых тормоза жуткие в отличии от инта. а всего-то стоило загляднуть в код, сгенерированный компилятором.

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

другой вопрос, что зная только ассемблер x86 работу с ним не найти

Ассемблер используют(мне приходилось) для ускорения существующего кода, например.
Отладка на asm очень трудоемка поэтому его применение ограничено по сравнению с C++ , например, и другими языками высокого уровня.
Вообще стоит отталкиваться не от языка (это всего лишь средство), а от того какие задачи вам интересно решать.
Ваша формулировака "заняться низким уровнем", как мне кажется, говорит о том , что вы точно не представляете себе, что хотите.
Вообще, заморачиватся на ассемблере я бы не советовал.

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

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

RU>

RU>void interchange_blocks(int *ptr, unsigned int b1_len, unsigned int b2_len)
RU>{
RU>    if (b1_len < b2_len)
RU>    {
RU>        interchange_equal_blocks(ptr, ptr + b1_len, b1_len);
RU>        interchange_blocks(ptr + b1_len, b1_len, b2_len - b1_len);
RU>    }
RU>    else if (b1_len > b2_len)
RU>    {
RU>        interchange_equal_blocks(ptr, ptr + b1_len, b2_len);
RU>        interchange_blocks(ptr + b2_len, b1_len - b2_len, b2_len);
RU>    }
RU>    else interchange_equal_blocks(ptr, ptr + b1_len, b1_len);
RU>}
RU>

Тупо циклический сдвиг сделать, ты что нагородил-то!

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

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

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

Pzz>>Ищите, такие места есть. Многие большие компании, типа Интела и Гугля, сознательно набирают неопытных но талантливых студентов "на вырост" — при наличии ресурсов, в т.ч. временнЫх, это более надежный способ получить квалифицированного специалиста, чем попытаться найти готового. Поработаете годика два за умеренную зарплату, но зато уму-разуму научитесь.

R>Дык как бэ уже и не студент((( Но все равно спасибо! буду стараться найти что-то интересное...

В Питере есть контора, которая копается в WinCE. Да-да, именно копается в коде Micrsoft. Допиливают CE, под свои нужды собирают, считай, ось делают. Уровень системный, как сама понимаешь. Приходится на ARM-асме даже иногда пописать. А так — в основном си. Рутины кстати, нет. Ищи и найдешь!

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

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

R>>You make my day(c) Этой задачкой ))) Есть школьный вариант... завести второй массив )

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

Циклический сдвиг на n можно сделать так же быстро как и циклический сдвиг на 1. За O(n).

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

D>Циклический сдвиг на n можно сделать так же быстро как и циклический сдвиг на 1. За O(n).

Ну да, собственно, эта задача и заключается в циклическом сдвиге на n. Т.е., вы свели задачу к самой себе

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

HN>Ассемблер используют(мне приходилось) для ускорения существующего кода, например.
интересно, почему когда спорят о необходимости знания ассемблера то в основном говорят за написание кода на нем, когда на практике гораздо больше приходитя сталкиваться с чтениием. типа реверсинг, отладка краш дампов и т.д.

HN>Отладка на asm очень трудоемка
интересно. и в чем же ее трудоемкость. отладочную печать уже отменили? учитесь отлаживать и будет вам щастье. сложность отладки больше зависит от алгоритма чем от языка.

HN>поэтому его применение ограничено по сравнению с C++ ,
??? только из-за "сложности" отладки? не говорите ерунды. тем более сравнивая с плюсами, у которых совсем другой уровень абстракции и плюсов по сравнению с ассемблером намного больше.

HN>Вообще, заморачиватся на ассемблере я бы не советовал.
ну ассемблер это пропуск на системный уровень. без него там делать нечего.

Пригодится. Иногда даже там где, казалось бы, машинного кода и за 100 верст быть не должно.

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

HN>>Отладка на asm очень трудоемка
М>интересно. и в чем же ее трудоемкость.

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

М> отладочную печать уже отменили?

Вот еще одина причина повышенной трудоёмкости — это всё добавляется руками. Фреймворков для автоматизации тестирования нет.

М> учитесь отлаживать и будет вам щастье. сложность отладки больше зависит от алгоритма чем от языка.

Ну да. Вот нашел ты ошибку в сложном алгоритме, и надо переписать часть кода. Теперь оцени требуемое время для асма и С.

HN>>поэтому его применение ограничено по сравнению с C++ ,
М>??? только из-за "сложности" отладки?

Думаю, имелось ввиду "сложность поддержки".

М> не говорите ерунды. тем более сравнивая с плюсами, у которых совсем другой уровень абстракции и плюсов по сравнению с ассемблером намного больше.

На плюсах можно писать на уровне ассемблера, если понимать последний, и если требуется. Поэтому rep nop остаётся одним из немногих применений последнего (могу добавить сюда еще .safeseh)

HN>>Вообще, заморачиватся на ассемблере я бы не советовал.
М>ну ассемблер это пропуск на системный уровень. без него там делать нечего.

Без него пару дней читается мануал...