Здравствуйте, Sinclair, Вы писали:

V>>Чтобы "отформатировать диск"? (С)
S>Для того, чтобы угрозы проверять. Напомню, речь идёт о софте, выявляющем трояны.

Ну и вот, выявляет трояны байт-код, сам этот байт-код битый, его нельзя исполнять — вдруг это атака?
Правильней будет завершить работу машины до разбирательств.


S>Основное преимущество управляемого кода — как раз возможность изолировать ошибки.

Да ложь это.
Проверка индекса при доступе к массивам — это фича конкретного объекта, а не среды исполнения.
Запросто в опкодах получай ссылку на данные и лезь по произвольному индексу, гадя в произвольную память, бгг...

Что там еще?
Проверка на null перед вызовом метода объекта?
Это и вовсе фича компилятора конкретного языка, который подставляет callvirt вместо call.

В общем, опять и снова ты пытаешься наделить любимый свой класс технологий тем, чем они не обладают или что как минимум перпендикулярно любым технологиями — что байт-кодным VM, что нет.
Да запросто дотнетная байт-машинка и по памяти проходится, и прочие все классы ошибок осуществляет, и нихрена это никак и ничем не "управляется", даром что MS зафорсила этот новый мем. ))

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

А исследовательский проект управляемой ОС окончился ничем, напомню.
Потому что не оттуда и не туда копали, я тебе когда-то объяснял — копать надо было в сторону зависимых типов.
Безопасность будущих программ кроется именно там, а не в байт-коде или нейтивном.
Это вообще условности. ))


V>>Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки?
S>

ЧТД, ты сам об этом сам не подумал, поэтому ответить тебе нечего.
Плюс ранее в подветке рассуждал о необходимости некоего особого режима для подгружаемого для исполнения кода.
Я на то нубство даже не ответил (и не акцентировал внимание читателей), а зря, получается. ))
Ведь и обычные нейтивные модули тоже "подгружаемые", бгг...


V>>А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой.
S>По-хорошему, байт-код нужно верифицировать, но кто ж знает, что у них там за байт-код. Это ж какая-то самодеятельность.

Да не верифицируется он нигде и никогда даже в случае не самодеятельности. ))
Даже взять самый первый барьер — абсолютно все более-менее полезные дотнетные приложухи имеют унутре unsafe-код.

А после появления в лимбах объекта-хелпера Unsafe теперь и этого не требюуется — абсоютно все проходы по управляемой или неуправляемой памяти можно выполнять в честном safe-режиме.

Либа эта УЖЕ стала мега-популярной что в коде базовых библиотек, что в прикладном коде, бо позволяет эффективно оперировать данными...
При этом, надёжность кода получается как в С++, только хуже — потому что деструкторы не всегда автоматически вызываются, бгг...
И потому что using-переменная value-типа вдругш становиться immetable, и все её начинают через Unsafe приводить к мутабельной ссылке и издеваться над ней.

Да кароч, в 2024-м с этим глобальным враньём можно было бы уже и закончить. ))


V>>(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию)
S>"Сотни постов". Ага. Стоило один раз упомянуть, как у vdimas порвался пукан, и нас накрыло коричневой волной.

Не один раз, ты тут несколько раз высказался.
Просто ты не в первый раз высказался.
И просто схема всегда одна и та же — ты тупо гонишь, не разобравшись.


V>>Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси.
S>Ну, то есть вы так до сих пор и не поняли, что никакой ереси я там не нёс

Еще как нёс ересь. ))
Отборнейшую, махровую.
Почитай себя там до моего появления в топике, бгг..

Ты ведь не вникал, как компиляторы обслуживают потенциальные UB?
Не вникал в ретроспективу развития кода компиляторов?

Ты просто придумал себе удобное объяснение, что компилятор — это некий "черный ящик", по мощности сопоставимый с облачными ИИ, и примерно с этих позиций пытался то "объяснить" его поведение "он просто распознал UB" в обсужденриях с другим колегой (чего-чего? ), то, наоборот, ты возмущался тем, что конкретно твой кейз не был распознан.
Нифига себе ожидания...
Пипец махровое нудство. ))

