Skip to main content

Конференции

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

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

Дата: 25 Sep 2016, 11:38:24
От: Yury Haron @ 2:5020/848.23
Кому: Valentin Nechayev
Тема: Вопрос по коду


Приветствую Вас Valentin!

24 Сен 16 в 12:17, Valentin Nechayev сообщал Yury Haron:

 VN>>> случае однокристалок. Конкретные названия и прямым текстом.
 YH>> 8051, 6880, etc.

 VN> Я бы и не рассматривал GCC в принципе для этих платформ, это совсем не
 VN> его целевая ниша, и любую критику на основании кодогенерации под всё
 VN> ниже условного класса PDP-11 считаю бессмысленной

Hапомниаю - эта "дискуссия" началась с моего утверждения о том, что компиляторы делаемые по принципу "каждой бочке затычка" (e.g. для многих разных платформ) генерят б/м равномерно-хреновый код для
любой из них.
Так что - этот твой аргумент к данному обсуждению не подходит.

 VN>>> превращается (здесь и далее GCC 4.8, -O1, -march=i686 для 32,
 VN>>> умолчание для 64)
 VN>>> g1:
 VN>>>         movzbl  4(%esp), %eax
 VN>>>         ret
 YH>> что (с точки зрения оптимизации) _ошибка_. Сравни времена mov и movzx.

 VN> Какой mov? Только в регистр al?

да

 VN> Документ Intel (R) 64 and IA-32 Architectures Optimization Reference
 VN> Manual (248966), версия 33:

[skip]

 VN> Или твои знания про MOVZX остались со времён 80386?

Hапиши тест (только не под *nix/win а для голого железа) узнаешь много нового и интересного о том стоит ли верить современной документации в подобных вопросах.

 YH>> Этот пример некорректен - он использует особенности cc, т.е. не
 YH>> отвечает ситуации о которой шла речь "результат в al" - он тут в edi.

 VN> Покажи корректный, с твоей точки зрения, пример. Исходный код, точная
 VN> версия компилятора, опции, желаемый и фактический выход. Иначе считаю
 VN> балаболом.

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

 VN> Hу, и где твой "and 0xff"?

Объясняю 1 раз - речь шла о том, что gcc _не умеет_ использовать байтовые регистры. А какая конкретно форма "последствий" это детали.

 YH>>>> Это нужно в двух случаях. Первый - что бы заменить
 YH>>>> что исходник изменился (e.g. "отредактирован"),
 VN>>> Решается описанным выше. С другой стороны, это нужно только для
 VN>>> быстрого контроля, но никак не для обеспечения целостности результата
 VN>>> сборки.
 YH>> Задача "проверки целостности результата" (даже если считать её
 YH>> осмысленной) какое отношение к отладке имеет, не пояснишь?
 VN> Ты ж сам захотел контрольные суммы видеть в _отладочной_ информации.
 VN> Вот и поясняй.

Т.е. ты так и не понял? Тогда это не ко мне.

 VN> Постоянно-то таскать зачем? Hу и на такой случай подключить поддерево
 VN> - обычно очень лёгкая задача.

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

 VN>  Иначе ты ждёшь, пока оно проиндексирует все файлы, а если не ждёшь,

Ты что-то путаешь. Отладчик не vcs и не db. Ему "индексировать файлы" без надобности.

 VN> А потом изменили что-то в заголовках, а .c остался неизменным, но
 VN> логика поменялась чуть более чем полностью.

Хорош уже деменстрировать полное незнание предмета, а? Разумеется эти самые csum/datime есть у _каждого_ исходного файла. Или ты думаешь, в отладочной информации не упромянуты хидера?

 VN>>> mtime будет от последнего checkout.
 YH>> Да, безусловно, она хуже csum. Hо она - в debuginfo появилась когда
 YH>> описанная тобой ситуация была малореальной (за отсутсвтием каналов
 YH>> связи :). И - в отсутсвтии csumm - она лучше чем ничего.
 VN> Hет, она только сбивает с толку.

С апломбом заявил человек никогда не работавший ни с тем ни с другим. :(
Ты как хочешь, а я тему считаю закрытой - времени на "метание бисера" жалко.

 Hа чем и прощаюсь,
    Юра.

--- (none)
Origin: АР словарь: software - придурковатый продукт (2:5020/848.23)

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

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