Про 286 плохо помню, а про 386 хорошо.
В Real Mode, т.е. изначально при старте, действительно сегмент 64к.
А вот в Protected Mode уже или 1М или 4Г.
К слову, в 386 были недокументированные команды, позволяющие изменить дескриптор сегмента в RealMode.
Т.е., например, увеличить сегмент до 1м.

Slavnich При старте чего? Он постоянно 64КБ и другого его размера нет.
В защищённом режиме нет сегмента. Там как раз идёт уход к линейной адресации.
Коллега, ты бредишь. Сегмент только 64К и не больше. Это определяется самой природой адреса. Я уж не говорю о проблематичности использования каких-либо недокументированных команд и их последствий на языках, отличных от ассемблера.

Недокументированные команды существуют, другое дело что ничего страшного они не делали. (просто были не задокументированы так как не особо были нужны)

Э-э... Рекомендуется почитать мануалы, прежде чем спорить. Защищённый режим и модель памяти (адресация) - это несколько разные вещи. В защищённом режиме может быть любая адресация, как с сегментами (32 или 16 разрядными), так и flat модель.
По поводу flat в реальном режиме - поиск по ключу "unreal mode". Никаких недокументированных команд нет, есть недокументированная особенность x86-32 процессоров. Даже игры под DOS по-моему делали для этого режима.

Билли Бонс

unreal mode - жестокий хак и в принципе работать не обязан. Хотя все уже привыкли, что работает
Slavnich

наверное, страницы, которые бывают или 4KB, или 4MB? а размер сегмента я могу определить КАКОЙ я хочу.

Root Я уточнил терминологию. Недокументированная команда или недокументированная особенность архитектуры?

Билли Бонс
ну, когда у первых вариантов процессоров пентиум 2*2 не равнялось 4.0, а 3.99999, то сказали, что это ошибка. А тут считается, что это особенность архитектуры. Непорядочек...

Уж не знаю, на сколько ты мне коллега.

И так, 386 - не только первый 32-битный проц, но еще и первый проц аппаратно ПОЛНОСТЬЮ поддерживает мультизадачность. Что-то я в сторону ушел, сорри..
В защ. режиме 386-го регистры базы - CS, DS, ES,FS,SS - это не базовые адреса сегментов памяти.
Это индексы дескрипторов сегментов в таблицах дескрипторов, глобальной либо локальной - GDT, LDT.
Дескриптор - 64-битный описатель сегмента памяти. Т.е. тип сегмента (кодовый, данных, стек), базовый адрес,
размер и еще всяко разно.
Под размер выделено 20 бит, т.е. 1М. Это в том случае, если не используется механизм страничной адресации.
Страница - 4к. При страничной адресации размер сегмента может быть 1м 4-килобайтных страниц = 4Г.

Vladson А я с этим спорил? Речь была совсем не о том. Читай внимательно цитату, на которую ты отвечаешь.
А я утверждал, что делали?

Билли Бонс Могу в ответ рекомендовать подумать, прежде чем спорить. Мануал я давно не читал, нужды в этом нет - ну не работаю давно с подобными вещами. Но зачем переходить в защищённый режим, который позволяет работать с линейным адресом и продолжать работать с сегментами? Каков в этом смысл?
Про недокументированные команды писал не я. Поэтому ответ не по адресу. Но недокументированные команды, насколько помню, существовали в некоторых процессорах.
Что касается unreal mode, то писать программу для этого режима имеет смысл, если твой компилятор поддерживает его. Как я писал выше - нет смысла в командах или режимах, если ты не можешь под них писать программу. Какие компиляторы поддерживали генерацию кода для этого режима? Ассемблер не предлагать.

Root Это если пользоваться форматом с плавающей точкой. Для точных расчётов рекомендуется использовать формат с фиксированной точкой. Там этот глюк отсутствует.

Slavnich

Slavnich писал(а):

Уж не знаю, на сколько ты мне коллега.

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

Затем например, что процессоры, начиная с PII, поддерживают 36-разрядную шину адреса, а в режиме линейной адресации 32-разрядный адрес (т.к. регистры 32-битные), и чтобы использовать память выше 4Гб, придётся пользоваться сегментами.
Watcom C++ вроде поддерживал, впрочем я unreal не юзал, поэтому точно не скажу.

Билли Бонс Опять же надо иметь средства разработки, поддерживающие выбор этих режимов, настройку сегментов и генерацию машинного кода в зависимости от выбранного метода адресации. Я не в курсе, такие есть?
С компиляторами Watcom не сталкивался.

IgLowy По идее должен подойти любой 32-битный компилятор, т.к. они все работают во flat режиме. Пишется входная точка на ассемблере, в которой процессор переводится в unreal mode и передаётся управление программе на ЯВУ. Работа в unreal mode полностью совпадает с линейной адресацией в защищённом режиме, поэтому никакие дополнительные ухищрения не нужны. Единственное, где они могут потребоваться, - это обращение к функциям DOS, но написать небольшой враппер на асме труда большого не составляет.

