Showing posts with label x86. Show all posts
Showing posts with label x86. Show all posts

05/01/2022

System concepts (1): BSS — long forgotten but ever-present

In this post we'll take a look at one interesting concept of modern operating systems — BSS. Maybe some of you have not heard of it at all; some of you may think of it as of some sort of ancient thing and suppose it is not used these days. In first part of this post we will examine the purpose it was ever invented for. In second part we'll show how it is used these days ubiquitously even if you don't know about it.

Historically, BSS stands for "Block Started by Symbol" or "Block Starting Symbol". But we will not deepen in history because these days none of that acronym is meaningful.

Technically, BSS is a section of data in (object or executable) file. If it is a section, you may suppose we can declare it in the assembly language with .section directive. Well, that's right. Let's do it.

        .section .bss
	.lcomm var, 1 #1000

	.global main
	.text
    main:
	xorq %rax, %rax
        retq

By the way, modern assembly translators do not require keyword .section, .bss is enough. 

Let's explain what is done here. We declared .bss section with a variable named var in it with a parameter 1 (which may look like a value, but it is not). Compile and look at the resulting a.out, it's size in my case (Linux/GCC) is 16496 bytes. Now we change the parameter 1 to 1000, for example. Compile and look at size of a.out — it remains the same. "What kind of magic is that?!" It's "white" magic and now it's time to explain the whole thing. BSS was invented to save space on disk (or other storage or network bandwidth). And, yes, it's really that "ancient" invention — it originates to the 1950s. You can use it in cases when you don't need to specify values of storage area (variable), for example — to declare buffers which you will write to later, at runtime. You see that variables in .bss are declared in a different manner. It has no .globl directive — it uses .lcomm/.comm instead to specify it's visibility. .lcomm stands for local module visibility, while .comm — for global (some sort of .globl directive). The parameter (1, 1000 in our case or whatever you want) is the size of the buffer. How it works? Linker writes symbol with variable name and address and count of bytes in resulting module. At runtime .bss variables are expanded in memory to specified size and (while it's not standard, usually) initialized with zeroes.

The opposite way to declare zero-filled array is to use .fill directive on regular variable in .data section — in this case all zeroes will be written to resulting module increasing it's size. I'll omit this example here, but you may check it by yourself:

        .data
    big_var:
	.fill 1000000

At this moment you may think — "This is a good idea. But could I use it to optimize my high level language programs with this knowledge?". I've had same thoughts and have checked it. The answer is "yes", moreover — you already often do this. Here starts the second part of our little research.

The short receipt is — just declare your variables as global arrays and initialize them as { 0 }. Let's prove it:

    char lBSSVar[1] = { 0 };
    int main ()
    {
        return 0;
    }

