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

Это были извинения за то, что такой вопрос задаю. Вопрос:

Есть дизассемблированный код, в нём:
len - integer
pNonSpace, pStart - указатели pChar




Ну и далее там что-то, не важно.

Собственно вопрос:
Какие должны быть операнды  в
   sub  exc,[ebp-$0c]
чтобы после неё взвёлся флаг OF ?

Я думал, что оба операнда, например, должны быть больше MaxInt, но почему-то нет.
Или exc (оно же pNonSpace) должно быть больше MaxInt, а вычитаемое (т.е. pStart) должно быть меньше MaxInt?

(ну я предполагаю, что указатели - эти беззнаковый величины же и поэтому могут быть больше, чем знаковый Int)

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

По моему вопросу: нужен вариант номер 2, т.е. чтобы pNonSpace было более MaxInt, а pStart - менее MaxInt

ну к примеру в ECX $80000000 а в памяти по адресу [EBP - $C] значение $7FFFFFFF

Я, признаться, никак не могу сообразить логику выставления этого флага.
Ну разве что он применим (осмысленен) сугубо для signed int типов, а для unsigned int смысла не имеет?

( друзья, я в общем-то в теме и осознаю, что для процессора нет разницы между signed и unsigned типами, и что это лишь вопрос трактовки; но именно трактовку и "бизнес смысл" и пытаюсь понять)

123-124 не выставляется?

> Ну разве что он применим (осмысленен) сугубо для signed
> int типов, а для unsigned int смысла не имеет?

Процессор не знает о том что за число (SIGNED/UNSIGNED) поэтому это возлагается на компилятор, который генерирует различные инструкции условного перехода при работе с такими типами.

К примеру

var
 A, B: DWORD;
...
   if A < B then

Здесь будет использоваться инструкция JBE в которой задействованы флаги CF и ZF, а вот для такого случая:

var
 A, B: Integer;
...
   if A < B then

Будет использоваться инструкция JLE где прыжок осуществляется уже по совокупности флагов ZF, SZ и OF

А флаги будут выставляться всегда.

> Inovet ©   (04.02.16 15:50) [6]
> 123-124 не выставляется?

нет конечно

Если есть желание разобраться по какому принципу выставляются флаги - то вот пример (сори на сях - но там все очень просто): http://rouse.drkb.ru/tmp/cmp.zip

ЗЫ: в vmCMP8() происходит вычитание второго числа из первого - как раз искомый SUB

> [8] Rouse_ ©   (04.02.16 15:55)

Полез проверять.

> Inovet ©   (04.02.16 16:07) [11]

Ты точно про OF флаг говоришь?
Этот код не выставляет OF флаг.

> [12] Rouse_ ©   (04.02.16 16:13)
> Ты точно про OF флаг говоришь?

Блин, а я ж про CF думал.:)

А всё же, логика выставления OF флага?

> Inovet ©   (04.02.16 16:18) [13]
> > [12] Rouse_ ©   (04.02.16 16:13)
> > Ты точно про OF флаг говоришь?
>
> Блин, а я ж про CF думал.:)

Угу я даж ролик успел снять, подумал мошт у меня крыша поехала :)
http://rouse.drkb.ru/tmp/1.mp4

> KSergey ©   (04.02.16 16:20) [14]
> А всё же, логика выставления OF флага?

так она простая:




т.е. смотрим старшие биты у обоих чисел (это SIGN бит и смотрим SF флаг, который выставляется от операции сложения первого и инвертированного второго числа).

Грубо говоря этим мы проверяем - происходил ли переход через $80000000 (перенос бита в более старший разряд)

> [16] Rouse_ ©   (04.02.16 16:26)
> так она простая

Для интереса в Вики посмотрел - есть там!
https://ru.wikipedia.org/wiki/%D0%A4%D0%BB%D0%B0%D0%B3_%D0%BF%D0%B5%D1%80%D0%B5%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F

Давай попробую по другому, вот смотри пример от Inovet
От числа 123 отнимает 124.
Отнимать будем через сложение, т.е. выразим как оба этих числа (в 16 ричной) как
7B (123)
и FFFFFF84 (минус 124)

сложим их - получим результат = $FFFFFFFF т.е. число минус 1 - которое полностью укладывается в диапазон 32 бит.

Теперь берем пой пример:
первое число $80000000
второе $7FFFFFFF

