Я программировал руку / большой палец много лет, много ассемблера, и мне понадобилось очень мало из множества директив.
.thumb_func очень важен, как указал другой респондент.
*Например, 1004 *
.globl _start
_start:
b reset
reset:
.arm
.globl one
one:
add r0,r0,#1
bx lr
.thumb
.globl two
two:
add r0,r0,#2
bx lr
.thumb_func
.globl three
three:
add r0,r0,#3
bx lr
.word two
.word three
.arm или что-то вроде .code32 или .code 32 говорит, что это код руки, а не код большого пальца, который для вашего cortex-m3 вам не нужно использовать.
.thumb аналогично, раньше он был .code 16 или, может быть, все еще работает, то же самое действие делает следующий код большим пальцем, а не оружием.
Если используемые вами метки не являются глобальными метками, которые вынужно переходить из других файлов или косвенно, тогда вам не понадобится .thumb_func.Но для того, чтобы адрес ветви для одной из этих глобальных меток был правильно рассчитан (lsbit - это 1 для большого пальца и 0 для руки), вы хотите пометить его как метку большого пальца или руки, а thumb_func делает это, иначе вынеобходимо установить этот бит перед ветвлением, добавив больше кода, и метка не будет вызываться из C.
00000000 <_start>:
0: eaffffff b 4 <one>
00000004 <one>:
4: e2800001 add r0, r0, #1
8: e12fff1e bx lr
0000000c <two>:
c: 3002 adds r0, #2
e: 4770 bx lr
00000010 <three>:
10: 3003 adds r0, #3
12: 4770 bx lr
14: 0000000c andeq r0, r0, ip
18: 00000011 andeq r0, r0, r1, lsl r0
До. thumb ассемблер - код руки по желанию.
Обаи три метки / функции представляют собой код большого пальца по желанию, но две метки имеют четный адрес, а три имеют правильный нечетный адрес.
Для сборки, связывания и вывода вышеприведенного примера использовались новейшие инструменты кодирования..
Теперь для cortex-m3, где все с большим пальцем (/ thumb2), thumb_func может быть не так важен, он может просто работать с переключателями командной строки (очень легко провести эксперимент, чтобы выяснить это).Это хорошая привычка, если вы переходите от процессора «только большой палец» к обычному ядру «рука / большой палец».
Ассемблеры, как правило, любят добавлять все эти директивы и другие способы, чтобы вещи выглядели как язык высокого уровня.Я просто говорю, что вам не нужно их использовать, я переключил ассемблеры на руку и использую много разных ассемблеров для множества разных процессоров и предпочитаю подход «меньше - больше», то есть сосредоточиться на самой сборке и использовать как можно меньше элементов, специфичных для инструмента.Я обычно исключение, а не правило, поэтому вы, вероятно, можете выяснить, какие чаще всего используются директивы, посмотрев, какие директивы генерирует вывод компилятора (и сверьтесь с документацией).
unsigned int one ( unsigned int x )
{
return(x+1);
}
.arch armv5te
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 18, 4
.file "bob.c"
.text
.align 2
.global one
.type one, %function
one:
.fnstart
.LFB0:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r0, r0, #1
bx lr
.fnend
.size one, .-one
.ident "GCC: (Sourcery G++ Lite 2010.09-50) 4.5.1"
.section .note.GNU-stack,"",%progbits
Я использую.align при смешивании манипулятора руки и большого пальца или данных с ассемблером, вы ожидаете, что ассемблер для такой платформы будет знать что-то столь же очевидное, так как инструкции большого пальца находятся на границах полуслов, а инструкции руки выровнены на границах слов.Инструменты не всегда такие умные.
.text - это значение по умолчанию, поэтому оно немного избыточно, но не повредит..text и .data - это стандартные атрибуты (не специфичные для arm), если вы компилируете для своей цели комбинацию rom и ram, которая может вас заинтересовать (зависит от того, что вы делаете со своим сценарием компоновщика), в противном случае .text будет работать для всего,
.size, очевидно, размер функции начала этой директивы.Ассемблер не может понять это сам по себе, поэтому, если размер этой функции важен для вашего кода, сценария компоновщика, отладчика, загрузчика, что бы то ни было, это должно быть правильно, иначе вам не придется беспокоиться.Функция - это концепция высокого уровня. В любом случае, ассемблер действительно не имеет функций, и тем более не требуется объявлять их размер.И компилятору C это безразлично, он ищет только метку для перехода, а в случае семейства arm это код большого пальца или код arm, к которому идет ветвь.
вы можете найти директиву .pool (есть более новый эквивалент) полезной, если вы ленивы со своими непосредственными пользователями (ldr rx, = 0x12345678) на длинных отрезках кода.И здесь инструменты не всегда достаточно умны, чтобы размещать эти данные после безусловной ветки, вам иногда приходится об этом говорить.Я говорю «ленивый наполовину всерьез, делать ярлык больно: .word постоянно», и я полагаю, что инструменты arm и gcc позволили использовать этот ярлык, поэтому я использую его так же, как и все остальные.
Также обратите внимание, что llvm выводит дополнительный .eabi_attribute или два, которые поддерживаются версией / модами исходного кода для binutils, но не поддерживаются (возможно, пока) в выпущенном binutils для gnu.Два решения, которые работают, модифицируют функцию печати asm llvm, чтобы не писать eabi_attributes или, по крайней мере, писать их с комментарием (@), или получать исходные коды / моды binutils из исходного кода и создавать таким образом binutils.исходные тексты кода приводят к появлению gnu (например, поддержки thumb2) или, возможно, бэкпортят новые функции, так что я предполагаю, что эти атрибуты llvm будут присутствовать в mainline binutils в ближайшее время.Я не пострадал, обрезав eabi_attributes от скомпилированного кода llvm.
Вот вывод llvm для той же функции, что и выше, по-видимому, это llc, который я изменил, чтобы закомментировать eabi_attributes.
.syntax unified
@ .eabi_attribute 20, 1
@ .eabi_attribute 21, 1
@ .eabi_attribute 23, 3
@ .eabi_attribute 24, 1
@ .eabi_attribute 25, 1
@ .eabi_attribute 44, 1
.file "bob.bc"
.text
.globl one
.align 2
.type one,%function
one: @ @one
@ BB#0: @ %entry
add r0, r0, #1
bx lr
.Ltmp0:
.size one, .Ltmp0-one
Формат файла elf хорошо документирован и его очень легко проанализировать, если вы действительно хотите увидеть, что делают специфические директивы elf (если таковые имеются).Многие из этих директив должны помочь компоновщику больше всего на свете..thumb_func, .text, .data, например.