Compile and check the resulting file size. For example, on my machine a.out is 16496 bytes (same size as a.out I've got from assembly language code). Now change the size of lBSSVar to 1000, recompile and see the size of a.out is not changed.

Let's see if it is BSS or something else by examining assembly code we get of our C-code:

	.globl	lBSSVar
	.bss
	.align 32
	.type	lBSSVar, @object
	.size	lBSSVar, 1000
    lBSSVar:
	.zero	1000

We see in this list (I've posted here the part that we are interested in only) that compiler made .bss section from our C-code. Syntax differs from my raw assembly example but technical idea is the same.

P.S.
The idea to save space in object files I've demonstrated in this post is really old. But as we see in last list syntax may differ. For example, clang uses .zerofill directive to describe uninitialized buffers. Thus different compilers may use different syntax. So, in my my opinion, if you code your application in raw assembly language you can use syntax I've shown in first part of this post — it is a short way to use BSS idea. Second part of this post lets you know how to declare buffers you don't need to initialize in high-level languages saving some extra space on storage devices and a little time loading it.

16/09/2021

Маленький взлом системы (2): заставим процессор выполнить переменную

В прошлой статье (Маленький взлом системы (1): наконец-то вы сможете изменять строки типа char* String) мы рассмотрели как можно писать в область памяти, в которую запись запрещена. Сегодня мы разовьём эту тему и попробуем выполнить переменную. Начнём с подготовительных работ. Как и в прошлый раз, нам придётся изменить режим доступа к памяти, так чтобы её можно было исполнять, то есть, чтобы выполнить call или jmp на неё. Для этого объявим переменную следующим образом:

uint8_t lMagicCode [] = { };

Содержание её мы рассмотрим ниже. А сейчас выполним установку необходимых нам режимов доступа к этой переменной. Здесь повторим действия из примера в предыдущей статьи:

void* lPageBoundary = (void*) ((long) lMagicCode & ~(getpagesize () - 1));
mprotect (lPageBoundary, 1, PROT_EXEC | PROT_WRITE);

Мы добавили режим доступа PROT_EXEC, который и позволит нам выполнить переменную. Как вы заметили, я оставил режим PROT_WRITE. Это сделано потому что MMU работает со страницами. На наших машинах её размер, вероятнее всего будет 4kB, что довольно много и помеченная страница скорее всего заденет область, следующую за интересующей нас переменной. А нам нужен режим чтения и записи для обвязки нашего эксперимента. Поэтому чтобы не схватить SIGSEGV после вызова mprotect, мы выставляем совмещённый режим — запись (которая на x86 MMU не бывает без режима чтения) и выполнение.

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

unsigned int (*NewExit)(unsigned long _ExitCode) = (void*)lMagicCode;

Здесь мы объявили указатель на функцию с названием NewExit, принимающую один параметр _ExitCode и возвращающую значение. Теперь мы можем выполнить нашу переменную и получить возвращаемое ею значение простой строчкой:

unsigned int lResult = NewExit (1);

Пока не надо этого делать — пытаясь выполнить пустую переменную, то есть, выполняя call на адрес пустой переменной, вы по сути дела, «провалитесь» дальше (как было в примере предыдущей статьи с выводом строки), а там может быть что угодно и, скорее всего, данные, даже не похожие на последовательность байт, представляющую собой корректную машинную команду с операндами. Что, вероятнее всего, приведёт к ошибке Illegal instruction.

Далее нам нужно заполнить нашу переменную корректным кодом. Начнём, допустим с возврата, то есть исключим «проваливание» потока выполнения при вызове этой функции. По справочникам найдём код операции ret, который очень простой и равен C3h.

uint8_t lMagicCode [] = { 0xC3 };

На самом деле это retn — return near, то есть ближний возврат или внутрисегментный возврат — возврат в пределах одного сегмента кода.

Теперь можно выполнить нашу функцию, не боясь неопределённых последствий, так как теперь произойдёт следующее: команда call сохранит в стэке адрес возврата равный адресу операнда следующему сразу за ним (адрес call + длинна инструкции call и его операнда), затем перейдёт по указанному адресу (адресу нашей переменной), в которой лежит код команды ret, которая, в свою очередь извлечёт адрес возврата из стэка и выполнит переход по нему.

printf ("The result of NewExit is: %d.\n", lResult);

Сейчас мы будем видеть «мусор» на выходе из функции. Для получения какого-то осмысленного результата, вернём значение. Значение из функции по правилам x86_64 ABI возвращается через регистр «семейства» AX. Мы объявили нашу функцию как возвращающую значение unsigned int, то есть 32 бита. Значит нам нужно записать результат в EAX — 32-битный регистр. Найдём код загрузки константы в EAX — это B8h. При заполнении команды нужно учитывать размерность операнда. Здесь мы не можем написать 0xB8, 0x04. Нам нужно указать всё значение полностью.

В языках высокого уровня это за нас делает компилятор. GAS так же подставляет дополненные значения в зависимости от суффикса мнемонического представления команды, например movl $0x04, %eax запишет в реальный код B804000000h, дополнив нашу четвёрку нулями до длинны long. Здесь это не тот long, о котором мы говорили в моделях памяти (LP64), это long с точки зрения x86-ой машины длинной 32 бита. Некоторые трансляторы даже подбирают код конкретной операции из обобщённого мнемонического представления и дополняют размерность операнда в зависимости от указанных размерностей приёмника и источника.

В противном случае, если мы не распишем все байты составляющие 32-битное значение, последующий код, который мы запишем как следующую инструкцию или операнд, в процессе выборки команды процессором будет воспринят как данные для загрузки в EAX. Поэтому соберём код 0xB8, 0x07, 0x00, 0x00, 0x00. И наша переменная приобретёт следующий вид:

uint8_t lMagicCode [] =
{
  0xB8, 0x07, 0x00, 0x00, 0x00, // movl $0x7, %eax
  0xC3,                         // retn
};

Теперь, вызвав эту функцию как

printf ("The result of NewExit is: %d.\n", NewExit (0));

Мы получим:

The result of NewExit is: 7

Функция названа NewExit. Давайте придадим ей этот смысл. Для этого мы воспользуемся системной функцией под номером 60/3Ch и вызовем её при помощи syscall, которая имеет код операции 0F05h. Операционная система, при вызове системных функций от пользовательских процессов, принимает номер функции в регистре EAX. Писать туда мы уже умеем. Наша переменная с машинным кодом приобретёт такой вид (возврат из этой функции нам уже не нужен):

uint8_t lMagicCode [] =
{
   0xB8, 0x3C, 0, 0, 0, // movl $0x3C, %eax, 3Ch/60 - system call exit()
   0x0F, 0x05,          // syscall
};

У нашей функции есть один параметр. Этот параметр попадёт в возвращаемое значение функции main, то есть код нашей переменной аналогичен функции exit. Вы можете это проверить запустив программу на исполнение и проверив код выхода при помощи echo $?. Вы увидите число переданное вами в функцию NewExit.

Хоть мы и передаём int в качестве параметра, возвращаемое из функции main значение всегда снижается системой до одного байта, поэтому не имеет смысла задавать значения более 255.

Здесь может возникнуть вопрос — «А почему так? Мы так много кода писали для простейших действий, а возвращаемое значение попадает в систему без каких либо операций вообще». Дело в том, что по правилам x86_64 ABI первый параметр, указанный в функции, записывается в регистр RDI. А системная функция exit, 60/3Ch возвращает в систему в качестве кода выхода значение RDI. Так совпало — наше значение «провалилось» насквозь и попало в оболочку, в переменную $? и писать нам для этого действительно ничего не пришлось.

P.S.
Интересно отметить тот факт, что отлаживать участки программы, представленные в виде переменных и сформированные в качестве их содержания, будет проблематично. Это связано с тем, что этот код попадает в секцию .data, которая отладчиком не рассматривается как код. Даже если посмотреть ассемблерный вывод после компилятора, то мы увидим просто переменную, в которой будут числовые значения — перечень наших байт в объявленном массиве.

        .size   lMagicCode, 7
lMagicCode:
        .byte   -72
        .byte   60
        .byte   0
        .byte   0
        .byte   0
        .byte   15
        .byte   5

Ниже приведу всю программу:

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <sys/mman.h>

int main (void)
{
  uint8_t lMagicCode [] =
  {
//     0xB8, 0x3C, 0, 0, 0,          // movl $0x3C, %eax # 3Ch/60 - system call exit()
//     0x0F, 0x05,                   // syscall
    0xB8, 0x07, 0x00, 0x00, 0x00, // movl $0x7, %eax
    0xC3,                         // retn
  };
  
  void* lPageBoundary = (void*) ((long) lMagicCode & ~(getpagesize () - 1));
  
  mprotect (lPageBoundary, 1, PROT_EXEC | PROT_WRITE);
  
  unsigned int (*NewExit)(unsigned long _ExitCode) = (void*)lMagicCode;
  
  unsigned long lResult = NewExit (2);
  
  printf ("The result of NewExit is: %d. Or will never be printed...\n", NewExit (0));
  
  return 0;
}

01/06/2020

Маленькая ассемблерная вставка в мой блог (1): оптимизация выставления переменных состояния

Наблюдая за алгоритмами, по которым работают механические устройства, я начал задумываться — а что, если логика программы сама по себе избыточна? Например, принтер всегда делает какие-то движения — ёрзает кареткой туда-сюда, крутит барабан взад-вперёд и, в итоге, приводит себя в положение, необходимое для работы, игнорируя своё изначальное состояние и, что самое главное — не завися от этого состояния. Это конечно заставляет больше ждать пользователя, но удешевляет устройство так как снижает количество элементов, обеспечивающих обратную связь (или вовсе исключает их) — датчики позиций, счётчики оборотов и положений механизмов. А так же, я полагаю, это упрощает алгоритм и повышает его надёжность — в более высокой степени гарантирует приведение системы к требуемому состоянию за счёт исключения сложных логических операций (вычисление состояния/положения каретки, вычисление расстояния, которое, ей надо пройти). Я обратил внимание на то, что можно делать сначала какие-то безусловные действия (настройки) и лишь затем, модифицировать состояние системы, для приведения её в требуемое и отличное от изначального состояние по условиям. То есть можно снизить количество логики, повысив количество безусловных действий. Но кто-то, возможно, скажет что это приведёт к избыточным действиям (тем более, что я только что описал подобные, избыточные действия механической системы). Это нужно проработать и проверить.
Перейдём в плоскость ИТ/ВТ и конкретно разработки ПО. Представим себе пример — нам нужно выставить какой-то флаг в зависимости от условия — флаг наличия или количества байт в буфере I2C, одно из состояний элемента GUI. Часто люди думают (и пишут) конструкции типа:
if (condition) then
    flag = value_1;
else
    flag = value_2;
или даже:
if (condition) then
    flag = value_1;
if (!condition) then
    flag = value_2;
Я всегда хотел проверить, будет ли вариант:
flag = value_2;
if (condition) then
    flag = value_1;
эффективнее для вычислительной машины. Я предполагал, что такая конструкция должна компилироваться в код, где меньше команд JMP (и сходных — JG, JE, JNE). Чтобы проверить это я написал три варианта решения этой задачи и назвал их «if-then-else», «ternary» и «if-then». if-then-else — самый понятный и, как мне кажется, первый приходящий в голову вариант. С ternary всё понятно — это выставка флага по тернарному оператору. if-then — я назвал вариант, придуманный мной (скорее — который я хочу проверить), где сначала выставляется флаг, затем происходит проверка условия, необходимого для изменения состояния флага и изменение флага если условие истинно, соответственно. Вот эти блоки кода (оформлены в отдельные программы):
// if-then-else:
int main ()
{
    int n = 1;
    if (n < 0xC0FFEE)
        n = 2;
    else
        n = 3;
    return 4;
}
// ternary:
int main ()
{
    int n = 1;
    n = (n < 0xC0FFEE) ? 2 : 3;
    return 4;
}
// if-then:
int main ()
{
    int n = 1;
    n = 2;
    if (n < 0xC0FFEE)
        n = 3;
    return 4;
}
В этих программах я использовал числа 1, 2, 3 и возвращаемое значение 4, чтобы по ним, в последствии, ориентироваться в ассемблерном коде.
Теперь посмотрим как выглядит этот код на ассемблере:
1.file "if-then-else.c"
2.text
3.globl main
4.type main, @function
5main:
6.LFB0:
7.cfi_startproc
8movl $1, -4(%rsp)
9cmpl $12648429, -4(%rsp)
10jg .L2
11movl $2, -4(%rsp)
12jmp .L3
13.L2:
14movl $3, -4(%rsp)
15.L3:
16movl $4, %eax
17ret
18.cfi_endproc
19.LFE0:
20.size main, .-main
21.ident "GCC: (GNU) 9.3.0"
22.section .note.GNU-stack,"",@progbits
1.file "ternary.c"
2.text
3.globl main
4.type main, @function
5main:
6.LFB0:
7.cfi_startproc
8movl $1, -4(%rsp)
9cmpl $12648429, -4(%rsp)
10jg .L2
11movl $2, %eax
12jmp .L3
13.L2:
14movl $3, %eax
15.L3:
16movl %eax, -4(%rsp)
17movl $4, %eax
18ret
19.cfi_endproc
20.LFE0:
21.size main, .-main
22.ident "GCC: (GNU) 9.3.0"
23.section .note.GNU-stack,"",@progbits
1.file "if-then.c"
2.text
3.globl main
4.type main, @function
5main:
6.LFB0:
7.cfi_startproc
8movl $1, -4(%rsp)
9movl $2, -4(%rsp)
10cmpl $12648429, -4(%rsp)
11jg .L2
12movl $3, -4(%rsp)
13.L2:
14movl $4, %eax
15ret
16.cfi_endproc
17.LFE0:
18.size main, .-main
19.ident "GCC: (GNU) 9.3.0"
20.section .note.GNU-stack,"",@progbits
Части кода, что одинаковы, затенены серым цветом, а те, что нас нтересуют — выделены в центре. Таким образом мы фокусируемся только на том, что нас интересует, отсекая общие для всех программ участки кода.
Что мы видим:
        movl $1, -4(%rsp)
Здесь мы иницилизируем переменную единицей (именно для того чтобы понять, где начинается интересующий нас код, я это и делаю).
        movl $4, %eax
        ret
Это наш return 4; (именно для того чтобы понять, где заканчивается интересующий нас код, я и возвращаю четвёрку).
Можно видеть, что всё происходящее вполне прозрачно и подтверждает теорию, выдвинутую мною. Теперь мы можем отранжировать методы.
if-then показал себя самым компактным, не только с точки зрения операций, но ещё и тем, что содержит на одну метку меньше, а метки так же хранятся в ELF-файле, что, в нашем случае говорит об экономии места. Стоит отметить, что место экономится гораздо меньше, чем скорость — метка в файл записывается один раз, грузится тоже один раз, а вот исполняться каждый такой участок кода в программе может неисчислимое количество раз.
На втором месте if-then-else. Вполне логично больше на одну метку и на одну операцию перехода.
А вот ternary лично меня удивил. Это самый худший вариант, как с точки зрения размера, так и с точки зрения скорости (количества операций). В этой ситуации GCC сгенерировал код, который, кроме всех операций, что выполняет в варианте if-then-else, зачем-то работает сначала через регистр EAX, а затем перекладывает значение в переменную.
Вывод: да, вариант if-then эффективнее с точки зрения выполнения на машине. Хотя такая конструкция может несколько хуже восприниматься человеком — «Как это, сначала что-то приравнивается, а потом проверяется условие, и если оно не выполняется, то флаг вообще остаётся без внимания» — как будто кто-то забыл дописать строчку. Но если люди часто используют тернарную форму записи, которая вообще «не для людей» и считают себя «сеньорами», то я думаю мы можем писать в стиле if-then и тоже вполне обосновано считать себя сеньорами.
Здесь добавлю, что мы можем пользоваться этим методом не только для выставления флагов типа 1/0 или типа Boolean — метод if-then можно использовать и для выставления иных изначальных значений — цвет кнопки зелёный, а если имеется состояние ошибки, то выставлять его в красный; количество байт в буфере — ноль, а если есть что-то на входе, то выставляем этот счётчик в нужное количество и т.д..
Так же методом if-then можно экономить (хоть и не так много в процентном соотношении) и на более сложных конструкциях ветвления: цвет кнопки зелёный, если состояние ошибки — выставить в красный, если состояние промежуточное — выставить в оранжевый. Это сэкономит не 50%, как в вышеописанных ситуациях, а количество состояний за вычетом одного перехода и одной метки. Используя метод if-then, стоит вначале выставлять переменную в максимально часто возникающее состояние (если это можно продумать) — в таком случае часто будет происходить одна операция типа MOV, за ней одна или более операций типа JMP и минимальное количество случаев с повторным MOV, так как вы уже выставили флаг в максимально часто возникающее состояние.
В следующих статьях можно будет рассмотреть что получается из иных стандартных языковых конструкциях и как можно на них срезать углы.

20/05/2005

Ретро-статья: про «уровни» языков программирования и assembler

Эта статья является вводной в курс языка программирования низкого уровня Assembler (далее — Asm). Так как эта статья вводная, мы ограничимся весьма поверхностной информацией и общими сведениями. 

Было бы логично начать с определения, что мы будем принимать за низкий уровень, а что — за высокий. Языки программирования делятся на низкоуровневые и высокоуровневые. В данном случае подразумевается степень приближённости языка программирования к языку человеческому (а так же отдалённость его от машинного языка). Дело в том, что процессор работает по своим принципам, и общаться с ним можно только на его языке. Следовательно, самый низкоуровневый язык — это язык машинного кода, так как он является родным для процессора и находится дальше всего от человеческого языка. Следующим по высоте является язык Asm, поскольку Asm представляет собою мнемонику, набор легко запоминаемых обозначений (легко запоминаемых, относительно самого машинного кода). То есть Asm оперирует напрямик с процессором и его командами. Дальше стоят языки высокого уровня, такие как BASIC, Pascal, C/C++, Fortran. И на последней ступени, на данный момент, стоят RAD системы (Rapid Application Development — быстрая разработка приложений). Такие как Visual BASIC, Visual С#, Delphi и прочие, как правило визуальные. Сейчас RAD системы принято называть «студиями», так как фирмы выпускают именно студии, визуальные, содержащие большинство распространенных языков. В наше время можно наблюдать две основные студии — Borland Developer Studio и Microsoft Visual Studio. Borland Developer Studio включает в себя Delphi (язык на основе Pascal, который в процессе эволюции получил название Delphi Language) и C#. Отдельно поставляется версия RAD системы на основе C++ — C++ Builder. Но есть вероятность что фирма Borland в ближайшем будущем совместит две эти студии в одну. Microsoft Visual Studio включает в себя Visual BASIC, Visual C++ и Visual C#. Работа в студии наиболее похожа на обычное межличностное человеческое общение, на языке напоминающем человеческий (а во многих случаях и вовсе прямо сводится к тырканью мышью по различным областям экрана). 

Не сложно предположить, что всякая программа в конечном счёте всё равно будет переведена на язык процессора. Процесс перевода с человеческого языка на машинный называется трансляцией. Процесс построения программы — это трансляция, — преобразование программы в набор объектных файлов, содержащих машинный код, и линковка — объединение объектных файлов в результирующий исполняемый файл под данную конкретную операционную систему. Если мы пишем на машинном языке, нам не требуется ничего компилировать, достаточно всего лишь сохранить в файл и можно запускать. Компиляция с Asm'а — это всего лишь последовательный перевод одной команды Asm'а в определённый набор команд процессора. Компиляция программы на Asm'е подобна переводу с Американского на Британский. В то время как компиляция с языка высокоуровневого напоминает скорее перевод с иероглифов, русского или иврита, на, допустим, тот же Британский. 

Уровень языка также отвечает за то, насколько процесс разработки, компиляции и сборки финальной программы контролируется разработчиком. То есть, программисты на машинном коде и на Asm'е полностью контролирует процесс работы своей программы. Конечно, они же говорят практически на Британском. В случае с высоким уровнем языка, и подавно с RAD системами, мы практически не можем контролировать работу процессора, в лучшем случае мы как-то можем повлиять на результат работы программы. Весь процесс перевода языков берёт на себя транслятор. Здесь можно упомянуть такое понятие, как оптимизация. Оптимизация это способ организации алгоритма, т.е. каким именно образом данный алгоритм (или задача, поставленная перед программистом) будет преобразована в машинный код. В случае с Asm'ом, всей оптимизацией занимается сам разработчик. В языках высокоуровневых, оптимизацию берёт на себя транслятор, и разработчик не знает, как будет оптимизирована его программа. Но нужно указать, что трансляторы пишут так же люди весьма умные и оптимизируют они очень и очень хорошо. Разработчику придётся немало потрудиться, дабы добиться такого уровня оптимизации вручную. 

На Asm'е можно писать как под платформу х86 (x86-based PC, те которые мы привыкли видеть, построенные на процессорах архитектуры x86, к этой платформе относятся компьютеры, начиная с IBM PC и заканчивая Pentium IV, а так же все, так называемые клоны), так и под любую технику с цифровым микроконтроллером, так как этот язык представляет собой некий стандарт. Стандарт языка, по которому принято строить языки интерпретации команд процессора. А процессор, как известно, есть и у микроволновой печки, и у стиральной машины, и у всеми любимых телефонов. То есть на Asm'е можно программировать всё, что поддаётся программированию. Но это конечно, если фирма-изготовитель позаботилась о реализации Asm'а под свою микросхему. В противном же случае нам придётся всё-таки иметь дело с машинным кодом, да ещё и со своеобразным. Изучить даже самый распространённый язык процессора, язык процессора x86, будет задачей весьма непростой. Да и не поможет это, так как при переходе на другой контроллер придётся всё переучивать, потому что у каждой микросхемы свой язык, своя система команд. То есть нам помимо Британского придётся изучить и Латиницу. А в следующий раз и Французский и так далее. Поэтому мы выбираем Asm в качестве базового языка. Тем более что Asm, будучи во много раз более удобным, чем язык машинного кода, не снижает быстродействия и не ограничивает разработчика от каких либо возможностей, предоставляемых ему микроконтроллером. Таков стандарт. 

Поскольку Asm полностью отражает структуру программируемого устройства, его реализации под различные платформы так же будут варьироваться, но сам принцип останется прежним. В связи с этим разработчику всё-таки придётся изучать и саму аппаратную часть, которая различается от процессора к процессору. То есть без наречий всё-таки не обойдётся. Здесь, во вводной статье, я не буду расписывать, как и в чём конкретно изменяется Asm внешне, в зависимости от платформы, но разработчики, знающие хотя бы архитектуру x86 уже могут представить, чем он может отличаться. Смею предположить, что их догадки будут верны. И так изучение Asm'а, как указано выше, начинается с изучения платформы под которую разработчик собирается писать и всегда связано с изучением операционной системы и её API. API — Application Programming Interface, интерфейс программирования приложений. Это некая спецификация, с которой так же придётся считаться. Всё это сразу резко отдаляет момент написания первой, пусть даже самой простейшей программы, на неопределённый срок, что очень часто отпугивает начинающих программистов, решивших перейти на Asm. 

Но мы будем работать преимущественно с платформой x86, об этом и будет дальнейшая беседа. Работу на других платформах, перенос с одной на другую, мы оставим специально обученным людям, называющим себя «Ембеддерами». Ембеддер, от слова Embedded — вложенный, встроенный. В нашем случае мы рассматриваем это слово как встроенный. Ембеддер — это человек, который занимается встраиваемыми микропроцессорными системами различного назначения, а конкретно их аппаратно-программной частью. Эти люди знают и радиотехнику, и микропроцессорную технику, и программирование. Ембеддеры знают платы на микросхемах, схемы с программируемыми контроллерами и программируют эти устройства под определённые цели. 

Что касается нас, мы можем изучать Asm не только для того чтобы писать на нём в чистом виде. Практически во всех языках высокого уровня и студиях осуществлена возможность вставки кусков кода Asmа в высокоуровневую программу. Это делается для достижения максимальной скорости выполнения отдельных участков кода, например в случаях, требующих особой скорости выполнения математических операций или прямого доступа к каким либо аппаратным ресурсам. Плюс само знание Asm'а, даже может без его использования, является неотъемлемой частью знаний настоящего специалиста в программировании и разработчика. Это нужно просто для понимания того, с чем мы работаем. 

Оригинал — 23.04.2005, здесь в редакции от 20.10.2022.

При редакции, некоторые технические и стилистические моменты были оставлены неизменными.

P.S.
Ещё пол года — и эта статья будет совершеннолетней!