А на деле происходит обратное — компилятор предполагает, что никакого UB нет.
И у него есть такое право — из-за допущения расширения типов промежуточных значений.
Код с volatile я тебе показал сугубо для демонстрации того, как компилятор трассирует точки вычисления.
Что тут может быть непонятно — я уже просто теряюсь.

Ну ты реально тогда считаешь компилятор "черным ящиком", и на этом основании мысленно приписываешь ему любые магические св-ва. ))


S>зато вот над вашими постами смеются примерно все, кто понимает устройство компилятора?

Пытался твой собеседник, который тоже наговорил кучу ереси там.
Я не выбирал кого пороть — сишника или дотнетчика, оба там хороши были. ))

И о каком "понимании устройства" ты сейчас говоришь?
На уровне Ахо+Ульмана? Вирта? Хантера?

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

Но зато позволяешь себе приёмы "вы, наверно, ничего не понимаете" лишь на том основании, что человек с тобой не согласен.
А я вижу, что ты просто не в состоянии даже понять аргументов, которые тебе приводят.
Но сам ты своих технических аргументов не приводишь, каждый божий раз пытаешься рассуждать о некоей эзотерике для посвящённых.
А кто, типа, наркотикк не вкурил, тому провидение не откроется.
За такие вещи вообще стоило бы пороть, бгг...


V>>И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений.
S>Ну вот, вы продолжаете позориться.

Это ты продолжаешь не понимать работу компилятора, продолжаешь считать его "чёрным ящиком" с непонятными св-вами.
А там простые if-else, бгг.
Код открыт, иди изучай.


S>Понятно, почему не хотите в форуме название работодателя светить — вдруг коллеги вас поиском случайно найдут, ржать будут годами.

Коллеги мои тут регулярно бывают и ты с некоторыми из них регулярно спорил и так же был не раз прилюбдно выпорот, пока на тебя не забили еще лет 15 назад.

Ну реально, не был бы настолько нервозно-плодовит в некрасивых своих рассуждениях, что технических, что политических — на плевать на какого-то там фрика, хосподя.
Но у тебя определённым образом подвешен язык — присутствует талант врать, манипулировать, играть на публику, качать эмоции и т.д.

В общем, как вредитель ты весьма талантлив, этого не отнять.

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


S>За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.

Ты про плавучку? ))
Наивный — эту оговорку уже делал еще тогда.

А чтобы что-то там "понимать", недостаточно надувать щёки.
Надо просто расписать по шагам хотя бы поверхностно алгоритм, каким руководствуется компилятор в той ситуации.

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

Но ты этого не сделал.
Вместо этого у тебя есть некие убеждения, источники которых отсутствуют в природе, бо это синтез порывов твоей души, есть еще упёрство, с которым ты отстаиваешь милые сердцу убеждения, и сверху этого ноль совести, что позволяет тебе быть манипулировать беседой как угодно, работая на читателя.

Не зря же ты регулярно пытаешься опереться на публику — "да это не только я говорил".
Второму там тоже от меня досталось, не переживай. ))
Да хоть сотня вас таких бестолковых будет, тем забавней ситуация, хосподя...


V>>Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах.
S>Во-первых, типизация промежуточных значений происходит задолго до того, как появятся какие-то регистры. Так что продемонстрированные вами расширения — это уже фаза кодогенерации, на этом этапе компилятор все семантические оптимизации давно применил.

Т.е. ты не знал, что есть фаза оптимизации при конечной кодогенерации?
И что эта фаза чуть ли не основная по эффективности сегодня?
Семантические, это, надо понимать, альфа-дета и эта-преобразования? ))

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

А твои "семантические оптимизации" выполняются лишь на стадии генерации объектного кода.


S>Во-вторых, осталось показать, как это работает для суммы двух int256. Куда она там будет расширяться, и почему компилятор позволяет себе выбрасывать код для этого случая безо всякой оглядки на регистры.

__int256 пока что не стандартный тип, тикетов и багов в компиляторах, его поддерживающих, пока хватает.
Вот когда все компиляторы подтянутся, тогда этот тип войдёт в стандарт, а пока что это попытка убежать. ))

