> Сереж, я ж уже объяснил, блин (че как дети прям, книжки
> не читаете) - 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) больше нуля.