Обсуждение:Ассемблер

Материал из Lurkmore

Содержание 1 8051 2 Я тоже нихуя не понял 3 .kkrieger 4 Какой-то неименованный тред про то, как страшно жить 5 Щитаю 6 Я нихуя не понял 7 Драйверы не пишутся на ассемблере! 8 Компиляторный код быстрее, чем ручной 9 Ассемблер под не-эмбедед таки используется 10 Тем временем в параллельной вселенной 11 Быдлокодерам

[править] 8051

Попрошу упомянуть в вашем высере коллега о следующей хуйне: была у меня задача, накорябать на ассемблере прогу управления свистелкой построенной на основе былинного 8051-го процика. До этого ни с первым не со вторым не сталкивался, писал на ANSI C и в хуй не дул, думал какнить разберусь - ибо времяни было отведено не много ни мало полтора года блиать. И что вы думаете ? Таки все полтора года сурово на эту хуйню и угрохал, верхом всего было вот что: как оказалось в последствии на ассемблере для 8051 нет операции ВЫЧИТАНИЯ !!! Не какого-то там лобачевского вычитания а самого что нинаесть обыкновенного двоичного хотя-бы, я уж не говорю о десятеричном или ещё каком (hex)! Нету блять вообще в принципе такого понятия для 8051 ! Три месяца изобретал велосипед сам. Потом методом тыка и "ебоной матери" допёр до вычитания прибавлением комплимента (комплимент: инверт двоичного регистра) - но три месяца еботни !!! Что самое обломное, знаешь-же сука что если есть проц то есть и вычитание полюбому как ни вертись есть, должно быть - не могут-же люди только прибавлять. Хуй: оказалось могут. Такие дела.

[править] Я тоже нихуя не понял

Можно поподробнее про то как ассемблер используется в шатлах?

[править] .kkrieger

.kkrieger написан на c++ с использованием асма, втыкать интревью. Полемику по поводу этой игры выпиливаю.

[править] Какой-то неименованный тред про то, как страшно жить

БЛДЖАД,аффтар, твоя статья ЧУТЬ МЕНЕЕ ЧЕМ ВСЯ. Ты просто заебал со своими «чуть менее» чуть менее, чем вообще. Подбери уже какой-нибудь другой эпитет, блять. Русский язык на лохоморских мемах не заканчивается, прикинь!

fail

FAIL

Трижды фейл. Переписать и добавить про эмбеддед.

Весь эмбеддед пишется на няшной сишке уже лет эдак пять. А ВСЛ туда вообще форт запихивает. Эрго: ассемблеристы должны сделать сеппуку книжкой Зубкова.

Да, нахуй такую хуету вообще и проходят. Заебали по ней даже и задачки задавать!

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

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

Я пишу эмбеддед на няшной сишке и на ассемблере. Вопросы?

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

Пизданись! Да ты хоть одну «разную» архитектуру видел? Мнемоники у него, понимаешь, копирайтом закрыты, и в этом все дело.

>В целом история языков программирования протекает в направлении от программирования на языке компьютера до манипуляции абстракциями вроде Послать. Лесом(всех(кому не нравится эта статья))[1]. На языке ассемблера этот код занял бы более 9000 КБ.

ну да, а когда ваш любимый компилер таки скомпилит эту абстракцию, у него получится 900000кб. И что?

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

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

асмовое быдло детектед. Хороший, годный компилятор генерирует код лучше, чем ты когда-то напишешь. С всякими там бранч предикшенами и прочими разбросами мозгами по пайплайнам. Алсо, «больше инструкций» давно перестало значить «медленнее». Асмоблядки даже этого не знают про свой любимый задроченный асм.

пруфец? Так и не будет пруфа про невъебенность компиляторов?

автоматика невъёбней человека в промышленном производстве. кустари от асма не нужны.

Компилятор быть может и генерирует хороший код, но порой ассемблерная вставочка в нужном месте позволяет ускорить выполнение раза в 2. Например, компилятору далеко не всегда очевидно, что в некотором месте программы можно использовать какое-нибудь расширение типа SSE. Или, что манипуляции с отдельными битами, порядком байт и т. п. можно делать безо всяких сдвигов и наложений масок, а более простыми инструкциями.

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