Предположу, что пока что "тупо" использовали ту же ветку, что для других целых.


V>>Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах.
S>Впечатляющий пример глобального непонимания.
S>1. Не понимаете, что именно делает компилятор, и как он это делает, для конкретного случая.

ЧТД, вместо того, чтобы показать хотя бы схематично свои представления о логике происходящего, ты опять ударяешься в свою эзотерику "вы просто недостаточно просвещённые" ))
(и так каждый раз, бгг)


S>2. Не понимаете, как выводятся типы промежуточных результатов в арифметике C++. В частности, путаете integral promotions с signed overflow.

Если ты пытаешься утверждать, что эти вещи никак не связаны, то ты ошибаешься.
Впрочем, эту ошибку я тебе уже показывал схематично на C#. ))
А ты подтвердить свои рассуждения ничем не можешь, заметь, только позицией "А баба Яга против!"


S>3. Не понимаете причин, по которым компиляторы С++ делают именно так.

Но озвучить эти причины, показав хотя бы схематически рассуждения компилятора, ты не в состоянии, верно? ))


S>Заодно не понимаете последствий. В частности, отсюда ваши наивные заблуждения вида "ну вот я давно пишу такое на MSVC, и там всё хорошо".

Я уже лет 30 пишу одновременно для нескольких компиляторов/ОС/платформ.
Т.е. мой код должен исправно работать много где.

Причём, "тепличные" условия для этого случились лишь к концу нулевых, когда компиляторы GCC/ICC/MSVC стали более-менее одинаково понимать и глотать код, а до этого мне приходилось обыгрывать разночтения многих компиляторов, а до конца нулевых еще и многих платформ.

Да, часть используемых когда-то платформ окончательно отсохла вместе с уникальными для них компиляторами, например SPARC, PowerPC и куча тонкостей сверху от различного endianless-представления.

В общем, тебе опять саечку за попытку манипуляции вместо рассуждений по-существу.


S>4. Не понимаете закономерностей развития индустрии, отсюда ваши прогнозы про внедрение UB в дотнете.

Тут речь не о "понимании" (реально задолбал своими впадениями в эзотерику), а о "ванговании".

Я внимательно наблюдаю развитие компиляторов примерно с 92-го года, когда впервые в жизни нашёл баг компилятора в Borland C++ 3.1 и стал тщательно соотносить генерируемый ассемблерный код с исходником все годы затем. И не только на плюсах, ес-но, бо в те года плюсы были для многих задач далеко не самым удобным инструментом. Например, VB генерил более эффективный код при обслуживании COM-объектов, а смарт-поинтеры в плюсах, автоматизирующие время их жизни, спамили ненужными парными AddRef/Release.
По Паскалю и объектной его версии аналогично.

И делал так все годы, благо все 90-е много упражнялся ассемблером в работе.
В том числе использовал Си в микроконтроллерах и все годы, увы, приходилось контроллировать генерируемый компиляторами код.
И в дотнете тоже, ес-но.
И до сих пор та же привычка, бгг...

Эта привычка помогла обнаружить и зарепортить кучу вещей в дотнете, один в GCC (оказался дубликат, но я изобрел обходной путь, бо нам ПРИШЛОСЬ еще много лет поддерживать ту версию GCC-компилятора, бо было много клиентов на RHEL/CentOS 6.x, даже когда уже вышли версии 8.x)

В общем, со мной эта твоя бестолковая болтовня, оперирующая лишь эмоциями и субъективными твоими ожиданиями от технологий приведёт лишь к ответной такой болтовне. ))

Или четко по шагам обсуждать происходящее в техническом плане, или будешь выпорот за каждый косяк в логике спора/аргументации и в целом стрёмных своих манер, бгг...

Например, я увидел достаточно много оптимизаций в 8-м дотнете до написания того своего поста.
Это всё резко отличалось от виденного ранее в течении 24 лет дотнетной истории (ага, я слежу за дотнетом с его беты).