второе инвертируем: оно становится равно $80000001

складываем - на выходе число: $100000001 - а вот оно уже в 32 бита не влезет, самый старшая единичка находится в 33-ем бите - оть это и есть переполнение.

Так понятно?

> А всё же, логика выставления OF флага?

Флаг OF взводится если результат не влазит в размеры операнда. Операнд для этого флага трактуется как знаковый.
SInt8 = от -128 до 127
К примеру
SUB (-128), 1
Результат -129 не влазит в SInt8 следовательно возводится OF.
SUB 1, -127
Результат 128 не влазит в SInt8 следовательно возводится OF.


function SUB8(a,b:UInt8):UInt16;
begin
Result:=a-b;
_ZF:=Ord(Result=0);
_SF:=(Result  shr 7)  and 1;
_PF:=PF_Table[Result and $FF];
_OF:= (((a xor b) and (a xor result)) shr 7)and 1;
_CF:=(Result  shr 8) and 1;

_AF:=((a xor b xor result) shr 4) and 1;
end;

> Pavia ©   (04.02.16 16:43) [19]

Что за PF_Table, покажи плз

А все - не надо, собственно сам по быстрому построил :)

Я уже не помню что там к чему.

for i:=0 to 255 do
PF_Table[i]:=1 and (1 xor i xor (i shr 1) xor (i shr 2) xor (i shr 3)
               xor (i shr 4) xor (i shr 5) xor (i shr 6) xor (i shr 7));

Parity флаг - четное кол-во включенных бит в младшем байте (True/False).

> Rouse_ ©   (04.02.16 16:36) [18]

Да, мне всё понятно. Спасибо.

> Pavia ©   (04.02.16 16:43) [19]

И вам тоже спасибо!

Обращайся :)

Да и кстати, по поводу мануалов: http://www.intel.ru/content/www/ru/ru/processors/architectures-software-developer-manuals.html

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

Как-то я не отписался о сути. Проблема разобрана, хоть от этого и не легче.

Оказалась совершенно неожиданная мерзопакость в D5 в том, что вот в таком коде



при включенной опции компилятора "Check inneger overflow" компилятор после выражения pNonSpace - pStart впендюривает проверку на переполнение Int'а.
Причем не зависимо от типа переменной len: хоть Integer, хоть Cardinal. И даже если +1 убрать.

И как только получается так, что pNonSpace указывает на адрес за границей 2 Гб, а  pStart указывает на адрес до 2 Гб (при этом разница может быть и совсем небольшой) - получаем EIntegerOverflow на этой строке.

Кто догадался такую проверку вставить для указателей - не знаю.

А так?
len := Integer(pNonSpace - pStart + 1);

Не, соврал:

var
  len: DWORD;
  pStart, pNonSpace: PAnsiChar;
begin
 try
   pStart := Pointer($7FFFFFFF);
   pNonSpace := pStart + $FFFFFF;
  len := DWORD(pNonSpace) - DWORD(pStart) + 1;

Вот а логика простая, это можно увидеть из асм кода - изначально PChar кастится к Integer (так всегда было), стало быть использует при проверке OF флаг в частности генерацией JNO инструкции.
Нужно всего лишь объяснить компилеру что у нас тут переполнения по SIGN-биту нет, сделав каст любому устраивающему нас UNSIGNED типу (DWORD/Cardinal/ULong и т.п.)

В этом случае компилер сгенерирует JNB инструкцию, и все решиться нормально.

> Rouse_ ©   (07.04.16 16:36) [30]
> сделав каст любому устраивающему нас UNSIGNED типу (DWORD/Cardinal/ULong и т.п.)

Это да.
Но скажите мне: кто в борланде решил, что поинтер в Win32 - знаковый?!
Я понимаю, что в ту пору (примерно Windows 95, я думаю) про достижение 2Гб памяти и подумать никто не мог (к вопросу о странном развитии техники), но всё же теория-то была изложена, а теория - она про 4Гб (и 32-х битные указатели) сразу была!

Ну и потом: в своём коде я, конечно, могу переписать, но есть и "не мой" код, весь не перепроверишь.

Интересно, в текущих версиях дельфи - так же?

Ну смотри в 32 битых ты оперируешь памятью до 7fffffff - вылезешь за нее будет больно.
Логично? Да еще как

> Rouse_ ©   (07.04.16 19:37) [32]
> Ну смотри в 32 битых ты оперируешь памятью до 7fffffff

