Skip to main content

Конференции

Просмотр конференции fido7.su.c-cpp:

Предыдущее Следующее

Дата: 22 Sep 2016, 09:03:57
От: Valentin Nechayev @ 2:5020/400.0
Кому: Yury Haron
Тема: Re: Вопрос по коду



>>> Yury Haron wrote: 

 VN>> Я на всякий случай выдержал время, чтобы ты мог сам понять, где у
 VN>> тебя пробелы в логике на уровне букваря, но, видимо, надо сказать
 VN>> в открытую: для любого из них есть (квантор существования) не-матерные
 VN>> оценки, просто потому, что компиляторы таки работают в среднем
 VN>> достаточно хорошо.
YH> Есть и такие. Hо здесь речь шла не о компиляторах "вообще", а конкретно о
YH> "многоплатформенных". А среди них, такое поведение не встречается (в б/м
YH> распространённом ПО).

Какое "такое" поведение?

 VN>> Если тебя интересовало распределение оценок, доля крайних случаев,
 VN>> когда он неоптимально что-то пишет, от конкретных применений, и т.п. -
 VN>> надо было это сказать явно.
YH> Я сказал явно, но для тебя могу и повторить - кодогенерация нижнего уровня (ну,
YH> например, раскладка по регистрам) не работает "по человечески" у gcc для многих
YH> платформ (думаю, что для всех, но - не проверял).

И опять какое-то неконкретное "по-человечески". Хоть один измеряемый
параметр будет?

В регистрах хранится меньше, чем могло бы влезть? Тогда - насколько, и
какой тип этого "меньше" - не используются целые регистры или части
регистра?

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

Hа платформах с разной ценой доступа к разным регистрам не оптимально
используются наиболее дешёвые?

Или "по-человечески" означало всегда использовать для одного и того же
параметра один и тот же регистр? :)

 VN>> "Однокристалки" тоже понятие чудовищно широкое, включая в себя вплоть
 VN>> до x86 и AArch64.
YH> Я мог бы, конечно, попросить ссылку на какую-нито схему использования x86 без
YH> кучи обвязки, после чего высказаться на тему использования м-м-м своеобразной
YH> терминологии собеседником, но не буду.

OK, рассматриваем с поправкой, что Edison - это то, что я имел в виду
под классом однокристалок (не будем вдаваться в тему редких и
экспериментальных изделий). Уточни термин в своём стиле, и я его буду
тут использовать. А также скажи, какие именно ISA ты имел в виду в
случае однокристалок. Конкретные названия и прямым текстом.

YH> Хочешь рассуждать на примере x86? Да
YH> Бога ради - попробуй "обосновать" то, что gcc для процедур возвращающих bool
YH> (или char) хронически генерит на выходе нечто вроде
YH>     and eax, 0ffh
YH>     ret

Да, ты знаешь, трудно такое воспроизвести. Очень трудно. Давай я
попробую погадать. Первый, самый логичный, вариант: речь о каком-то
сужении диапазона для загоняние из более широкого значения. Какое у
нас более широкое? int? Пробуем - да, заведомо на самом простом коде,
чтобы исключить все посторонние эффекты.

char g1(int a) {
  return a;
}

превращается (здесь и далее GCC 4.8, -O1, -march=i686 для 32,
умолчание для 64)

g1:
        movzbl  4(%esp), %eax
        ret

а вот для 64 бит:

g1:
        movl    %edi, %eax
        ret

Я взял из присутствующих на gcc.gotbolt.org самый ранний - 4.4.7 - он
такого тоже не показывает. Hу да, логика чуть неровная - он в первом
случае извлекает один байт, во втором - целое слово. Hо - имеет право
- всё равно, если char, важен только al. (Тут ещё разница в соглашении
о вызове и передаче результата в нём.) Ладно, пробуем с -mabi=ms:

g1:
        movl    %ecx, %eax
        ret

Уй, регистр поменялся.

Может, ты тестировал на каком-то из 3.*? Тогда - а где ещё такое,
извините, сохранилось?

bool, говоришь?

bool g1(int a) {
  return a;
}

_Z2g1i:
        cmpl    $0, 4(%esp)
        setne   %al
        ret

_Z2g1i:
        testl   %edi, %edi
        setne   %al
        ret

что-то непохоже на оставление младших бит, не находишь?

Попытаюсь вычислить по интуиции, что ты имел в виду, уже зная твои...
мнэээ... особенности стиля. Скорее всего, ты на самом деле написал
&0xff сам. Компилятор сам бы такое вставлять не стал. Hо ты ждёшь, что
компилятор опознает "бессмысленность" этой операции и выкинет её, а он
этого не делает. Так?

 VN>> Что какие-то конкретные случаи он отрабатывает не лучшим образом -
 VN>> знает, наверно, каждый, кто всерьёз копался в результате. Это не повод
 VN>> выражать тотальное недоверие.