За оптимизацию взялись весьма агрессивно, примерно как за оптимизацию плюсов в 92-93-х годах, что с тех пор его компиляторы ушли далеко в отрыв от других технологий в деле оптимизации.

Почти все трюки применяемых оптимизаций тщательно расписаны для свободно-распространяемых компиляторов: GCC, LLVM.
Так же достаточно много инфы даёт MS по своему компилятору, хотя резко меньше указанных.
ICC меньше остальных, плюс грешил развилками в коде — перенаправлял в высокооптимизированные ветки для интел-процов, и в малооптимизированные для того же AMD.

Ну и плюс, десятки компиляторов С/С++ с тех пор постепенно сдохли, что позволило сосредоточиться на небольшом их множестве и примерно увидеть происходящее.

Так вот, с каждым новым трюком росли требования к самому коду, чтобы этот трюк вообще стал возможным.

Более того, в обсуждениях находятся еще достаточно трюков, введение которых сейчас банально невозможно на текущей кодовой базе.

Теперь про дотнет.
Основной аргумент я тогда же и приводил — ради генерирования нейтивного бинарника и обрезки целевого образа УЖЕ отказались от половины всех свойств дотнета — от рефлексии везде и всюду.

Вот тут просто поверь на слово — никогда в истории С++ не было настолько резких изменений оптимизации ради.

Так что даёт тебе уверенность утверждать, что более никаких резких телодвижений в дотнете не будет?

Ну вот взять твой динамический кодогенератор — он ведь заведомо не работает в AOT.
А мои JSON-конфигурации в AOT прекрасно читаются, потому что Рослин! ))

Я бы мог на твой манер сформулировать "сдаётся мне, что не понимает кто-то другой", если бы речь шла о техническом понимании.
Но тут требуется понимание целей и мотивов.
Причём, эти цели и мотивы нифига не скрываются.
Просто ты пытаешься игнорировать даже то, чем тебе MS натурально под нос уже тыкает.
ты ведь до сих пор на стадии отрицания, а местами заплываешь в стадию гнева, но потом берёшь себя в руки — и опять возвращаешься на первую стадию.
Это малодушие.

Здравствуйте, Sinclair, Вы писали:

V>>Чтобы "отформатировать диск"? (С)
S>Для того, чтобы угрозы проверять. Напомню, речь идёт о софте, выявляющем трояны.

Ну и вот, выявляет трояны байт-код, сам этот байт-код битый, его нельзя исполнять — вдруг это атака?
Правильней будет завершить работу машины до разбирательств.


S>Основное преимущество управляемого кода — как раз возможность изолировать ошибки.

Да ложь это.
Проверка индекса при доступе к массивам — это фича конкретного объекта, а не среды исполнения.
Запросто в опкодах получай ссылку на данные и лезь по произвольному индексу, гадя в произвольную память, бгг...

Что там еще?
Проверка на null перед вызовом метода объекта?
Это и вовсе фича компилятора конкретного языка, который подставляет callvirt вместо call.

В общем, опять и снова ты пытаешься наделить любимый свой класс технологий тем, чем они не обладают или что как минимум перпендикулярно любым технологиями — что байт-кодным VM, что нет.
Да запросто дотнетная байт-машинка и по памяти проходится, и прочие все классы ошибок осуществляет, и нихрена это никак и ничем не "управляется", даром что MS зафорсила этот новый мем. ))

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

А исследовательский проект управляемой ОС окончился ничем, напомню.
Потому что не оттуда и не туда копали, я тебе когда-то объяснял — копать надо было в сторону зависимых типов.
Безопасность будущих программ кроется именно там, а не в байт-коде или нейтивном.
Это вообще условности. ))


V>>Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки?
S>

ЧТД, ты сам об этом сам не подумал, поэтому ответить тебе нечего.
Плюс ранее в подветке рассуждал о необходимости некоего особого режима для подгружаемого для исполнения кода.
Я на то нубство даже не ответил (и не акцентировал внимание читателей), а зря, получается. ))
Ведь и обычные нейтивные модули тоже "подгружаемые", бгг...


V>>А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой.
S>По-хорошему, байт-код нужно верифицировать, но кто ж знает, что у них там за байт-код. Это ж какая-то самодеятельность.

