@MSGID: 2:5000/14 642805dc
@REPLY: 2:5020/848.23 6426a613
@CHRS: CP866 2
@TZUTC: 0200
Привет!

31 Mar 23 12:21, you wrote to me:

 YH> как ты их нынче подписываешь?

 Пока никак. :) Уже созрел для смены юрисдикции (я последние годы во
Франции, но виза "без права работы", определения этого понятия нигде нет, но
зарегистрироваться, как ИП, нельзя, даже если все доходы из-за границы). :)

 YH> сколько я помню сетями ты не занимался? Вот и попробуй найди в
 YH> документации отличия при написании фильтр-драйвера между ndis4 и ndis5
 YH> :)

 Плотно я действительно не занимался, но как раз сетевой драйвер под
NDIS как-то делал. Hо по фильтрам вообще у MS было традиционно мало
информации - как и Kernel Streaming. Типа, раз задача нестандартная, то и
ищите сами. :)

 YH> Указать-то можно, но если использовать те самые sln, то там какой-то
 YH> вариант прописан как дефолтный.

 В sln (точнее, в vcproj/vcxproj и vsprops/props) почти никогда не
бывает такого, чтоб разные конфигурации использовали разные библиотеки -
только режимы компиляции сборки. Так-то можно наделать конфигураций для
разных библиотек, но двухуровневая иерархия (платформа/конфигурация) для этого
неудобна. Так что почти везде одни и те же версии, одни и те же пути,
кроме платформенно-зависимых.

 YH> А создаётся он (всякими VS) именно под "текущую". Hе систему, а среду,
 YH> но была бы разница. Ты не путай "голый" makefile (или вообще батник :)
 YH> с тем что делает нынешняя гуйня.

 Так и VS при создании проекта никогда не кладет туда конкретных
путей, а только определяет кучу переменных среды, причем в ранних версиях
это были только path/include/lib, а в каждой последующей добавлялись
новые, так что менять логику сборки гораздо проще. Hу и главное - эта
среда не имеет никакого отношения к системе, в которой установлена. Какие
компоненты поставишь - с теми и будет собираться. А в линуксе чаще всего
принципиально невозможно сконфигурировать систему так, чтобы собрать по умолчанию, а
потом запустить в другой.

 YH> "Локальная оптимизация" (у у всех x86-компиляторов) работает
 YH> исключительно на файловом уровне. А все эти #pragma optimize применимы
 YH> (увы) разве что для откючения ошибок оптимизатора :(

 Hе знаю, на чем ее используешь ты, а я ее очень давно и активно
использую для отдельных функций, с неизменно превосходным результатом. :) В том
числе и для многоуровневых инлайнов. Если там и есть какие-то ошибки
оптимизации, то на логику и вычисления они никак не влияют.

 YH> покажи 1 (один) пример когда при cl tst.c (сиречь -Od) и без
 YH> __forceinline у тебя что-то инлайнится.

 Hе покажу, ибо действительно не инлайнится. Я ж объяснял, что у
меня -Od соседствует с -Ob1, а -O2 - с -Ob2. А от тебя я хотел пример
кода, в котором бы сам по себе инлайн (без прочей оптимизации) как-то
влиял на распределение памяти в стеке.

 YH> Ты что, до сих пор vc6 используешь?

 Основным у меня cl 15.x в VS 2008, ибо от более поздних студий
блевать тянет тем сильнее, чем они позднее. :) Hо 19.x использую тоже - в
частности, для сборки под arm64, ну и для проверок всяких.

 YH> Og уже лет 15 как deprecated и (реально) ни на что не влияет.

 Hу-ну. :) Сунь -Og вместе с -Od в командную строку 19.x - получишь
предупреждение о deprecation, и вместе с ним - кое-какие оптимизации, в том числе
распределения памяти в стеке. Сунь -Og- вместе с -O2 - получишь оптимизацию кода
без оптимизации стека. :) И обрати внимание на "function compile flags"
в ассемблерном листинге.

Вот пример, если интересно:

#include 

void xf (char *);

void f () {

  {
    char aa [10000];
    memset (aa, `a`, sizeof (aa));
    xf (aa);
  }

  {
    char aa [20000];
    memset (aa, `b`, sizeof (aa));
    xf (aa);
  }

  {
    char aa [30000];
    memset (aa, `c`, sizeof (aa));
    xf (aa);
  }

}

 А еще я только сейчас обнаружил, что логика оптимизации там
несколько странная. В этом примере, с -O2 ты получишь выделение в стеке 30000
байтов на три перекрывающихся массива, а с -O2 -Og- - 60000 на
неперекрывающиеся области. Hо, если вместо вызова внешней функции с каждым из
массивов, заведешь в функции переменную, и в каждом блоке будешь что-то
довычислять в нее (хоть прибавлять значение нулевого элемента), то массивы всегда
останутся неперекрывающимися, независимо от режимов оптимизации.

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

 Hе знаю, зачем они так делают - при анализе дампа, о котором ты
говорил, состояние объекта, для которого в блоке была вызвана функция, может
потребоваться с той же вероятностью, что и при использовании для вычислений сугубо
внутри функции.

Всего доброго!
Евгений Музыченко
fi-do@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20180707
 * Origin: Fox Tracks, France (2:5000/14)
SEEN-BY: 50/12 400/814 452/28 166 455/19 4500/1
5000/14 5020/400 545 848 1042
SEEN-BY: 5020/1477 1823 4441 12000 5022/128 5025/3
75 5030/1081 1957 2404
SEEN-BY: 5035/85 5053/400 5054/1 5059/26 37 5066/18
5080/68 102 5085/13
SEEN-BY: 5095/20
@PATH: 5000/14 5020/545 4441