Это почему?! почему на ваш взгляд  8-й проводок в старшем байте не может принять состояние логической единицы? чем он такой особенный?
я не понимаю.

> [33] KSergey ©   (07.04.16 19:47)
> Это почему?! почему на ваш взгляд  8-й проводок в старшем
> байте не может принять состояние логической единицы?

В Майкрософт тоже когда-то сложился знаковый тип? Ну как бы - вот вам половина, а остальное не трожьте.:)

Для win 95-98 это ещё имело смысл. А вот в других ОС нет никакого смысла.

> Ну смотри в 32 битых ты оперируешь памятью до 7fffffff -
>  вылезешь за нее будет больно.


Не всегда

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

> Rouse_ ©   (07.04.16 16:36) [30]
>
> Вот а логика простая, это можно увидеть из асм кода - изначально
> PChar кастится к Integer (так всегда было)

Ну вот а нафига так всегда было? :)

Сереж, я ж уже объяснил, блин (че как дети прям, книжки не читаете) - 4 гига виртульной памяти дели на лапопам, первая твоя, вторая ядра.

> Сереж, я ж уже объяснил, блин (че как дети прям, книжки
> не читаете) - 4 гига виртульной памяти дели на лапопам,
> первая твоя, вторая ядра.

Так у вас логика не правильная. Ядро отображалось в адресный процесс приложения для того что-бы приложение могло адресовать к ядру. Иначе нет смысла. К примеру чтение значение таймера. Поэтому ваша логика не верна.

> Rouse_ ©   (08.04.16 00:38) [37]
> Впрочем Игорь правильно меня поправил - можно расширить
> диапазон адресации, но как это обьяснить компилеру?

А не надо ему объяснять, адресация - она все 4 Гб памяти должна быть, по-моему. Ну раз ОС мне физически даёт туда доступ - почему компилятор это ограничивает? ("кто он вообще такой?!")

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

> доступ - почему компилятор это ограничивает? ("кто он вообще
> такой?!")

D2 первый 32 битный компилятор создавался на Win98.
В Win98 все лазили выше 2Гб и поэтому она постоянно висла. небыло защиты от записи.
Если бы разработчики D2 не заприметили это то отладка стала бы кошмаром.

*заприметили -> запретили

> Pavia ©   (08.04.16 06:31) [40]
> Так у вас логика не правильная. Ядро отображалось в адресный
> процесс приложения для того что-бы приложение могло адресовать
> к ядру. Иначе нет смысла. К примеру чтение значение таймера.

Та шо ты такое говоришь, отображение значения таймера ядром в процесс идет по фиксированному адресу в виде структуры KE_USER_SHARED_DATA.
Показываю.
http://rouse.drkb.ru/tmp/1.gif

> KSergey ©   (08.04.16 08:16) [41]
> А не надо ему объяснять, адресация - она все 4 Гб памяти
> должна быть, по-моему. Ну раз ОС мне физически даёт туда
> доступ - почему компилятор это ограничивает? ("кто он вообще
> такой?!")

Туда будет доступ если приложение собранного с использованием флага IMAGE_FILE_LARGE_ADDRESS_AWARE, указанного в FILE_HEADER.
По умолчанию данный флаг отключен и лимит для 32 бит именно $7FFFFFFF

Rouse, отстаиваемая вами позиция понятна, но мир уже как бэ изменился и очень сильно.
Я ведь на с потолка придумал проблему, она в жизни имеет место быть, к сожалению. (Менеджер памяти подменён, да)

Pavia ©   (08.04.16 08:50) [42]


> D2 первый 32 битный компилятор создавался на Win98.
> В Win98 все лазили выше 2Гб и поэтому она постоянно висла.
>  небыло защиты от записи.


Это какой-то феерический трындец.

У меня к тебе огромная просьба - не пиши пожалуйста на форум, не оскорбляй мои религиозные чувства.

> KSergey ©   (08.04.16 10:22) [46]
> Rouse, отстаиваемая вами позиция понятна, но мир уже как
> бэ изменился и очень сильно.

Это не позиция - это знания, подкрепленные как аргументами, так и фактами :)

KSergey,
> почему компилятор это ограничивает?
сами просили "Check integer overflow" !

> но мир уже как бэ изменился и очень сильно.
ого, а проблема где проявилась:
на x32, x32+3G, x64 ?

> Та шо ты такое говоришь, отображение значения таймера ядром
> в процесс идет по фиксированному адресу в виде структуры
> KE_USER_SHARED_DATA.Показываю.

Так я говорю про то что было в 98 году. И то что сейчас оно совершенно по другому. И уже не требуется приложениям лазить в ядро.

Открою великую тайну - приложение даже в 95-98 годах в ядро не лезло, ну это так, для общего понимания

> Rouse_ ©   (08.04.16 02:02) [39]
>
> Сереж, я ж уже объяснил, блин (че как дети прям, книжки
> не читаете)

Сань, какие именно глупые книжки нужно читать?  :)
При чём тут "лампомпам" и приведение указателя к знаковому целому?
<OFFTOP>
Вот уже второй раз за последнее время ты мне "объясняешь" логику компилятора, а я эту логику  второй раз никак понять не могу. :(
</OFFTOP>

Сдаюсь, на днюхе персонально тебе на бумашке нарисую :)