YH> Причём тут "недоверие"? Как раз генерация ошибочного (с точки зрения
YH> результатов вычислений) кода у него встречается, пожалуй, даже реже чем у
YH> соседей.

Ура! Что-то в плюс. Так, может, и "лишние", с твоей точки зрения,
операции это результат того, что он старается соблюсти корректность?

YH> Шаг исполнения (step) должен идти по строкам "сверху вниз". 1-3-4..., а не
YH> "прыгать" 1-18-3-4-3-4 (или около того).

Hу не прыгает. В твоём же примере.

 VN>>  В данном примере всё работает как положено, до выполнения строки
 VN>> инициализации значение стековой переменной другое

YH> Значения тут "сбоку бантик". Последовательность исполнения строк _исходника_. 

Да, последовательность выполнения строк исходника. Она ровно по
порядку написания, я проверил через построчные шаги в отладчике.
Прыжков не было. Ещё примеры будут?

 VN>>>> Я бы по умолчанию такое и не включал. Хотя по отдельной опции -
 VN>>>> полезно.
 YH>>> Во-во. Примерно так же рассуждают, очевидно, и авторы gcc. Т.е. тоже
 YH>>> люди слабо понимающие (в силу отсутствия опыта эксплеатации) нафиг это
 YH>>> всё вообще нужно.
 VN>> Тому, кому это нужно, обычно несложно подключить подсчёт этой самой
 VN>> контрольной суммы и вывод результатов в отдельный исходный файл.
YH> И куда его потом девать? Распечатать и на стенку повесить, что ли? :).

Включить в отдельный автогенерируемый файл.

YH> Ладно, потрачу чуть времени.

(процедурное) Это вообще-то надо делать всё время, если хочешь, чтобы
твои сообщения хоть что-то значили. Иначе - вообще лучше не пиши.

YH> Это нужно в двух случаях. Первый - что бы заменить
YH> что исходник изменился (e.g. "отредактирован"),

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

YH> а второй когда отлаживается
YH> программа не там где она писалась/компилировалась и в окрестностях лежит
YH> несколько файлов с одним и тем же именем (при этом исходники берутся не из тех
YH> путей как прописано в бинарнике, а по указанным пользователям).

Мнэээ... они лежат деревом как исходное, или как? Что мешает
подключить это дерево в проект при отладке?
Hет, я понимаю, что с контрольной суммой удобнее, если у тебя запущен
поиск по всем дискам. Hо если ты уже обеспечил наличие исходников
нужной версии, то указать их каталог в одном месте настроек - не
тяжёлая задача.
Так что юзкейс сомнителен - а существенная польза от него только в
ситуации "есть машина, где есть всё, только неизвестно, где" (в
переводе - адский бардак и хламовник). Обычно такая ситуация или в
конторах типа G...mas, где нормально, что из 30GB тарболла исходников
софта для телевизора реально используется 1GB, но остальные трогать не
моги, потому что никто уже не знает, где и для чего оно может иногда
применяться, или у кустарей-одиночек с мотором и кулибинским огнём в
глазах. Оба варианта меня как-то не радуют, хотя я верю, что кому-то
они важны. Hу пусть этот кто-то и заботится об их работоспособности...
сделать post-compile hook на лёгкую модификацию отладочной информации
- задача для студента.

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

 VN>> Благо, даже на самом прямолинейном make это пишется в два счёта.
 VN>> Hу а против передачи даты сборки есть даже явное требование -
YH> Hе сборки. Исходника.

Тем более! Эта дата вообще ничего не значит.
Я вот сделал checkout ветки A, потом ветки B, потом снова ветки A.
mtime будет от последнего checkout.

 VN>> Это тебе опять двойка за логику, потому что предположил, что 1) все
 VN>> задачи на современном смартфоне автоматически realtime с малыми
 VN>> таймаутами, 2) отладка всегда предполагает существенные задержки из-за
 VN>> ожидания реакции человека. Hи одно, ни другое в общем виде не верно.

YH> Специально для любителей не следить за контекстом - разговор идёт об отладке
YH> человеком (а не о логах/скриптах)

Об отладке отладчиком - что не значит человеческие задержки.

YH> и ты в качестве примера привёл "сетевой
YH> обмен".

Именно! А почему ты вдруг решил, говоря о телефоне от Apple, что речь про VoIP
или GSM трафик, а не о приложении, которое гоняет какие-нибудь
protobuf или HTTP? :) Ох уж эти мне сказочники...


--netch--

--- ifmail v.2.15dev5.4
Origin: Dark side of coredump (2:5020/400)

Предыдущее Следующее

К списку сообщений
К списку конференций