мне нужно перечитать С++

так уж исторически сложилось, что я долго говнокодил на ассемблере (не для интел)
и если я хочу посмотреть какой-то тонкий момент в С++, я хочу смотреть в ассемблерный листинг
я это 100500 раз делал, только в тех случаях язычок был не С++, а кое-какой пропиетарный язычок без рантайма, и архитектура была не интел, но в целом ничего не меняется
не надо ржать, и такое бывает

думаю пару десятков команд amd64 я осилю, чтоб читать то, во что преврвщаются простейшие и не очень С++ конструкции

допустим я буду использовать Linux и архитектуру amd64 для своих изысканий
первое, на что нужно обратить внимание в этом случае, это вот этот документ
http://www.x86-64.org/documentation/abi.pdf

оттуда нужна взять соглашения по вызовам функций ( как параметры передаютя, кто регистры какие должен сохранять и всякая такая фигня)

но я вижу что то, что я вижу в книжне и то что в листинге не соответствует одно другому
например возвращаемое значение типа инт или лонг в листинге передается через регистр %eax, а в книжке через %raх
может это то же самое, но читать неудобно


есть ли какая-нибудь дока нормальная по amd64 ABI в линуксе или может быть какая-то нормальная среда где удобно смотреть в листинг С++ компилятора и не ловит 100500 несоответствий между доками и листингом?

ИзопропилНовый Годно я вижу что то, что я вижу в книжне и то что в листинге не соответствует одно другому
например возвращаемое значение типа инт или лонг в листинге передается через регистр %eax, а в книжке через %raх
может это то же самое, но читать неудобно
соответсвует. мануал говорит автор3. If the class is INTEGER, the next available register of the sequence %rax,
%rdx is used

%eax - это младшая половина %rax
int/long в исследуемом копмиляторе - 32 разряда

вот смотри



возвращение 8 байт через %eax
sizeof(long) == 8 байт

черт это оптимизация
вот так будет возврат через %rax как в книшке
можно ее как-то отключть?



1 .file "test.cpp"
2 .local _ZStL8__ioinit
3 .comm _ZStL8__ioinit,1,1
4 .globl xxx
5 .data
6 .align 8
7 .type xxx, @object
8 .size xxx, 8
9 xxx:
10 0000 19000000 .quad 25
10 00000000
11 .text
12 .globl _Z3foov
13 .type _Z3foov, @function
14 _Z3foov:
15 .LFB971:
16 .cfi_startproc
17 0000 55 pushq %rbp
18 .cfi_def_cfa_offset 16
19 .cfi_offset 6, -16
20 0001 4889E5 movq %rsp, %rbp
21 .cfi_def_cfa_register 6
22 0004 488B0500 movq xxx(%rip), %rax
22 000000
23 000b 5D popq %rbp
24 .cfi_def_cfa 7, 8
25 000c C3 ret
26 .cfi_endproc
27 .LFE971:

зато я догадываюсь теперь как делается каст из лонг в инт
просто movl <лонг value>, % еax

извинити мне хочется ругаться матом

Изопропилзачем грустить?
movl $25,%eax заполняет нулями старшие разряды %rax
movq $25,%rax - инструкция на байт длиннее

с++ не виноват, изучай систему команд

да понятно все это
есть референс на минимальный полезный набор команд?

что-то вроде Principles of Operations для zSeries не нужно. я же не на ассемблере писать собрался

alexy_blackразве это не должно от компилятора больше зависить? какая-нибудь версия компилятора может и длину поменять.. вот например для андройда wchar то же самое что и char.

System V Application Binary Interface это вроде стандартная вещь для всех компиляторов
надеюсь люди образумились и сделали общий call stack

а в общем случае ты даже не представляешь, какой там п....ц
не то что компиляторы, даже приложения могут различаться по тому, как устроен call stack
надеюсь люди образумились и больше так не делают

Изопропилalexy_blackразве это не должно от компилятора больше зависить?
у топикстартера sizeof(long)==8 - медитировать не над чем.

ему не нравится как работает команда movl $25,%eax

мне все нравится
но все-таки предпочел бы чтоб регистры одинаково назывались
и компилер генерил бы код без оптимизации

ИзопропилНовый Годно все-таки предпочел бы чтоб регистры одинаково назывались
eax - часть rax
как они могут одинаково называться?

да система команд прошла две модификации 8086- 80386 - x64
выглядит страшненько благодаря модификаторам
посоветуешь quick start tutorial?

ИзопропилНовый Годи компилер генерил бы код без оптимизации
заслать константу в rax выбрав одну из возможных команд (да -вот такая печалька , для выполнения одного и того же элементарного действия могут использоваться разные команды)

хорошая иллюстрация момента, где "здравый смысл" подводит
Intel® 64 and IA-32 Architectures
Optimization Reference Manual3.5.1.1 Use of the INC and DEC Instructions
The INC and DEC instructions modify only a subset of the bits in the flag register. This creates a dependence
on all previous writes of the flag register. This is especially problematic when these instructions are
on the critical path because they are used to change an address for a load on which many other instructions
depend.
Assembly/Compiler Coding Rule 33. (M impact, H generality) INC and DEC instructions should
be replaced with ADD or SUB instructions, because ADD and SUB overwrite all flags, whereas INC and
DEC do not, therefore creating false dependencies on earlier instructions that set the flags.

ну значит компилеры не должны использовать INC and DEC Instructions, а вместо этого должны использовать ADD and SUB
на уровень ниже в микрокоде тоже полно такой фигни
например сдвиг влево и и умжодение на 2 это одно и то же

но речь то не об етом, речь про С++!

alexy_blackНовый Годкомпилер генерил бы код без оптимизации да ладно! а оптимизировать руками потом? ))
я знаю лично только 1 человека, который занимался вы подобными вещами
еще с парочкой переписывался

ИзопропилНовый Годно речь то не об етом, речь про С++!
так что тебе не нравится в кодогенераторе?
команды генеримые не всегда понятны и очевидны?

а ведь он может вообще остановиться на фазе генерации промежуточного представления - LLVM, например
мне все нравится
нужен только quick start tutorial
нихачу читать все комманды

ИзопропилНовый Годнужен только quick start tutorial
нихачу читать все комманды

цель то какова?

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

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

интринсике это же просто ассемблерная вставка, да?
типа TYPE __sync_val_compare_and_swap(TYPE *ptr, TYPE oldval, TYPE newval); ?
нет не надо эту хрень

Новый Год TYPE__sync_val_compare_and_swap(TYPE *ptr, TYPE oldval, TYPE newval);
это просто функция со вполне очевидной сcdfмантикой[/quote]

это 1 атомарная инструкция "сравнение с обменом"
она просто выглядит как функция чтоб С++ программеры не нервничали