> Rouse_ ©   (09.04.16 01:36) [53]
>
> Сдаюсь, на днюхе персонально тебе на бумашке нарисую :)
>  

Сомневаюсь я однако, что "на днюхе" найдётся для этого время. :)

> [50] Pavia ©   (08.04.16 20:18)
> И уже не требуется приложениям лазить в ядро.

Одно удовольствие читать твои посты:) - так (я) и курить (табак) бросить. Пиши исчё.

> Но скажите мне: кто в борланде решил, что поинтер в Win32
> - знаковый?!


http://docwiki.embarcadero.com/RADStudio/XE8/en/Pointers_and_Pointer_Types_(Delphi)

Указатель беззнаковый тип (что вобщем-то разумно). Но с указателями недопустимы арифметические операции (если справку почитать). А если ты все-таки выполняешь эти операции, то компилятор приводит их к типу Integer, что тоже разумно.

Ни с какой адресацией памяти это не связано, просто совпадение.

> Игорь Шевченко ©   (10.04.16 10:37) [56]
> Но с указателями недопустимы арифметические операции (если справку  почитать)

Да они издеваются!

в дополнение к [56] надо отметить, что для работы с указателями, как с целыми числами лучше использовать тип UIntPtr/IntPtr ну или NativeUInt, иначе могут возникнуть проблемы на 64 битных версиях программы.

Я так и не понял, был ли дан ответ: The SUB instruction performs integer subtraction. It evaluates the result for both signed and unsigned integer operands and sets the OF and CF flags to indicate an overflow in the signed or unsigned result, respectively. The SF flag indicates the sign of the signed result.

Проще говоря, OF показывает, было ли переполнение, если операнды рассматриваются как SIGNED. Например, для байта (-100) SUB (100) возникает переполение для SIGNED (-200 не помещается в байт). Для UNSIGNED переполнения нет (156) - (100) = 56, поэтому CF сброшен. Другой возможный случай, напримкр, когда (100) SUB (-100), тут тоже переполнение для SIGNED (200 не помещается в байт), и для UNSIGNED тоже (100) SUB (156) больше нуля.

> Игорь Шевченко ©   (10.04.16 10:37) [56]
> Указатель беззнаковый тип (что вобщем-то разумно). Но с
> указателями недопустимы арифметические операции (если справку
> почитать). А если ты все-таки выполняешь эти операции, то
> компилятор приводит их к типу Integer, что тоже разумно.
>  
>
> Ни с какой адресацией памяти это не связано, просто совпадение.
>

Хм, ну странно конечно, но я как раз в какой-то из статей именно про эту адресацию и арифметические операции и читал (дабы не уплыло все, как говорится).
Попробую найти - не склероз же у меня.

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

> [61] Rouse_ ©   (11.04.16 16:28)
> сложения/вычитания/умножения

Не ну в Си, например, если я ничё не забыл, чётко определено сложение/вычитание с целым результат указатель, разность двух указателей результат целое, А умножение тут каким боком прикрутить?

mov eax, [eax + edx * 4] к примеру

> [63] Rouse_ ©   (11.04.16 18:49)
> mov eax, [eax + edx * 4] к примеру

Так здесь не указатель умножается, а индекс.

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

Руки им за это оторвать.

KSergey ©   (12.04.16 08:59) [65]

Never attribute to malice which can be adequately explained by stupidity.

Спасибо, (погуглив) узнал много нового.