@1337trix

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

0

@Constantin Cat

напишите названия языков, которые Вы знаете.
Начните с байтов.



Если серьйозно, вопрос не задан корректно.
1)Что Вы хотите изучать?
2)Что хотите программировать?
3)Сами решите, какой язык Вам нужен и для чего.

0

@R71MT

Это зависит от того, какое направление тебя больше интересует. Если (как ты говоришь) электроника и реверс, то думаю, что только ассемблер, т.к. реверс требует дизассемблирования.

Для электроники - начни с принципов постоения процессорных систем, который одинаков для всех устройств с м/процессором: компьютер, ТВ, фото-камеры, сотки и пр. Везде, где есть процессор - есть память(ПЗУ) и шина, посредством которой они соединяются. В ПЗУ прописывают м/программу (прошивку), которая управляет работой процессора. Эти микропрограммы так-же пишутся на ASM (для каждого проца свой ассемблер). Прошивки соток пишутся в основном на плюсах.

В компьютерных системах дела обстоят сложней..
У них несколько устройств и каждый со-своим процессором/контроллёром: диск, видео, сеть и т.д. Каждый из них имеет своё ПЗУ, со-своей м/программой. При таком раскладе, нужет кто-то, кто организовал-бы согласованую работу всех/этих процессоров. Этим "кто-то" является ЦП, а микропрограммой для него служит ПЗУ-BIOS. По-сути, это и есть низкий уровень.

В компьютерных системах иерархия уровней выглядит примерно так:
Нужно сказать, что в настоящее время граница между аппаратным- и программным обеспечением всё больше размывается, т.к. в архитектуре появляются новые уровни (привет UEFI).

Для аппаратного обеспечения широко распространены языки ASM и СИ.
Дельфи, Паскаль, VB годятся только для окошек. Для виртуальных машин, лидерами являются JAVA и .NET, но для них нужны соответствующие платформы: JVM /NET_Framework. Одним словом - выбирать тебе, и для начала нужно определиться, что именно ты хочешь программировать, и зачем тебе это нужно.

2

@Dit81

Ассемблер и С используется везде, где есть процессоры. Даже под разные процессоры свои ассемблеры. Но лучше начинать с x86. А для реверс-инжиниринга и исследования программных защит пригодятся поверхностные знания. Больше нужно знать функции WinAPI типа GetDlgItemTextA и GetDriveType...
Сам сейчас, в качестве справочника использую книги Зубкова С.В. "Assembler" и Калашникова "Ассемблер - это просто" 2-е издание

0

@Mikl___

Причины использования языка ассемблер

1. Образовательная причина. Помогает узнать, как микропроцессоры и компиляторы работают на уровне машинных инструкций.
2. Отладка и проверка. Просмотра ассемблерного кода, сгенерированного компилятором, или просмотр листинга, выданного дизассемблером, с целью поиска ошибок и проверки качества оптимизации критических участков программы.
3. Создание компиляторов. Понимание технологии ассемблирования непосредственно для создания компиляторов, отладчиков и других средств разработки.
4. Разработка компиляторов для языков высокого уровня. При появлении новой архитектуры или операционной системы пишут и отлаживают ассемблеры для этой системы. А потом пишут трансляторы с другим языком программирования в язык ассемблера.
5. Драйверы и системный код. Обращение к аппаратному обеспечению, регистрам и т.д. достаточно сложно организовать на языке высокого уровня. Хотя драйверы в основном пишут на С.
6. Работа с инструкциями, которые недоступны в языках высокого уровня.
7. Самомодифицирующийся код. Использование самомодифицирующегося кода в общем случае является неэффективным. Но его можно использовать, например, когда нужно включить небольшой компилятор в математическую программу для выполнения функций, определяемых пользователем. Также самомодифицирующийся код применяется для усложнения дизассемблирования и отладки программ.
8. Оптимизация кода по размеру.
9. Оптимизация кода по скорости. Современные C++ компиляторы оптимизируют код очень хорошо в большинстве случаев. Но бывает, что и эти компиляторы не могут сделать программу такой быстрой, какой её можно сделать на ассемблере, правильно расположив команды.
10. Функциональные библиотеки. Польза от оптимизации кода максимальна, когда она применяется к библиотечным функциям, используемым многими программистами.
11. Создание функциональных библиотек, совместимых с множеством компиляторов и операционных систем. Это возможно при создании библиотек с множеством входов для различных компиляторов и операционных систем.

Причины неиспользования языка ассемблер

1. Время разработки. Написание кода на ассемблере требует гораздо больше времени, чем при использовании языков высокого уровня.
2. Безопасность и надёжность. Очень просто допустить ошибку в ассемблерном коде. Ассемблер не будет контролировать сохранность регистров и переменных, если вызываемая вами функция будет их менять. Никто не скажет вам, что количество положенных в стек данных с помощью функции PUSH, не соответствует количеству выбранных данных из стека функцией POP, или, что их размерности не совпадают. А также существует возможность появления скрытых ошибок, которые невозможно выявить без систематического тестирования и отладки.
3. Отладка и проверка. Ассемблерный код достаточно сложно отлаживать и проверять, потому что он менее чувствителен к ошибкам, чем языки высокого уровня.
4. Удобство сопровождения. Ассемблерный код сложно модифицировать и сопровождать, так как он может напоминать смешанное спагетти и содержать разные хитрые трюки, которые сложно понять.
5. Переносимость. Ассемблерный код машинозависим. Переносить его на различные платформы достаточно сложно.
6. Системный код можно реализовать на встроенном ассемблере. С-компиляторы имеют возможность доступа к прерываниям, регистрам, и другим системным ресурсам, через использование встроенного ассемблера. Ассемблерный код не так часто нужен при написании драйверов и системных вызовов, и может быть заменён встроенным ассемблером по мере необходимости.

5

@kerg archer

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

0

@Constantin Cat

Ха...

Вы думаете, что схемотехника в 300'000 транзисторов, нарисованная на километровых простынях поможет изучить процессор.
Ёще одно Ха.

Изучать процессор нужно либо укрупняя схемотехнику, наращивая вентили: транзистор, пара транзисторов - тригер, восемь тригеров - регистр, и т.д, либо уменьшая функциональность:АЛУ, регистры, блок управления, шина данных, управления и т.д., постепенно всё это доводить до транзисторов.

1

@kerg archer

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

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

Миниатюры

     

 

0