высокоуровневым дрочерам — дрочить дальше. Да, на асме ОЧЕНЬ трудно, долго и ебаторно сделать хоть что-то, а крупный проект так вообще нириально, процессор устареет и отправится на свалку истории раньше чем хоть что-то напишут. Но на этих ваших, особенно обьектных и мышкой, езыгах — очень трудно сделать нормально. Получить бегамайтного размера хелло ворлд — нивапрос, раз и все, получить глюкалу которая и на двд-то не помещается — еще проще, посадил тыщу индусов, дал пинка, и напейсали. Вот только при этом результат удручает, ну то есть свистоперделок все больше а работает все хуже и медленнее. И пра ашипки, то же самое — найти ашипку (особенно динамическую, приводящую к неработоспособности управляемого обьекта при реальном включении и тп, а не тупой наеб в формуле отлавливаемый примитивным тестом) среди мышой навазюканного, среди бегамайтов напложденного всякими трансглюкаторами, гораздо менее вероятно чем в асмовой глюкале которая будет выполнять ту же простенькую но критически важную задачу. Ибо эта глюкала будет меньше и проще на порядки, и главное — над ней кто-то думал а не только по кнопкам стучал. Повторюсь, да, разумеется, это самое «думал» в современном мире залог проигрыша и слива, ибо 95% вообще думать не в состоянии. Ну так это проблемы не асма а глобуса.

бла-бла-бла. «на асме ОЧЕНЬ трудно» — «на обьектных очень трудно», страдаю от безысходности, ибо нет пути. «Ибо эта глюкала будет меньше и проще на порядки» — вся история софтверной индустрии тому пример, ага.

>найти ашипку (особенно динамическую, приводящую к неработоспособности управляемого обьекта при реальном включении — это называется Run time error[[Участник: —Кенгуру 03:00, 9 марта 2011 (MSK)]]

[править] Щитаю

что необходимо сказать об асме, как о языке "намба уан" для любых профессоров. Ибо это и есть его суть - делать всё максимально быстро для конкретного камня. Тут был срач "asm vs компиляторы". Упомяните же, что компиляторы на асме и пишутся. Не все, но те, которые не по 3 минуты High-Level-программу собирают.

Честно говоря, мне кажется, что для написания компилятора на ассемблере, нужно быть больным человеком. Короче, пруфлинки на компиляторы, написанные на ассемблере.

Ну как бы логика подсказывает, что по крайней мере самый первый-то компилятор был написан на ассемблере.

и как быстро он компилил? Да и языки на месте не сидят, да. Если один только фронтенд весит 2 метра на плюсах, то страшно представить, что там будет на асме. И шо это тут вообще за асмоёбство такое?

Ящитаю, надо запилить ссылку на эту статью: [1] — душераздирающая история. Кстати, те, кто песдят, что код для embedded-систем давно пишется на C, явно не знают сути вопроса. Да, он пишется на C, но и на ассемблере он тоже пишется, ещё как! Особенно правится.

гы-гы. Смерть задрота :) Хотя грешно: сам ведь байтовые джампы тасовал, а на один забил.

[править] Я нихуя не понял

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

Ассемблерный код заменяют на С? После доводки мартышками? Я правильно понял? Первый раз про такое слышу.

[править] Драйверы не пишутся на ассемблере!

Последние драйвера написанные на ассемблере были VXD под Вынь3.1х/95. А до того были только под ДОС. Во всех остальных ОСах драйверы написаны на АСМе чуть менее чем 0 строк (за исключением может эмбэддэд системок с 64К памяти, где нет ОС и драйверы тоже не отделяются). Дело в том, что код в драйверах выполняет три задачи: 1) инициализирует устройство и структуры / процедуры уведомления, специфические для ОС (1 раз); 2) программирует запрос на устройство (когда клиент просит); 3) опрашивает устройство о данных/статусе с задержками или при получении прерывания. Во всех случаях ни более быстрый, ни более компактный код ассемблера нихуя не улучшает. А вот непереносимость будет неизлечимой (попробуй провести такой драйвер в ядро Линукса...)

Учим матчасть, срочно

[править] Компиляторный код быстрее, чем ручной

Посмотрите, к примеру, интеловские руководства по оптимизации. Вы собираетесь запоминать все pairing'и, рекомендации и прочее? Ассемблер сейчас разве что для эмбеддед, и то, там где ещё остались жёсткие ограничения по размеру. Да видали мы "оптимизированный" компилятором код. Всегда можно его ещё оптимизировать руками, и ведь дохуя и больше остаётся разжолья для творчества, ибо нет предела совершенству. Но это уже для задротов.