Билли Бонс Не уверен, что для любого языка можно написать входную точку на ассемблере. И не уверен, что после этого твоя программа будет вообще работать. Реализация функций и операторов для сегментной адресации и линейной разная. Поэтому все функции работы с памятью придётся модифицировать для работы в этом режиме. Разве нет?
Писать дополнительный код на асме для высокоуровневых языков тоже не всегда удобно, даже когда реализуемо. Попробуй сделать всё это для тех же Clippera, FoxPro или Clarion. В том же Clarion присутствует для каждого режима свой комплект библиотек: 16 бит, защищённый режим 32 бит. Думаю, что для защищённого режима с сегментацией придётся писать новый комплект библиотек.

IgLowy Ну дык, я же и говорю, что компилятор должен поддерживать flat режим. Входная точка абсолютно без проблем пишется на ассемблере. ЯВУ компилируется в объектник, также как и асм, и всё это линкуется. Ничего сложного. Возможно при работе стандартных аллокаторов памяти и будут какие-нибудь грабли, но опять же выделение памяти - это очень небольшой фрагмент программы. Всякие там кларионы и пр. - это не ко мне. А на C++ я всё это реализую без проблем.

Билли Бонс Flat режим он поддерживает. Но ты же предлагаешь не его, а реализовать работу с сегментами в защищённом режиме. На режиме адресации стоится всё выделение памяти. И не надо говорить, что это небольшой фрагиент программы. Он может по самому коду небольшой, но без него не будет работать ни одна функция работы с создаваемыми во время работы программы объектами. А в высокоуровневых языках этот код "зашит" в библиотеки. И его не переписать.
А все эти Кларионы строятся на базе того же Си. В Кларионе вообще линкер одинаковый для всех используемых языков: Кларион, С++, Модула, ассм. Линкуй хоть до посинения. Что с библиотеками делать?
И на С++ тебе придётся делать тоже самое. И проблемы будут.
Может на искуственно созданном примере ты и легко это реализуешь. А что будет при использовании достаточно больших библиотек для серьёзных задач?

ЫЫЫЫ... хочу!!!
Добавлено спустя 45 секунд
а интеловский на мамке - это скорее всего 16ти мегагерцовый - таких аж два есть

IgLowy
Я говорю об unreal mode, а ты о чём? С сегментами в защищённом режиме я работать не предлагаю, просто уточнил, что это возможно, а иногда может быть необходимо.

З.Ы. И для "серьёзных" задач, разумеется, использовать недокументированные возможности не стоит. Unreal mode использовался в играх, где все библиотеки создавались самими разработчиками.

З.З.Ы. Про "небольшой фрагмент". Я неплохо себе представляю то, о чём говорю. В C++, например, не составляет большого труда использовать нестандартный аллокатор памяти, есть множество библиотек, которые так и поступают с различными целями (для улучшения производительности, например). Реализовать свой аллокатор под любой режим адресации тоже не так трудно, как об этом думают.

Билли Бонс Я о защищённом режиме и смысле использовать в нём сегментную адресацию.
И придётся делать подмену стандартных функций alloc, malloc и т.д. на твои, чтобы все библиотеки её подхватили? А на чём основываются функции работы с масивами? Разве им не понадобиться тоже осуществлять аналогичную подмену?
Это называется - не составляет большого труда? Тут куча вопросов на тему - как это будет работать.
Да и одним С++ дело не ограничивается. Как быть с другими языками?
Сомневаюсь. Ты так и не ответил на вопрос - как поведут себя все уже написанные библиотеки в случае такой подмены. А без такого ответа нельзя дать ответ о простоте использования другой адресации.

IgLowy Что ты так привязался к уже написанным библиотекам? Ты знаешь что-нибудь об ООП, повторном использовании кода, шаблонах, в конце-концов? Ты знаешь, что в C++ можно перегружать операторы new и delete?
Я вот пишу сейчас для sparc, а отлаживаю под Windows (x86, разумеется). Код один и тот же, за исключением небольшого платформенно-зависимого куска, а различия в архитектуре систем намного больше чем между защищённым режимом и unreal или между реальным и unreal. Никакой кучи вопросов почему-то не возникает.
Если тебе очень нужна уже написанная библиотека, перекомпилируй её со своим новым аллокатором и всего делов.

З.Ы. Другие языки меня мало интересуют, да и не в языках дело.

Билли Бонс Да потому что без них толку от компилятора нет!!!
Знаю. А ты знаешь что-нибудь о других языках программирования или библиотеках не использующих ООП? Что и чем ты там будешь перегружать? И, как понимаю, ты предлагаешь для всех уже имеющихся классов написать новые инициализаторы и деструкторы? Типа, маленькая проблемка.
Всё зависит от того, что ты пишешь. Если речь идёт о математическом алгоритме, то это возможно. Но хотелось бы посмотреть, как ты код написанный под WinAPI запустишь в другой операционке. Интерфейсная часть любого ПО не столько процессорозависимая, сколько зависит от операционной системы.
У меня складывается впечатление, что ты плохо представляешь о чём ты говоришь. Ты учитываешь, что исходников библиотек у тебя нет? Потому что речь идёт о "стандартных" библиотеках, которые идут в комплекте с компилятором и средой разработки: работа с базой данных, построение интерфейса и т.д.
И в языках тоже. А то что другие языки тебя не интересуют, не значит, что все должны кинуться писать на C++ и перекомпилировать кучу кода. Я тебе сказал, что есть проблемы с использованием сегментации под защищённым режимом и проблемы действительно есть. Ты их не хочешь замечать, потому что ты с ними в своей работе не сталкивался. Но они есть.