Да не верифицируется он нигде и никогда даже в случае не самодеятельности. ))
Даже взять самый первый барьер — абсолютно все более-менее полезные дотнетные приложухи имеют унутре unsafe-код.

А после появления в либах объекта-хелпера Unsafe теперь и этого не требюуется — абсоютно все проходы по управляемой или неуправляемой памяти можно выполнять в честном safe-режиме.

Либа эта УЖЕ стала мега-популярной что в коде базовых библиотек, что в прикладном коде, бо позволяет эффективно оперировать данными...
При этом, надёжность кода получается как в С++, только хуже — потому что деструкторы не всегда автоматически вызываются, бгг...
И потому что using-переменная value-типа вдруг становиться immutable, и все её начинают через Unsafe приводить к мутабельной ссылке и издеваться над ней.

Да кароч, в 2024-м с этим глобальным враньём можно было бы уже и закончить. ))


V>>(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию)
S>"Сотни постов". Ага. Стоило один раз упомянуть, как у vdimas порвался пукан, и нас накрыло коричневой волной.

Не один раз, ты тут несколько раз высказался.
Просто ты не в первый раз высказался.
И просто схема всегда одна и та же — ты тупо гонишь, не разобравшись.


V>>Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси.
S>Ну, то есть вы так до сих пор и не поняли, что никакой ереси я там не нёс

Еще как нёс ересь. ))
Отборнейшую, махровую.
Почитай себя там до моего появления в топике, бгг..

Ты ведь не вникал, как компиляторы обслуживают потенциальные UB?
Не вникал в ретроспективу развития кода компиляторов?

Ты просто придумал себе удобное объяснение, что компилятор — это некий "черный ящик", по мощности сопоставимый с облачными ИИ, и примерно с этих позиций пытался то "объяснить" его поведение "он просто распознал UB" в обсужденриях с другим колегой (чего-чего? ), то, наоборот, ты возмущался тем, что конкретно твой кейз не был распознан.
Нифига себе ожидания...
Пипец махровое нудство. ))

А на деле происходит обратное — компилятор предполагает, что никакого UB нет.
И у него есть такое право — из-за допущения расширения типов промежуточных значений.
Код с volatile я тебе показал сугубо для демонстрации того, как компилятор трассирует точки вычисления.
Что тут может быть непонятно — я уже просто теряюсь.

Ну ты реально тогда считаешь компилятор "черным ящиком", и на этом основании мысленно приписываешь ему любые магические св-ва. ))


S>зато вот над вашими постами смеются примерно все, кто понимает устройство компилятора?

Пытался твой собеседник, который тоже наговорил кучу ереси там.
Я не выбирал кого пороть — сишника или дотнетчика, оба там хороши были. ))

И о каком "понимании устройства" ты сейчас говоришь?
На уровне Ахо+Ульмана? Вирта? Хантера?

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

Но зато позволяешь себе приёмы "вы, наверно, ничего не понимаете" лишь на том основании, что человек с тобой не согласен.
А я вижу, что ты просто не в состоянии даже понять аргументов, которые тебе приводят.
Но сам ты своих технических аргументов не приводишь, каждый божий раз пытаешься рассуждать о некоей эзотерике для посвящённых.
А кто, типа, наркотикк не вкурил, тому провидение не откроется.
За такие вещи вообще стоило бы пороть, бгг...


V>>И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений.
S>Ну вот, вы продолжаете позориться.

Это ты продолжаешь не понимать работу компилятора, продолжаешь считать его "чёрным ящиком" с непонятными св-вами.
А там простые if-else, бгг.
Код открыт, иди изучай.


S>Понятно, почему не хотите в форуме название работодателя светить — вдруг коллеги вас поиском случайно найдут, ржать будут годами.

Коллеги мои тут регулярно бывают и ты с некоторыми из них регулярно спорил и так же был не раз прилюбдно выпорот, пока на тебя не забили еще лет 15 назад.