Именно все рекомендации. Именно все сочетания команд и их суммарную потактную эффективность. И плюс априорное знание входных данных типа "тут можно опустить очистку, потому что тут всегда ноль, а тут можно сортировать по двордам, потому что в данных всегда есть жёсткая корреляция" — именно оно даёт 80% всей оптимизации, а не сам перевод команд си в машинные команды. И ни хрена это не сложно, потому что такая технология распространяется на крошечное ядрышко, делающее всю мякотку, а всякие фронтэнды, занимающие десятки метров и занимающиеся исключительно комфортабельной для пользователя подгрузкой задач этому ядрышку, мы тупо пишем на С++ и не паримся с оптимизацией. Так было, так есть и так будет всегда. Это тот подход, который сделал Кармака тем, кто он есть, и, как мы по нему видим — этот подход продолжает работать. Этот подход превратил Линух из доморощенной поделки в конкурента мастдая (там, правда, выдроченное ядрышко и фронтэнд обычно разнесены по разным пакетам). Этот подход породил Симбиан. Этот подход позволил шейдерам (да-да, они прогались именно как это ядрышко) захватить рынок.

+1 А еще компилятор резервирует чуть меньше чем все регистры для своих компилястских нужд. Ассемблерист от этого свободен и может использовать все архитектурные регистры (сохранив компилястские) для оптимальной обработки потока данных

[править] Ассемблер под не-эмбедед таки используется

• в рантайм библиотеках С в функциях типа memcpy. Т.к. используется чуть менее чем во всех программах оптимизация не разу не преждевременна. Особенно характерно для Дефли - обусловлено весьма посредственной отимизацией с одной стороны и поддежкой исключительно х86 с другой.
• злобными хакерами для написания специфичного кода.

А нафига здесь вообще эта статья?Она же уныла чуть более,чем само программирование! Эта статья подошла бы больше для Педивикии.

Статья хорошая, годная чуть менее, чем наполовину, но повесьте же кто-нибудь на неё плашку {{Ссылкота}}! Кенгуру 22:15, 10 января 2010 (MSK)

ЭТО ПОЛНЫЙ БРЕД! Ни одна программа, написанная на высокоуровневом языке, не будет быстрее таковой по скорости исполнения (разумеется, если она не привязана к быстродействию внешних устройств и характеризуется только скоростью вычислительных действий), написанной на АССЕМБЛЕРЕ, разумеется, под совместимую (соответствующую платформу). Оптимизация кода, сиречь выкидывание ненужных диагностических кусков кода, кои зачастую бывают даже чуть более чем наполовину бОльшими, чем сам код, дает нехилую прибавку к быстродействию. Разность в быстродействии связана также с разницой в объеме кода. Например, всем известная ВИН ХР могла бы иметь раз в 40 меньше объема, и, раз в 80 большее быстродействие, будь она написана на ассемблере. Это не фантазии, я сам писал, как на асме Z80 (спектрум), так и на Х86(в частности на 486й платформе, в т.ч. программировал FPU (математический сопроцессор)).

Итого, по итогам "сухого остатка" моих излияний могу сказать, что:

1) "ценность", вес, строки высокоуровневого языка превышает "ценность" ассемблерной строки (команды) по "обще-программной ценности" совсем ненамного. Примерно на 1,0-1,2 раза. Соответственно, те программные продукты, которые пишутся на С, на Паскалях, и т.п., весьма успешно могли бы писаться на АССЕМБЛЕРАХ, и разница в труде программистов (человеко-часах) составляла бы около тех же 20-30 %.

2) ОШИБКИ, ран-тайм эрроры и пр. неприятности, возникающие в конечном программном продукте (например, в WINDOWS), совершенно не случайны. Сама возможность их возникновения обусловлена именно принципом НЕ-ассемблерного написания этих продуктов. Иными словами, чем больше "выскокоуровневость" языка, тем больше недокументированных (непонятных) действий может иметь одна отдельно взятая строка кода, и тем больше потенциальная вероятность ошибки.

Если же, писать на ассемблере, то программист волей-неволей должен САМ проработать ВСЕ возможные (и в т.ч. ошибочные) варианты "развития событий" выполнения кода. Даже пресловутое "деление на ноль" в некоторых программах вызывает "зависание", притом что совершенно аналогичная ситуация в случае прямого (на ассемблере) программирования математического сопроцессора вызывает всего лишь безобидный ответ от него в стиле "ничего не получилось".

3) Я сам этим занимался, мой дипломный проект (институт МАИ) был написан на гибриде из Турбо-Паскаля и ассемблерных вставок. Я уже начинал просто "чувствовать" Борланд Паскаль, зная наверняка какие регистры после каких команд у него какие значения имеют.

Проект был легок и беспечен, ни о каких "Run-time error" даже и речи быть не могло.

