LINUX.ORG.RU
Ответ на: комментарий от tailgunner

не дешевле, чем _что_? другого выхода просто нет. В любом случае приходится лезть в память.

seiken ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Я, наверное, чего-то недопонимаю, но push/pop как раз пишет/читает в память. В вычислениях немного сложнее "2 x 2" все регистры общего назначения заняты и приходится использовать память (будь то стек или не стек - не важно).

seiken ★★★★★
() автор топика
Ответ на: комментарий от seiken

> Я, наверное, чего-то недопонимаю, но push/pop как раз пишет/читает в память.

Верхушка стека стопудово находится в горячем кэше, и тогда push/pop работают очень быстро.

tailgunner ★★★★★
()
Ответ на: комментарий от Yareg

>А для каких целей вообще писать на асме?

Для начальной загрузки.

>Верхушка стека стопудово находится в горячем кэше, и тогда push/pop работают очень быстро.

Это понятно. Просто код получается разлапистый.

seiken ★★★★★
() автор топика
Ответ на: комментарий от seiken

>> А для каких целей вообще писать на асме?

> Для начальной загрузки.

Хы... зачем начальному загрузчику скорость?

tailgunner ★★★★★
()
Ответ на: комментарий от Manhunt

почему? Если посмотреть на код "немного сложнее 2x2", генерируемый gcc для i386 без оптимизации, как раз видна чехарда со стеком.

seiken ★★★★★
() автор топика
Ответ на: комментарий от unrealix

спроси что-нибудь попроще

seiken ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

>Хы... зачем начальному загрузчику скорость?

Вообще незачем.

seiken ★★★★★
() автор топика
Ответ на: комментарий от seiken

код «немного сложнее 2x2»

Качественный код - тривиальный код. Написать сложную запутанную программу может каждый дурак.

генерируемый gcc для i386 без оптимизации

1. Без оптимизации - это избиение младенцев.

2. Проблемы с аллокатором регистров стали в среде разрабов gcc притчей во языцах. У них в багзилле фортунки с шутками в адрес аллокатора.

3. Емнип, abi затрудняет компилятору эффективное использование всех доступных регистров.

Manhunt ★★★★★
()
Ответ на: комментарий от seiken

> приходится городить стек.

вы о чём? mov ax, 10; mov dl, 5; div [ax,]dl — где здесь стек? где обращение к памяти?

arsi ★★★★★
()

веб-кодеры негодуют.

wfrr ★★☆
()

>Оказывается, в div нельзя использовать непосредственный операнд

Часто деление на фиксированное число дешевле сделать на нескольких сдвигах. Хотя зависит уже от конкретных чисел, конечно.

http://www.golovchenko.org/cgi-bin/constdivmul

KRoN73 ★★★★★
()
Ответ на: комментарий от tailgunner

Верятно, чтобы получить перечень фортунок, нужен аккаунт в багзиле. У меня его нет. Так что просто приведу три таких фортунки.

Many people can walk on their hands. Only a few extraordinary people can run 100 mt below the ten seconds wall. Only the son of God could walk on the sea. Nobody can patch reload.c without causing regressions.

yes, I find some kind of beauty in reload after looking into dwarf2out for 2 days. (Honza)

I begin to understand the reload entity

Последняя, видимо, должна вызывать у причастных истерический смех.

Manhunt ★★★★★
()
Ответ на: комментарий от tailgunner

Если чуть серьезнее, то я многократно натыкался на обсуджение плохой работы аллокатора в случае high register pressure. И жалобы, что к аллокатору хрен притронешься.

В версии 4.4 Макаров таки осилил переделать аллокатор (и при этом в тестах Spec Cpu у gcc случилось улучшение). Возникли регрессии: в некоторых случаях новый аллокатор распределяет регистры ощутимо хуже, чем старый (о чем в багзиле имеется несколько багов). Пофиксить эти регрессии Макаров не осилил, сославшись на эвристическую природу обоих аллокаторов.

Кстати, если тебе интересно, вот бумага, где достоточно подробно рассказано и связи между ra и reload: http://ols.fedoraproject.org/GCC/Reprints-2007/makarov-reprint.pdf . В частности, на странице 78.

Manhunt ★★★★★
()

Nobody cares. Use EM64T/AMD64, там регистров больше. И обычных, и SSE.

svr4
()

открыл для себя x86 ? :)

robot12 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.