Ну реально, не был бы настолько нервозно-плодовит в некрасивых своих рассуждениях, что технических, что политических — на плевать на какого-то там фрика, хосподя.
Но у тебя определённым образом подвешен язык — присутствует талант врать, манипулировать, играть на публику, качать эмоции и т.д.

В общем, как вредитель ты весьма талантлив, этого не отнять.

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


S>За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.

Ты про плавучку? ))
Наивный — эту оговорку уже делал еще тогда.

А чтобы что-то там "понимать", недостаточно надувать щёки.
Надо просто расписать по шагам хотя бы поверхностно алгоритм, каким руководствуется компилятор в той ситуации.

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

Но ты этого не сделал.
Вместо этого у тебя есть некие убеждения, источники которых отсутствуют в природе, бо это синтез порывов твоей души, есть еще упёрство, с которым ты отстаиваешь милые сердцу убеждения, и сверху этого ноль совести, что позволяет тебе быть манипулировать беседой как угодно, работая на читателя.

Не зря же ты регулярно пытаешься опереться на публику — "да это не только я говорил".
Второму там тоже от меня досталось, не переживай. ))
Да хоть сотня вас таких бестолковых будет, тем забавней ситуация, хосподя...


V>>Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах.
S>Во-первых, типизация промежуточных значений происходит задолго до того, как появятся какие-то регистры. Так что продемонстрированные вами расширения — это уже фаза кодогенерации, на этом этапе компилятор все семантические оптимизации давно применил.

Т.е. ты не знал, что есть фаза оптимизации при конечной кодогенерации?
И что эта фаза чуть ли не основная по эффективности сегодня?
Семантические, это, надо понимать, альфа-дета и эта-преобразования? ))

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

А твои "семантические оптимизации" выполняются лишь на стадии генерации объектного кода.


S>Во-вторых, осталось показать, как это работает для суммы двух int256. Куда она там будет расширяться, и почему компилятор позволяет себе выбрасывать код для этого случая безо всякой оглядки на регистры.

__int256 пока что не стандартный тип, тикетов и багов в компиляторах, его поддерживающих, пока хватает.
Вот когда все компиляторы подтянутся, тогда этот тип войдёт в стандарт, а пока что это попытка убежать. ))

Предположу, что пока что "тупо" использовали ту же ветку, что для других целых.


V>>Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах.
S>Впечатляющий пример глобального непонимания.
S>1. Не понимаете, что именно делает компилятор, и как он это делает, для конкретного случая.

ЧТД, вместо того, чтобы показать хотя бы схематично свои представления о логике происходящего, ты опять ударяешься в свою эзотерику "вы просто недостаточно просвещённые" ))
(и так каждый раз, бгг)


S>2. Не понимаете, как выводятся типы промежуточных результатов в арифметике C++. В частности, путаете integral promotions с signed overflow.

Если ты пытаешься утверждать, что эти вещи никак не связаны, то ты ошибаешься.
Впрочем, эту ошибку я тебе уже показывал схематично на C#. ))
А ты подтвердить свои рассуждения ничем не можешь, заметь, только позицией "А баба Яга против!"


S>3. Не понимаете причин, по которым компиляторы С++ делают именно так.

Но озвучить эти причины, показав хотя бы схематически рассуждения компилятора, ты не в состоянии, верно? ))


S>Заодно не понимаете последствий. В частности, отсюда ваши наивные заблуждения вида "ну вот я давно пишу такое на MSVC, и там всё хорошо".

Я уже лет 30 пишу одновременно для нескольких компиляторов/ОС/платформ.
Т.е. мой код должен исправно работать много где.

Причём, "тепличные" условия для этого случились лишь к концу нулевых, когда компиляторы GCC/ICC/MSVC стали более-менее одинаково понимать и глотать код, а до этого мне приходилось обыгрывать разночтения многих компиляторов, а до конца нулевых еще и многих платформ.

Да, часть используемых когда-то платформ окончательно отсохла вместе с уникальными для них компиляторами, например SPARC, PowerPC и куча тонкостей сверху от различного endianless-представления.

В общем, тебе опять саечку за попытку манипуляции вместо рассуждений по-существу.