4) Конечно же, быстрота и безошибочность кода сами-знаете-какой современной операционки была принесена в жертву как можно бОльшей скорости эволюции интерфейсов, совместимости приложений и стандартизации драйверов. Отсюда куча зависаний, багов и прочей хуиты, т.к. сама суть языка АССЕМБЛЕР такова, что пишущий на нем программист ДОЛЖЕН предусмотерть ВСЕ варианты развития событий. За все приходится платить. Предусматривать все и вся было неохота, и разработчики пошли по пути наименьшего сопротивления. Результат налицо.

Как-то так! Так-то :)

«Ни одна программа, написанная на высокоуровневом языке, не будет быстрее таковой по скорости исполнения»

Серьезно?) А как же Си? Неужели код на Си без RTL будет такой уж медленный по сравнению с Асмом? да нихуя подобного, он если и отставать будет, то на несколько тактов/мс. Кому это заметно и актуально сейчас? Встречал недавно троян на С, всего 5кб,есть все необходимые функции. И кто тут хвалился, что Асм супер быстрый/минимальный по объему язык? Разве что по сравнению с делфи/вб..

Лол, ЦЕЛЫХ 5кб? Nuff said.

блядь, а на Асме сколько сделаешь? четыре с половиной? На Масме минимальный ехе под венду весит 2.5 кб. Это минимум, в котором есть только пустое окно! а тут в 5кб - целый качественный трой.

Лол, зачем окно? И да, масм эта бугога)))

Трижды лол. У меня минимальный .exe на масме вышел 705 байт. Вообще оытный демосценер в 4кб запихнет 3D графику и музыку, убив у быдлокодера всяческой желание жить. Недавно проскакивала новая вишня на ассемблере в 2.5 кб(это без сжатия, пропусти сие чудо через FSG, будет вообще смещно)

[править] Тем временем в параллельной вселенной

Разработчик под ARM рыдает кровавыми слезами от умиления. Так, к слову: ARM — это 95 % хоть что-то умеющих мобильников, Nintendo DS, эти ваши айфоны, а также ожидающийся массовый наплыв ARM-нетбуков, работающих по 20+ часов от аккумулятора. Торвальдс вообще прогнозирует скорую победу ARM над x86 по причине разницы в энергопотреблении на 1-2 порядка.

Так вот, картина следующая — ещё несколько лет назад ARM по большому счёту не вылазил за пределы мобильных телефонов, урча маянезиком гонял себе тормозные Java-игрушки, и всем было хорошо. Работает и работает. А потом ВНЕЗАПНО подкрался взрыв популярности в более требовательном к производительности сегменте. Результат такой: хитровывернутая и непривычная платформа есть, необходимость кодить есть, заказы на супер-мега-оптимизированный нативный код (то есть не Java) есть (пока большей частью игрушки, но с первыми ARM-нетбуками ситуация изменится), а все компиляторы — полнейшее, невообразимо блевотное говно динозавра, которое никто никогда не пытался совершенствовать и допиливать. Нет, правда. Что CodeWarrior, что GCC генерят какую-то эмуляцию x86, по-другому этот ужас не назвать. Внезапно выяснилось, что некоторые критические куски хорошего, годного кода на Си, переписанные руками на ассемблере, дают буст производительности в 60-80 раз. При этом не надо использовать никаких хитрых битхаков, достаточно лишь использовать все регистры и ARM-специфические инструкции, да не генерировать страницы (не утрирую, реально страницы) какого-то невообразимого клаттер-кода, гоняющего регистры туда-сюда без видимого эффекта. Такого ужаса в компиляторах под x86 в моей фирме не застал никто.

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

• Чет фигня какая-то. ARM-ы продаются лярдами - их в 5-6 раз больше x86. Разрабатывались с нуля как микропроцессор, а не как чип для калькулятора а-ля x86. Вы попробуйте нормальные компиляторы - GCC это пиздец, страх и ужас нарушающий все возможные стандарты. ARM C генерит оченя хорошо.

[править] Быдлокодерам

Попробуйте-ка ответить на следующие троллевопросы. Сможете ли вы на языке высокого уровня:

а)Открыть\закрыть вентили процессора(например A20),

б)Перевести процессор в защищенный или реальный режим,

в)Изменять содержимое регистров CR,

г)Узнать информацию о процессоре исполнив только свой код безо всяких там API и драйверов(аналог инструкции CPUID),

д)При таких-же условиях узнать количество миллисекунд с момента запуска процессора(RDTSC),

е)Вызывать прерывания, запрещать, разрешать их.

Например, написание загрузчика ОС требует знания ответов на большую часть этих вопросов.