Здравствуйте, Евгений Музыченко, Вы писали:
N>>Где это у нас автоматический перенос программ?
ЕМ>В винде. 
32-разрядная программ автоматически идет под 64-разрядной виндой в той же линейной модели, а 16-разрядная идет под 32-разрядной в искусственно создаваемой 16-разрядной модели.
Ну вот ты сам себе и ответил, что та 16-битная была уже искусственно созданной. В случае же 32/64 это тоже намеренно оставленный переходник. Могли и не оставлять, но тогда переключение между legacy и long (в их терминах) было бы сильно дороже.
А в исходниках ты тем более так легко не сделаешь.
N>>A0000-BFFFF видеопамять всех видов
N>>C0000-DFFFF область расширителей
N>>E0000-FFFFF BIOS (да, занимал сильно больше 64KB, начиная ещё с AT)
ЕМ>Это все устаканивалось почти десяток лет, а изначально выбор границы в 640 кб был практически произвольным.
Да. А теперь обрати внимание, что первые PC могли иметь вообще 16KB памяти. Даже меньше одного сегмента. Это самая дешёвая конфигурация. А память тогда (1981) стоила 8.8$/kB, то есть 64 обходилось бы в 560$ тогдашних (а для теперешних надо умножить на 5-7).
Итого посчитай по нынешнему: 2800$/64KB. 28000$/640KB.
Никто такой памяти не ставил до середины 80-х, и то только самые толстые.
Вот примерно с 1986-87 стало возможно заполнить эти 640 полностью для большинства, когда цена реально драматически упала (1986 это 300$/MB, 1987 уже 150 — о таком прогрессе сейчас можно только тоскливо мечтать).
Конечно, сидя в СССР за занавесом мы с тобой эту историю пропустили. И теперь тебе кажется, что эта граница могла быть достигнута с самого начала.
А тогда думали иначе. При том, что архитектуры более широкого плана были известны давно, про 386-й с момента его выхода (1985) знал каждый в теме, это не считалось проблемой. Кому мало этой памяти — идите в расширители и в 32 бита.
Вот почему окончательный переход с реального режима и MS-DOS застрял фактически лет на 10 (когда с Win95 стали забывать про DOS), вот это действительно серьёзный повод обсудить. То ли расчёты прогресса оказались поспешными, то ли авторы софта застыли в кривой позе и потеряли время непонятно на чём. Ну Microsoft экспериментировал с Xenix, это да. NT они начали рисовать году в 87, судя по первым копирайтам.
Тут я бы послушал, какие грабли и где были расставлены. У кого есть ссылки с хорошим описанием, поделитесь.
EM> В итоге, как известно, в одних машинах было множество неиспользуемых дыр в АП, а в других все служебное не влезало в 384 кб, и приходилось переключать.
Я согласен с тем, что область видеопамяти надо было бы переместить повыше, тогда мы бы упёрлись не в 640, а в 768K или даже выше (если взять видеорежим попроще). Тут недоработали. Но опять же со взглядом из 1981 считалось, что прежде чем упёрлись бы в этот предел, архитектура поменялась бы так, что он перестал бы быть важным.
Кстати, ещё один момент тут — Intel при проектировании 286 мог сделать, что эти области мапятся в верхний предел адресного пространства. Это было сделано ещё в PDP-11: 16-битные адреса с 0b111 вначале получали для обеих размерностей (18 и 22 бита) все старшие единицы, если выключен DAT. Но Intel как всегда протупил на ровном месте, и мы получили проблему в виде legacy 1MB блока.
N>>Ну да, с запасом.
ЕМ>Да, выбранным практически наугад.
А тогда и невозможно было иначе. Что оно составило больше половины адресного пространства — уже было успехом для последующей работы. Могли и 256KB ограничиться, а дальнейшее позанимать на разные разности. Может, это было бы и лучше в том плане, что переход на следующую разрядность прошёл бы более ровным путём.
N>>Вот я и пытаюсь понять, где у тебя граница между "ряд основных" и "подавляющее большинство остальных".
ЕМ>Логика предельно проста, она такая же, как и в программировании: если конкретная величина заранее неизвестна, то она оформляется в виде переменной. Если затраты на работу с переменной чрезмерно велики, то для оптимизации используются приемы вроде констант или макросов. Если константа самоочевидна (единица как минимальное натуральное число, двойка как основание двоичной системы и т.п.), то нет смысла вводить переменные или константы One/Two.
Спроецируем на IBM PC. Если я тебя понял правильно, то пока мы не можем ничего сделать с 20-битной адресацией, нам нужно было бы сделать какую-то ячейку в, как было принято, BIOS data area с указанием, где сидит видеопамять (так как это у нас основная граница). Пусть в первых версиях она сидела от 0xA0000. Но пришло время ужаться — убрали неиспользуемый кусок в ROM extension area и в extended BIOS и посадили память, например, 0xE8000. В результате имеем уже не 640KB, а 928KB. Так?
И тогда я скажу в третий, наверно, раз за этот комментарий, что когда шёл стремительный прогресс (быстрее того 2 раза за 1.5-2 года что по закону Мура), эффект типа "в 2 раза" никого не интересовал, цикл от идеи до внедрения это 3-5 лет и потому эффект нужен такой, чтобы давал минимум 16 раз, а лучше 256. Вот переход на 24 бита адреса в 286 и 32 в 386 это сила, а 928 вместо 640 это ни о чём. И таки я очень рекомендую вернуться к вопросу, почему MS-DOS с реальным режимом умерли не в 1985, а в 1995 ("умерли" тут в смысле "перестали вкладываться новые силы в разработку под них с нуля").
N>>когда стало _легко_ делать вариабельные адреса, то это стали делать.
ЕМ>Когда было тяжело сделать один вариабельный адрес на всю систему?
Какой именно из? Их там несколько.
N>>не из какого-то упрямства, а в порядке поиска границ. Ты сам допускаешь, что какие-то значения должны быть константными. Но чётких критериев разграничения не дал.
ЕМ>Это границы разумного.
Вот и вопрос в согласовании понятия "разумное", при условии, что ты, похоже, не понимаешь, в какой обстановке всё это происходило. И нет, я не про политику.
N>>Чему они могли бы быть равны?
ЕМ>Конкретным объемам, доступным в данной системе. Во времена, когда 2 Гб стало не хватать уже много кому, объем всего ядра не превышал нескольких десятков мегабайт. Соответственно, M было бы равно 3.9 Гб, а N — 0.1 Гб. 3.9 Гб для прикладных процессов, за совершенно ничтожную цену.
И снова упускаешь две вещи.
1) Это ещё период заметного роста свойств, хоть и не такой безумный, как в 80-х. Приложения, которым не хватает 2GB, но хватает 3.9GB, очень редки — это узкая полоса. Большинству или достаточно меньше (99+%), или не хватает уже 4GB (1-%). Основное направление развития уже давно это переход на 64 бита, причём Windows на x86 в этом смысле глубокая отсталая провинция. Юниксы начали переходить ещё в 90-х, у нас была машинка на Alpha в 1999. MIPS64 появился в 1999, ну нам не достался SystemZ — это 2000. Когда там первая Windows на amd64? 2005?
2) Вся архитектура ядер оптимизирована на случай, когда всю оперативную память плюс адресное пространство ввода-вывода можно полностью отобразить на ту часть общего адресного пространства, что отведена ядру. В случае 2+2 и оперативной памяти до 1.5GB это выполняется. В случае, например, 4GB RAM уже нет. При 3+1, 3.5+0.5 — тоже нет. При невыполнении этого главного условия начинаются частые переключения страниц и перегонки между ними. В Linux явно ругались на это, что надо вводить так называемые bounce buffers. Затраты времени на эти операции. И зачем оно такое для менее 1% пользователей, если при переходе на 64 это снова не будет нужно?
Повторюсь, ты тут один-к-одному провинциал из села, который не видел выше двухэтажного дома, начинаешь рассказывать, как строить пятиэтажные тем, кто только что закончил квартал как минимум 9- и 16-этажных, а в планах следующий на 25. Сконцентрировавшись на Windows, ты тут пропустил, где в этом плане шёл прогресс задолго до.
N>>Вот потому и делали 2:2, 3:1 и для особых извращенцев — 3.5:0.5
ЕМ>А могли бы сразу добавить один конфигурационный параметр для границы, и избежать частных случаев навсегда.
Не нужно. См. выше.
N>>расскажи, в чём именно непродуманность.
ЕМ>В упор не понимаю, что еще нужно рассказать. Но есть отчетливое впечатление, что Вы упорно косите под дурачка.
Спасибо. Я не буду столь же интенсивен в плане личных качеств, но см. выше про провинциала. Проблемы, которые кажутся вам критичными, не являлись такими для большинства или по крайней мере не планировались такими.
[skip аналогии, которые пошли не туда и не актуальны вообще]
N>>Я всё-таки не вижу, где эти ограничения были бы настолько неоправданны, что заставили бы страдать индустрию без причины на длительный срок.
ЕМ>Ну, раз никто не страдал по поводу нехватки сперва 640 кб, потом двух гигабайт, а затем трех, то надо признать, что XMS/EMS, PAE и тому подобное создавались, внедрялись и переделывались из чистого энтузиазма, без малейшей производственной надобности.
Нет, это уже демагогия с вашей стороны. А вот на что рекомендую обратить внимание по каждой этой технологии, это во сколько раз они расширяли возможности.
N>>как только упирались в них, достаточно быстро находился вариант решить проблему переходом за следующий порог, который при этом был в разы дальше.
ЕМ>То есть, классика: сперва создаем проблему, затем героически ее решаем.
"Героически" было только по причине неоправданной задержки с MS-DOS, и я уже в 4-й раз вынужден сказать, что именно её продлённое существование тут является ключом и вопросом на полезное обсуждение (хотя бы в историческом плане).
Даже задержка создания общедоступной 64-битной Windows, по сравнению с Linux, NetBSD и прочими, которые к моменту выхода amd64 в железе были полностью готовы — не насколько интересна и существенна.
N>>чтобы без порога вообще — такого не бывало, потому что мы в реальном мире.
ЕМ>Реальность мира диктует только размер переменной для хранения границы доступного АП: в 32-разрядных системах — четыре байта, в 64-разрядных — восемь.
И снова не учитываете, что действия типа "а сейчас мы забабахаем все 64 бита на физический адрес!" приведут просто к тому, что подорожавший на 20% продукт не выиграет соревнования с конкурентами.