S>4. Не понимаете закономерностей развития индустрии, отсюда ваши прогнозы про внедрение UB в дотнете.

Тут речь не о "понимании" (реально задолбал своими впадениями в эзотерику), а о "ванговании".

Я внимательно наблюдаю развитие компиляторов примерно с 92-го года, когда впервые в жизни нашёл баг компилятора в Borland C++ 3.1 и стал тщательно соотносить генерируемый ассемблерный код с исходником все годы затем. И не только на плюсах, ес-но, бо в те года плюсы были для многих задач далеко не самым удобным инструментом. Например, VB генерил более эффективный код при обслуживании COM-объектов, а смарт-поинтеры в плюсах, автоматизирующие время их жизни, спамили ненужными парными AddRef/Release.
По Паскалю и объектной его версии аналогично.

И делал так все годы, благо все 90-е много упражнялся ассемблером в работе.
В том числе использовал Си в микроконтроллерах и все годы, увы, приходилось контроллировать генерируемый компиляторами код.
И в дотнете тоже, ес-но.
И до сих пор та же привычка, бгг...

Эта привычка помогла обнаружить и зарепортить кучу вещей в дотнете, один в GCC (оказался дубликат, но я изобрел обходной путь, бо нам ПРИШЛОСЬ еще много лет поддерживать ту версию GCC-компилятора, бо было много клиентов на RHEL/CentOS 6.x, даже когда уже вышли версии 8.x)

В общем, со мной эта твоя бестолковая болтовня, оперирующая лишь эмоциями и субъективными твоими ожиданиями от технологий приведёт лишь к ответной такой болтовне. ))

Или четко по шагам обсуждать происходящее в техническом плане, или будешь выпорот за каждый косяк в логике спора/аргументации и в целом стрёмных своих манер, бгг...

Например, я увидел достаточно много оптимизаций в 8-м дотнете до написания того своего поста.
Это всё резко отличалось от виденного ранее в течении 24 лет дотнетной истории (ага, я слежу за дотнетом с его беты).

За оптимизацию взялись весьма агрессивно, примерно как за оптимизацию плюсов в 92-93-х годах, что с тех пор его компиляторы ушли далеко в отрыв от других технологий в деле оптимизации.

Почти все трюки применяемых оптимизаций тщательно расписаны для свободно-распространяемых компиляторов: GCC, LLVM.
Так же достаточно много инфы даёт MS по своему компилятору, хотя резко меньше указанных.
ICC меньше остальных, плюс грешил развилками в коде — перенаправлял в высокооптимизированные ветки для интел-процов, и в малооптимизированные для того же AMD.

Ну и плюс, десятки компиляторов С/С++ с тех пор постепенно сдохли, что позволило сосредоточиться на небольшом их множестве и примерно увидеть происходящее.

Так вот, с каждым новым трюком росли требования к самому коду, чтобы этот трюк вообще стал возможным.

Более того, в обсуждениях находятся еще достаточно трюков, введение которых сейчас банально невозможно на текущей кодовой базе.

Теперь про дотнет.
Основной аргумент я тогда же и приводил — ради генерирования нейтивного бинарника и обрезки целевого образа УЖЕ отказались от половины всех свойств дотнета — от рефлексии везде и всюду.

Вот тут просто поверь на слово — никогда в истории С++ не было настолько резких изменений оптимизации ради.

Так что даёт тебе уверенность утверждать, что более никаких резких телодвижений в дотнете не будет?

Ну вот взять твой динамический кодогенератор — он ведь заведомо не работает в AOT.
А мои JSON-конфигурации в AOT прекрасно читаются, потому что Рослин! ))

Я бы мог на твой манер сформулировать "сдаётся мне, что не понимает кто-то другой", если бы речь шла о техническом понимании.
Но тут требуется понимание целей и мотивов.
Причём, эти цели и мотивы нифига не скрываются.
Просто ты пытаешься игнорировать даже то, чем тебе MS натурально под нос уже тыкает.
ты ведь до сих пор на стадии отрицания, а местами заплываешь в стадию гнева, но потом берёшь себя в руки — и опять возвращаешься на первую стадию.
Это малодушие.