Comments 66
Меня всегда интересовал вопрос. Неужели всякие там GCC генерируют нечто настолько неэффективное, что проще всю прошивку написать на чистом ассемблере, а не ограничиться вставками там, где надо работать с аппаратными ресурсами?
UFO just landed and posted this here
Это ж решается банальными вставками, возможно даже в функцию без сгенерированных компилятором пролога/эпилога, нет? Я всегда считал, что такие штуки должны выделяться в HAL, а основная логика лежать парой уровней выше.
Вопрос, конечно, интересный. И я могу лишь высказать свое мнение на этот счет, но ни в коем случае не претендую на звание истины в последней инстанции.
Так вот… Как по мне, так хороший компилятор и правильное место произрастания рук самого программиста может в совокупности составить замечательный код. Но компилятор ведь, в любом случае, добавит некоторой «отсебятины» в конечный файл. Вот самый характерный пример — системы реального времени. Там, где требуется быстродействие и присутствует ограниченность в ресурсах памяти, ассемблер (по моему глубокому убеждению) просто незаменим. При допустимо одинаковой оптимальности логического построения программы, код на ассемблере будет исполняться быстрее. А ежели вы программируете какого-нибудь военного робота, то скорость его реакции на изменяющуюся среду — это, надо отметить, не самое последнее дело.
Так вот… Как по мне, так хороший компилятор и правильное место произрастания рук самого программиста может в совокупности составить замечательный код. Но компилятор ведь, в любом случае, добавит некоторой «отсебятины» в конечный файл. Вот самый характерный пример — системы реального времени. Там, где требуется быстродействие и присутствует ограниченность в ресурсах памяти, ассемблер (по моему глубокому убеждению) просто незаменим. При допустимо одинаковой оптимальности логического построения программы, код на ассемблере будет исполняться быстрее. А ежели вы программируете какого-нибудь военного робота, то скорость его реакции на изменяющуюся среду — это, надо отметить, не самое последнее дело.
А как же распространённое мнение о том, что генерируемый С-компилятором код зачастую оптимальнее за счёт учёта таких штук как выравнивание команд в памяти, особенностей работы конвеера, etc? Да и С — по сути, кроссплатформенный ассемблер, предоставляющий набор человекочитаемых абстракций над базовыми примитивами кода.
Как говорится, распространенное мнение не всегда самое верное.
По моему мнению, компилятор — это все-таки не идеальное творение рук человеческих. Иногда случаются ошибки и в компиляторах, так что на первый взгляд правильно написанный код будет исполняться некорректно, а в таком случае, кроме как изучая во что код скомпилировался, не разберешься. А тут, собственно говоря, ассемблер и поможет.
По моему мнению, компилятор — это все-таки не идеальное творение рук человеческих. Иногда случаются ошибки и в компиляторах, так что на первый взгляд правильно написанный код будет исполняться некорректно, а в таком случае, кроме как изучая во что код скомпилировался, не разберешься. А тут, собственно говоря, ассемблер и поможет.
Оно-то верное, но проблема в том, что компилятор не может читать мысли программиста. И там, где я могу написать
Хотя далее нужды в нуле в __zero_reg__ большой может и не быть.
in sreg_save, IO(SREG), потому как я знаю, что этот регистр гарантированно здесь использоваться не будет, компилятор может, простите, нафигячить что-то вроде push __zero_reg__
push r0
in r0, IO(SREG)
push r0
clr __zero_reg__
Хотя далее нужды в нуле в __zero_reg__ большой может и не быть.
Ещё бывает, что аналогов ассемблерной команде в языке просто нет. Как пример в статье с установкой бита. На ассемблере это одна инструкция. А на C придётся считывать в переменную (а если без переменной, то всё равно будет задействован целый байтовый регистр), накладывать маску, переключать бит и записывать полученное в ячейку памяти. Типа данных «bit» и удобных операций для работы с битами в языках высокого уровня, как правило, нет.
Как по мне, ассемблер сейчас нужен не столько для того чтобы писать, сколько для того чтобы читать то что уже написали, но по какому-то странному недоразумению забыли приложить исходные коды.
UFO just landed and posted this here
Конечно, всё так. Но в вашем комментарии упоминается лишь характеристика «качества» кода. Все-таки код, на мой взгляд, это не вино, так что кроме «качества», опять же на мой взгляд, ключевыми параметрами сравнения кода от программиста и от компилятора будут, как минимум, еще и «быстродействие», «вес». Код, с эстетической точки зрения, может быть безумно красив и понятен, но с других позиций будет уступать по каким-то иным (например, перечисленным мною выше) характеристикам. В свою очередь, программист может быть не столь утончен в «формулировках», но все-таки оптимизировать код под конкретную задачу. Тут я, конечно же, сужу с позиции ассемблирования под микроконтроллеры.
Стоит также отметить, что компилятор — это не дар богов, а плоды труда все тех же программистов. Тут возникает дилемма курицы и яйца. Собственно, мне кажется, что не стоит всегда перекладывать всю работу на компилятор, ибо это лишь рукотворный инструмент, который, безусловно, может быть большим подспорьем в программировании.
Стоит также отметить, что компилятор — это не дар богов, а плоды труда все тех же программистов. Тут возникает дилемма курицы и яйца. Собственно, мне кажется, что не стоит всегда перекладывать всю работу на компилятор, ибо это лишь рукотворный инструмент, который, безусловно, может быть большим подспорьем в программировании.
UFO just landed and posted this here
Не, как я уже говорила, всё так, конечно. Собственно, я не противоречу вашей мысли, просто хочу дополнить, так сказать, пространство событий. Моя мысль заключается в том, что, во-первых, и в компиляторе присутствуют косяки, во-вторых… Как бы это лучше выразиться. Скажем так, компилятор реализуется не на основе хотя бы даже искусственных нейронных сетей… Иными словами, широта мышления отсутствует у него. Как вы правильно отметили, если программист очень хорошего уровня, то он уже знает во что будет компилироваться его код (при условии багов в компиляторе, конечно) и, грубо говоря, может прекрасно и сам написать соответствующий ассемблерный код. Другой вопрос, что благодаря тому, что он «знает», он может «не париться» на этот счет и автоматизировать процесс составления конечной программы. А вот если программист не очень хорошо шарит во всем этом деле, то и при наличии глюков не сможет толком разобраться в чем дело, ежели что-то пойдет не так.
В общем, что я хочу сказать. Увольте, я не призываю народ стереть тот же Visual Studio и писать программы в машинных кодах. Программирование высокого уровня (особенно под тот же Виндовс) чрезвычайно дельная штука. Я лишь говорю о том, что во всем могут быть недостатки (как в компиляторе, так и в программисте), а знать как и что происходит, когда человек пишет программу на языке высокого уровня будет более чем полезно. Особенно при написании больших/важных/сложных программ. А большое количество программистов пренебрегают этим полезным знанием.
Кстати да, обращаю внимание, что статья в общем ориентирована именно на начинающих людей в этом деле.
В общем, что я хочу сказать. Увольте, я не призываю народ стереть тот же Visual Studio и писать программы в машинных кодах. Программирование высокого уровня (особенно под тот же Виндовс) чрезвычайно дельная штука. Я лишь говорю о том, что во всем могут быть недостатки (как в компиляторе, так и в программисте), а знать как и что происходит, когда человек пишет программу на языке высокого уровня будет более чем полезно. Особенно при написании больших/важных/сложных программ. А большое количество программистов пренебрегают этим полезным знанием.
Кстати да, обращаю внимание, что статья в общем ориентирована именно на начинающих людей в этом деле.
Я бы от части согласился с вами, от части — нет. Всё зависит от архитектуры. Применительно к программированию МК хороший программист должен знать все её особенности, и на ассемблере в любом случае будет более оптимальный код.
Время — да больше, трудозатраты — так же, но и качество выше. И чем проще МК, тем сильнее этот разрыв в качестве.
Например на восьмибитках никогда компилятор не даст лучше кода, чем будет изначально продуманный программистом ассемблерный.
Время — да больше, трудозатраты — так же, но и качество выше. И чем проще МК, тем сильнее этот разрыв в качестве.
Например на восьмибитках никогда компилятор не даст лучше кода, чем будет изначально продуманный программистом ассемблерный.
Я знаю в совершенстве особенности и тонкости архитектуры. Я в состоянии на текущем этапе своего развития запомнить и активно применять мануал по процессору. Что я делаю не так? :)
>> Он не знает в совершенстве особенностей и тонкостей архитектуры.
С чего бы? Значит плохой программист. Для того же х86 есть мануалы Фога, масса статей по внутренностям CPU. Авторы компиляторов работают с этими же данными.
>> Он не в состоянии на текущем этапе своего развития запомнить и активно применять мануал по процессору на тысячи страниц 6 кеглем шрифта.
Обоснуйте. Типа люди стали сейчас настолько тупые, что не могут применять мануал по процессору?
Я вот помню растактовки и латентности большинства инструкций и особенности пайпланов у процов с которыми плотно работал. Для этого даже не нужно писать на асме. Когда в голове есть картина какие инструкции и в какой части конвеера выполняются — это не сложно.
Также часто получается довольно точно определить время работы некоего кода даже ДО ТОГО как я приступил к его написанию.
>> Он не умеет в уме решать задачи на перебор миллионов и миллиардов вариантов.
Извините, но это редкостный бред. Человек — не машина. Человеку не нужно перебирать варианты. Он сразу или с нескольких попыток выберет эффективный.
>> У него наверняка нет таких знаний «по науке» как у целой группы разработчиков компилятора.
Почти вся наука уходит на то, чтобы заставить тупую машину делать ПРИМИТИВНЫЕ вещи.
С чего бы? Значит плохой программист. Для того же х86 есть мануалы Фога, масса статей по внутренностям CPU. Авторы компиляторов работают с этими же данными.
>> Он не в состоянии на текущем этапе своего развития запомнить и активно применять мануал по процессору на тысячи страниц 6 кеглем шрифта.
Обоснуйте. Типа люди стали сейчас настолько тупые, что не могут применять мануал по процессору?
Я вот помню растактовки и латентности большинства инструкций и особенности пайпланов у процов с которыми плотно работал. Для этого даже не нужно писать на асме. Когда в голове есть картина какие инструкции и в какой части конвеера выполняются — это не сложно.
Также часто получается довольно точно определить время работы некоего кода даже ДО ТОГО как я приступил к его написанию.
>> Он не умеет в уме решать задачи на перебор миллионов и миллиардов вариантов.
Извините, но это редкостный бред. Человек — не машина. Человеку не нужно перебирать варианты. Он сразу или с нескольких попыток выберет эффективный.
>> У него наверняка нет таких знаний «по науке» как у целой группы разработчиков компилятора.
Почти вся наука уходит на то, чтобы заставить тупую машину делать ПРИМИТИВНЫЕ вещи.
С DSP или микроконтроллерами устоявшихся архитектур такое может быть и возможно. Но возьмем, например, x86. Вы помните наизусть особенности укладки в пайплайны всех его инструкций на всем многообразии линеек от Atom и до Core i7 и Athlon-ов? При том, что для инструкций типа умножения или квадратного корня там зачастую и в подробных мануалах от Intel/AMD не найдешь нужных сведений. Или возьмем какой-нибудь Itanium. Может ли нормальный человек удержать в голове все возможные укладки инструкций в bundles? Там даже сами ассемблеры хорошие умеют заниматься такой оптимизацией за программиста, так как считается, что даже ассемблерный программист не может все это удержать в голове. А помнит ли даже отличный программист структуру конвейеров всех существующих линеек Power[PC] процессоров от IBM и Motorola? Может быть, есть отдельные люди на всей Земле с такой феноменальной памятью и умением быстро перебирать в голове варианты. Но их действительно единицы на всей планете (единицы в прямом смысле). Остальных же программистов компилятор обгонит в 99% случаев при достаточно объемной программе. Если речь не идет о вручную проработанном внутреннем счетном цикле из 5-10 инструкций.
Нельзя обьять необьятное.
Люди, которые пишут на асме какие-то оптимизированные вещи, разрабатывают под _конкретное устройство или семейство CPU_.
И нормальный компилятор тоже делает тоже самое.
Можно просто писать на среднем_по_больнице_асме, как в MenuetOs, например. Но это не имеет практической пользы.
>> Вы помните наизусть особенности укладки в пайплайны всех его инструкций на всем многообразии линеек от Atom и до Core i7 и Athlon-ов
В старых ООО х86 нужно было лишь правильно положить инструкции в памяти по простым правилам. В современных ещё проще. От P6 до Sandy Bridge (кроме P4) схема OoO практически одинаковыя. С той разницей что сейчас делается предекодирование, а-ля трейскеш P4.
Правила они не с потолка берутся — это конкретная железка, которая делает fetch-decode. Поэтому нужно примерно представлять её блок-схему.
>> для инструкций типа умножения или квадратного корня там зачастую и в подробных мануалах от Intel/AMD не найдешь нужных сведений
А что там нет такого, что хотелось бы знать?
Под итаниум не писал, но насколько я помню правила укладки в бандлы никаких проблем не должны вызывать.
Авто-распределение регистров и авто-скЕдулер штука очень удобная для архитектур с большими латентностями (например мой любимый SPU) У компилятора же проблемы больше с генерацией, чем с «размазыванием» инструкций по «дыркам».
>>А помнит ли даже отличный программист структуру конвейеров всех существующих линеек
Концептуально они не слишком отличаются. Просмотр схемы конвеера позволяет получить бОльшую информации. Запоминать нужно не всё, а важные и отличающиеся вещи. Если что-то не помнишь, не будет зазорным подсмотреть.
>>Может быть, есть отдельные люди на всей Земле с такой феноменальной памятью и умением быстро перебирать в голове варианты
Реально не понимаю что вы хотите доказать. Что тупой последовательный алгоритм написанный человеком «умнее» человека?
Человеческому мозгу НЕ НУЖНО ПЕРЕБИРАТЬ ВАРИАНТЫ.
Это сравни сочинению симфонии путём перебора случайных нот или написанию книги рандомными символами.
>>Остальных же программистов компилятор обгонит в 99% случаев при достаточно объемной программе
Каждый день убеждаюсь в обратном. Смотришь в результат работы GCC и плакать хочется
Но на асм переписывать времени нет. Тут бы тупо на SIMD перевести успеть.
Люди, которые пишут на асме какие-то оптимизированные вещи, разрабатывают под _конкретное устройство или семейство CPU_.
И нормальный компилятор тоже делает тоже самое.
Можно просто писать на среднем_по_больнице_асме, как в MenuetOs, например. Но это не имеет практической пользы.
>> Вы помните наизусть особенности укладки в пайплайны всех его инструкций на всем многообразии линеек от Atom и до Core i7 и Athlon-ов
В старых ООО х86 нужно было лишь правильно положить инструкции в памяти по простым правилам. В современных ещё проще. От P6 до Sandy Bridge (кроме P4) схема OoO практически одинаковыя. С той разницей что сейчас делается предекодирование, а-ля трейскеш P4.
Правила они не с потолка берутся — это конкретная железка, которая делает fetch-decode. Поэтому нужно примерно представлять её блок-схему.
>> для инструкций типа умножения или квадратного корня там зачастую и в подробных мануалах от Intel/AMD не найдешь нужных сведений
А что там нет такого, что хотелось бы знать?
Под итаниум не писал, но насколько я помню правила укладки в бандлы никаких проблем не должны вызывать.
Авто-распределение регистров и авто-скЕдулер штука очень удобная для архитектур с большими латентностями (например мой любимый SPU) У компилятора же проблемы больше с генерацией, чем с «размазыванием» инструкций по «дыркам».
>>А помнит ли даже отличный программист структуру конвейеров всех существующих линеек
Концептуально они не слишком отличаются. Просмотр схемы конвеера позволяет получить бОльшую информации. Запоминать нужно не всё, а важные и отличающиеся вещи. Если что-то не помнишь, не будет зазорным подсмотреть.
>>Может быть, есть отдельные люди на всей Земле с такой феноменальной памятью и умением быстро перебирать в голове варианты
Реально не понимаю что вы хотите доказать. Что тупой последовательный алгоритм написанный человеком «умнее» человека?
Человеческому мозгу НЕ НУЖНО ПЕРЕБИРАТЬ ВАРИАНТЫ.
Это сравни сочинению симфонии путём перебора случайных нот или написанию книги рандомными символами.
>>Остальных же программистов компилятор обгонит в 99% случаев при достаточно объемной программе
Каждый день убеждаюсь в обратном. Смотришь в результат работы GCC и плакать хочется
Но на асм переписывать времени нет. Тут бы тупо на SIMD перевести успеть.
Посмотрите на объемы md-файлов в проекте GCC. Например, для того же x86. Или md-файлы для любого другого семейства современных процессоров общего назначения, типа Itanium, PowerPC, MIPS или даже для более простой линейки ARM. Сами объемы говорят за себя, не говоря уже о сотнях тонкостей в описании пайплайнов, байпассов и юнитов. Посмотрите на объемы кода в самом компиляторе, который занимается scheduling-ом инструкций при генерации по этим md-файлам. Огромные объемы разных тонкостей, уловок и так далее, комбинаторики и эвристик – чтобы решить как оптимально распихать команды по конвейерам. Я убежден, что обычный человек не может все это уместить в своей голове. Есть только единичные люди, которые интуитивно чувствуют, как нужно писать, чтобы реально обгонять компиляторы (на высоких уровнях оптимизации).
Если говорить именно о процессорах общего назначения – обычно код не пишется под конкретную железку. Даже если он внутреннего пользования. Ведь железо меняется каждый год, компания переходит на новые серверы и так далее. Я уж не говорю о коде для пользовательских машин. Поэтому писать большие объемы кода на ассемблере сейчас просто бессмысленно. Если нужно, чтобы этот код был лучше сгенерированного компилятором — потребуются самые лучшие программисты страны/мира, с соответствующими офигенными зарплатами. А через год их код станет неактуален из-за входа новой линейки процессоров.
Поэтому сейчас ассемблер на процессорах общего назначения нужен только для вставки особых команд и оптимизации самых внутренних циклов в самых критичных ко времени приложениях на последней стадии доводки проекта, когда в целом все уже работает. Как самостоятельный язык программирования он давно утратил смысл.
Если говорить именно о процессорах общего назначения – обычно код не пишется под конкретную железку. Даже если он внутреннего пользования. Ведь железо меняется каждый год, компания переходит на новые серверы и так далее. Я уж не говорю о коде для пользовательских машин. Поэтому писать большие объемы кода на ассемблере сейчас просто бессмысленно. Если нужно, чтобы этот код был лучше сгенерированного компилятором — потребуются самые лучшие программисты страны/мира, с соответствующими офигенными зарплатами. А через год их код станет неактуален из-за входа новой линейки процессоров.
Поэтому сейчас ассемблер на процессорах общего назначения нужен только для вставки особых команд и оптимизации самых внутренних циклов в самых критичных ко времени приложениях на последней стадии доводки проекта, когда в целом все уже работает. Как самостоятельный язык программирования он давно утратил смысл.
>> Посмотрите на объемы md-файлов в проекте GCC.
Смотрел. Даже баги правил в кодгене под Sparc (в коде)
Все эти объёмы не мешают ему генерить говнокод =) Скорее даже помогают.
Например на in-order процессорах, тупым перемещением строк внутри цикла легко добится как ускорения, так и замедления (при достаточном размере цикла).
На конкретном 400-тактовом внутренним цикле (на SPU) я получал +-20% перемещая небольшой блок кода. Весь цикл — чисто функциональный SSA-style код.
>> Есть только единичные люди, которые интуитивно чувствуют, как нужно писать, чтобы реально обгонять компиляторы
>>Если говорить именно о процессорах общего назначения – обычно код не пишется под конкретную железку
На PC и встройку пишут под конкретное семейство CPU (о чём я сказал). А вот на консолях пишут под конкретный проц. С практической целью, естественно.
Писать на ассемблере _ради ассемблера_ сейчас не имеет практической пользы, разве что если не знаешь других языков =) «С» я изучил в ~99г. До этого 100% асм.
>> Я убежден, что обычный человек не может все это уместить в своей голове
Обычные российские граждане не знают языка Суахили, например.
То что вы работаете на Роботов, я уже понял, но мозг может запомнить столько книг, сколько не прочитаешь и за всю жизнь. И уж запомнить инфу из нескольких TRM это вообще ничто.
Это как учить иностранный язык. Вначале со словарём, а потом он вам уже так часто не нужен будет. Ну может быть подсмотреть пару слов.
Да тот же английский куда сложнее чем асм =)
Вобщем вы выдумываете какие-то проблемы, которых нет.
>> Поэтому писать большие объемы кода на ассемблере сейчас просто бессмысленно
А где я утверждаю обратное? Я это подчеркивал как раз.
>> А через год их код станет неактуален из-за входа новой линейки процессоров.
На встройке как были всякие 8051 PIC AVR и ARM7, так и остались.
Уж за 15-20лет то можно научится писать под проц, где и конвеера-то 3 стадии в лучшем случае. И где ничего не поменялось за этот срок.
Опять же, на консолях пишут сравнительно много ассемблерного кода, который актуален в течении всего 10-летнего жизненного срока, а то и больше — если СPU не сменят на несовместимый.
Да даже на PC в самых свежих интеловских процах всё что есть это небольшое развитие архитектуры 15 летней давности.
Смотрел. Даже баги правил в кодгене под Sparc (в коде)
Все эти объёмы не мешают ему генерить говнокод =) Скорее даже помогают.
Например на in-order процессорах, тупым перемещением строк внутри цикла легко добится как ускорения, так и замедления (при достаточном размере цикла).
На конкретном 400-тактовом внутренним цикле (на SPU) я получал +-20% перемещая небольшой блок кода. Весь цикл — чисто функциональный SSA-style код.
>> Есть только единичные люди, которые интуитивно чувствуют, как нужно писать, чтобы реально обгонять компиляторы
>>Если говорить именно о процессорах общего назначения – обычно код не пишется под конкретную железку
На PC и встройку пишут под конкретное семейство CPU (о чём я сказал). А вот на консолях пишут под конкретный проц. С практической целью, естественно.
Писать на ассемблере _ради ассемблера_ сейчас не имеет практической пользы, разве что если не знаешь других языков =) «С» я изучил в ~99г. До этого 100% асм.
>> Я убежден, что обычный человек не может все это уместить в своей голове
Обычные российские граждане не знают языка Суахили, например.
То что вы работаете на Роботов, я уже понял, но мозг может запомнить столько книг, сколько не прочитаешь и за всю жизнь. И уж запомнить инфу из нескольких TRM это вообще ничто.
Это как учить иностранный язык. Вначале со словарём, а потом он вам уже так часто не нужен будет. Ну может быть подсмотреть пару слов.
Да тот же английский куда сложнее чем асм =)
Вобщем вы выдумываете какие-то проблемы, которых нет.
>> Поэтому писать большие объемы кода на ассемблере сейчас просто бессмысленно
А где я утверждаю обратное? Я это подчеркивал как раз.
>> А через год их код станет неактуален из-за входа новой линейки процессоров.
На встройке как были всякие 8051 PIC AVR и ARM7, так и остались.
Уж за 15-20лет то можно научится писать под проц, где и конвеера-то 3 стадии в лучшем случае. И где ничего не поменялось за этот срок.
Опять же, на консолях пишут сравнительно много ассемблерного кода, который актуален в течении всего 10-летнего жизненного срока, а то и больше — если СPU не сменят на несовместимый.
Да даже на PC в самых свежих интеловских процах всё что есть это небольшое развитие архитектуры 15 летней давности.
Бывает варианты когда на Си в принципе нельзя писать. Например когда ОЗУ нет вообще :)
Ну и в целом можно и нужно писать на Си, но знание ассемблера помогает ПРАВИЛЬНО писать на Си, чтобы компилятор там не рожал монстров.
Плюс отладка, иной раз все работает ну совсем не так как оно написано. А отладка по сишному тексту после его оптимизации практически не работает, т.к. на исходный текст оно вообще не похоже и курсор скачет как полоумный по всему тексту :) А в режиме дизасма переключаешься и все хорошо видно и понятно. Отключать оптимизацию не вариант — это будет уже совсем другая программа с совсем другими глюками.
Опять же зная асм можно понять как на Си написать ту или иную вещь, часто бывает это совсем неочевидно. Ведь среди МК разброд и шатания в плане архитектуры. Куча разных видов адресных пространств. Например, на AVR в GCC для того, чтобы строку разместить во флеше недостаточно просто обьявить ее как PROGMEM, она должна быть еще вне main иначе работать будет, но помимо того что она будет во флеше, так она еще и в ОЗУ запихается в самом начале проги и ляжет там балластом. А потом бедные программисты сидят и гадают, а чего это у них ОЗУ так резко кончилось. Все летит кувырком и сплошные срывы стека. Кстати, о срывах стека — ассемблерщики это чуют жопой с рождения, те кто всю жизнь писал на Си (да под ПК) может и не догадываться о такой милой вещи :)
Ну и в целом можно и нужно писать на Си, но знание ассемблера помогает ПРАВИЛЬНО писать на Си, чтобы компилятор там не рожал монстров.
Плюс отладка, иной раз все работает ну совсем не так как оно написано. А отладка по сишному тексту после его оптимизации практически не работает, т.к. на исходный текст оно вообще не похоже и курсор скачет как полоумный по всему тексту :) А в режиме дизасма переключаешься и все хорошо видно и понятно. Отключать оптимизацию не вариант — это будет уже совсем другая программа с совсем другими глюками.
Опять же зная асм можно понять как на Си написать ту или иную вещь, часто бывает это совсем неочевидно. Ведь среди МК разброд и шатания в плане архитектуры. Куча разных видов адресных пространств. Например, на AVR в GCC для того, чтобы строку разместить во флеше недостаточно просто обьявить ее как PROGMEM, она должна быть еще вне main иначе работать будет, но помимо того что она будет во флеше, так она еще и в ОЗУ запихается в самом начале проги и ляжет там балластом. А потом бедные программисты сидят и гадают, а чего это у них ОЗУ так резко кончилось. Все летит кувырком и сплошные срывы стека. Кстати, о срывах стека — ассемблерщики это чуют жопой с рождения, те кто всю жизнь писал на Си (да под ПК) может и не догадываться о такой милой вещи :)
Это пожалуй единственная не прочитаная даьше первых глав книга на моей полке.
Я начинал под Z80 (92 год где-то) причём до этого почти не был знаком с программированием, только базовые знания бейсика на уровне школоты…
Главное это удобный отладчик, и само собой хорошая литература.
(У меня отдладка была вся ручкой в тетрадке, по этому познавал ASM я в 10 раз дольше чем те кто учился с нормальными отладчиками)
Главное это удобный отладчик, и само собой хорошая литература.
(У меня отдладка была вся ручкой в тетрадке, по этому познавал ASM я в 10 раз дольше чем те кто учился с нормальными отладчиками)
+1. У меня не было ассемблера даже в те времена, а ещё не было нормального мануала по Z80, была только тонкая книжка «Учимся программировать КР580ВМ80А» или что-то в этом духе, в конце которой была приведена табличка соответствия мнемоник и восьмеричных кодов команд.
А когда я начал под ×86 писать, аналогичная книжка меня уже не спасла, т.к. в ней не было опкодов. Вскоре, правда, нашлась Большая Чёрная Книга на тыщу страниц, в которой описывалось всё, включая опкоды, функции BIOS, а также распиновки 80286 и 80386, а также debug.com и двухпроходный метод написания программ с его использованием — вначале набить программу со всеми джампами на текущий адрес, а потом вторым проходом перебить адреса на настоящие.
Вот так вот.
А когда я начал под ×86 писать, аналогичная книжка меня уже не спасла, т.к. в ней не было опкодов. Вскоре, правда, нашлась Большая Чёрная Книга на тыщу страниц, в которой описывалось всё, включая опкоды, функции BIOS, а также распиновки 80286 и 80386, а также debug.com и двухпроходный метод написания программ с его использованием — вначале набить программу со всеми джампами на текущий адрес, а потом вторым проходом перебить адреса на настоящие.
Вот так вот.
Наш чувак! У меня до сих пор хранятся эти тетрадочки в клеточку с командами Z80 (а после 8051) в столбик.
Таких много на самом деле, до сих пор многие под спеки пишут. Правда теперь увы только для развлечения, и чаще всего на эмуляторах. Но факт остаётся фактом.
Я как то на zx.pk.ru попал, чуть со стула не упал, думал все уже забыли что бывают компы меньше чем гигагерц, а нет, пишут, и сегодня…
Я как то на zx.pk.ru попал, чуть со стула не упал, думал все уже забыли что бывают компы меньше чем гигагерц, а нет, пишут, и сегодня…
Такая же фигня. Отладчик был, но проще было переписать в тетрадку, там же написать комментарии, нарисовать в той же тетрадке диаграммы или блоксхемы.
Э… А о чём, собственно, статья? Очередной мотиватор? Надеялся на большее. Полезной информации — ноль. А в комментах вечный холивар — Assembler vs C. Хотите поговорить об этом? (и не только)
Пофиг на ассемблер, футболку где взять??!
Растолкуйте нубу, пожалуйста, что там написано. Я только понял, что это как-то связано с процедурами.
Например, здесь: www.getdigital.de/products/Assembler/lng/en
Как раз интересуюсь асмом, посоветуйте хороший учебник
Мне понравился «Зубков С.В. Ассемблер для DOS, Windows и Unix», но это ИМХО
Супер книга! По ней реально можно весьма быстро писать на х86
Она хорошо структурирована и там упущена «лирика», она концентрирует внимание на главном, и главное она последовательна. Она одновременно и учебник и справочник. Редко такое можно встретить.
Криса Касперски почитайте — как книги, так и статьи.
Справочник по инструкциям, отладчик, дизассемблер, интересные приложения
Если речь про x86 архитектуру, то начинайте с «Кип Р. Ирвин — Язык ассемблера для процессоров Intel» — не пожалеете, тут все пальцах показано и грамотно выстроен порядок изложения материала, автор отличный педагог. Потом уже классики жанра — Абель и Юров. Зубков тоже неплох, но многие необходимые базовые моменты изложены вскользь. Удачи.
Статью написала Светлана?
Интересно как выглядит девица, которая кодит на асме
Интересно как выглядит девица, которая кодит на асме
Как показывает практика, примерно так же как и все остальные обременённые интеллектом.
Как, как? Как огурчик! Зеленая и в пупырышку.
А фото можно глянуть по ссылке в профайле.
А фото можно глянуть по ссылке в профайле.
Примерно так
>> Интересно как выглядит девица, которая кодит на асме
Например так
web.mac.com/christinacoffin/iWeb/Site/Main%20Page.html
Christina Coffin, Platform Specialist @ DICE
Например так
web.mac.com/christinacoffin/iWeb/Site/Main%20Page.html
Christina Coffin, Platform Specialist @ DICE
Знать ассемблер, конечно, хорошо и полезно для общего развития, но вот писать на нём, по моему скромному мнению, нет смысла с тех пор, когда изобрели branch predictor, т.е. примерно с начала 80-х годов 20 века.
Э… А о чём, собственно, статья? Очередной мотиватор? Надеялся на большее. Полезной информации — ноль. А в комментах вечный холивар — Assembler vs C. Хотите поговорить об этом? (и не только)
Sign up to leave a comment.
Ассемблер для начинающих