Исходное сообщение
"Опубликованы тесты простейших приложений на различных языках..." Отправлено Аноним84701, 08-Дек-19 21:44
> Вот куда ушли современные компиляторы и технологии: > How new-lines affect the Linux kernel performance. > https://nadav.amit.zone/linux/2018/10/10/newline.html > Думаю, заголовок статьи говорит сам за себя. Думаю, читать все же желательно не только заголовки: > New lines in inline assembly ... > The reason turns to be the newline characters (marked as ‘\n’ above [asm volatile("1: ud2\n"]). The kernel compiler, GCC, is unaware to the code size that will be generated by the inline assembly. It therefore tries to estimate its size based on newline characters and statement separators (‘;’ on x86). In GCC, we can see the code that performs this estimation in the estimate_num_insns() function: ... > Solving the problem is not trivial. Ideally, GCC would have used an integrated assembler, similarly to LLVM, which would give better estimation of the generated code size of inline assembly. > Experimentally, LLVM seems to make the right inlining decisions and is not affected by new-lines or data that is set in other sections of the executable ... GCC, however, uses the GNU assembler after the code is compiled, Разъясняю для опеннетных аналитиков современного компиляторостроения: Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции - не известен и компилятор вынужден гадать по кол. строк и ";". Решается проблема ручками (указание размера/оверрайд и т.д.) или же включением ассемблера непосредственно в компилятор.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Вот куда ушли современные компиляторы и технологии: >> How new-lines affect the Linux kernel performance. >> https://nadav.amit.zone/linux/2018/10/10/newline.html >> Думаю, заголовок статьи говорит сам за себя. > Думаю, читать все же желательно не только заголовки: >> New lines in inline assembly > ... >> The [b]reason[/b] turns to be the newline characters (marked as ‘\n’ above [asm volatile("1: ud2\n"]). [b] The kernel compiler, GCC, is unaware to the code size that will be generated by the inline assembly. [/b] It therefore tries to [B]estimate its size based on newline characters and statement separators (‘;’ on x86). [/B]In GCC, we can see the code that performs this estimation in the estimate_num_insns() function: > ... >> Solving the problem is not trivial. [b]Ideally, GCC would have used an integrated assembler[/b], similarly to LLVM, which would give better estimation of the generated code size of inline assembly. >> Experimentally, [B]LLVM seems to make the right inlining decisions and is not affected by new-lines or data [/B] that is set in other sections of the executable ... GCC, however, [B]uses the GNU assembler after the code is compiled[/B], > Разъясняю для опеннетных аналитиков современного компиляторостроения: > Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции > - не известен и компилятор вынужден гадать по кол. строк и > ";". > Решается проблема ручками (указание размера/оверрайд и т.д.) или же включением ассемблера > непосредственно в компилятор.
	Введите код, изображенный на картинке: