Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>Так для чего ей были константно заложены те два гига только под одно ядро?
S>>Чтобы я сейчас, через тридцать или сколько-там лет, мог запустить её с двумя гигами под ядро — примерно в 100 раз больше, чем исходно было задумано.
ЕМ>А сумеете внятно объяснить, как на эту возможность повлияла именно константность раскладки адресного пространства?
Эта конкретная константа, 2GB:2GB, просто не мешала этому использованию. В программах дофига констант, от которых требуется, чтобы они просто не были слишком плохи.
А константы.. они вполне соответствовала времени. Для DOS было достаточно 640 KB, а когда перестало быть достаточно, перестала существовать DOS, вместе с x86 реальным режимом. Так и для 32 бит достаточно, легко, и удобно сделать разделение 2:2 (и, на мой вкус, зря прикрутили 3:1). Старый софт, который уже не переписывается, всё ещё можно запустить, даже на физической машине, если нужно, но когда перестало быть достаточно 2 GB на процесс для нового софта, выкинули x86 вместе с 32-битным режимом, и всё новое, что могло бы сожрать больше 2 GB, написали на x64. На ближайшие десять лет x64 достаточно, и константа 8:8 TB или сколько там, вполне прекрасна.
А константность — это просто удобно. Кончилось поколение — кончилась константа, бери другую.
Re[16]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Sharowarsheg, Вы писали:
S>В программах дофига констант, от которых требуется, чтобы они просто не были слишком плохи.
Ну вот конкретно в Ваших программах, какими константами задаются адрес и максимальный размер кучи, адреса загрузки системных DLL и т.п.?
S>Для DOS было достаточно 640 KB, а когда перестало быть достаточно, перестала существовать DOS, вместе с x86 реальным режимом.
Это Вы уже все прочно забыли. HiMem/Emm386 появились в самом начале 90-х, и не от хорошей жизни. Иногда только эти 100-200 дополнительных килобайт и позволяли запустить софт, который иначе никак в память не помещался.
S>Так и для 32 бит достаточно, легко, и удобно сделать разделение 2:2
А зачем именно 2:2, а не m:n?
S>Старый софт, который уже не переписывается, всё ещё можно запустить, даже на физической машине, если нужно, но когда перестало быть достаточно 2 GB на процесс для нового софта, выкинули x86 вместе с 32-битным режимом, и всё новое, что могло бы сожрать больше 2 GB, написали на x64.
И это тоже наблюдения из мира розовых пони. Майкрософту бы нафиг не сдалось переделывать 2:2 в 3:1, если бы не массовое давление со стороны юзеров винды, в том числе жирных корпораций. А давили потому, что слишком большое количество софта просто некому было взять и переписать с 32 на 64. А еще потому, что в изрядном количестве софта разрядность указателя тоже явно или неявно используется, как константа, поэтому простая перекомпиляция не катит, а разбираться — нужны ресурсы. А еще под 64-разрядные 2k3 и XP, доля которых была очень мала на фоне 32-разрядных XP/2k, очень долго не было драйверов, кроме самых необходимых, и ситуация начала выправляться лишь после середины 2000-х, с выходом унифицированной 32/64-разрядной висты.
S>На ближайшие десять лет x64 достаточно, и константа 8:8 TB или сколько там, вполне прекрасна.
Ну да, один французский король тоже нечто подобное говаривал.
S>Кончилось поколение — кончилась константа, бери другую.
Хорошо, что математики, несколько сотен лет назад придумавшие заменять конкретные числа буквами, так не думали.
Re[17]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>В программах дофига констант, от которых требуется, чтобы они просто не были слишком плохи.
ЕМ>Ну вот конкретно в Ваших программах, какими константами задаются адрес и максимальный размер кучи, адреса загрузки системных DLL и т.п.?
Конкретно в моих адреса загрузки системных DLL не задаются, я же не пишу загрузчик системных DLL. Размеры массивов (битность индексов) — задаются константами 16, 21, 24, и 48 (в разных местах и применительно к разным сущностям, естественно).
S>>Для DOS было достаточно 640 KB, а когда перестало быть достаточно, перестала существовать DOS, вместе с x86 реальным режимом.
ЕМ>Это Вы уже все прочно забыли. HiMem/Emm386 появились в самом начале 90-х, и не от хорошей жизни. Иногда только эти 100-200 дополнительных килобайт и позволяли запустить софт, который иначе никак в память не помещался.
Не помню, чтобы что-то куда-то не помещалось. MultiEdit с дос навигатором помещались везде. Первое, что перестало помещаться, был DOOM, для которого сделали DOS4GW.
S>>Так и для 32 бит достаточно, легко, и удобно сделать разделение 2:2
ЕМ>А зачем именно 2:2, а не m:n?
Чтобы по старшему биту можно было узнать, это пользовательский указатель, или ядерный.
S>>Старый софт, который уже не переписывается, всё ещё можно запустить, даже на физической машине, если нужно, но когда перестало быть достаточно 2 GB на процесс для нового софта, выкинули x86 вместе с 32-битным режимом, и всё новое, что могло бы сожрать больше 2 GB, написали на x64.
ЕМ>И это тоже наблюдения из мира розовых пони. Майкрософту бы нафиг не сдалось переделывать 2:2 в 3:1, если бы не массовое давление со стороны юзеров винды, в том числе жирных корпораций.
У микрософта в то время было достаточно денег, чтобы купить все те "жирные" корпорации, а также купить пользователей и в рабство обратить. Это собственные микрософтовские программисты, которых тоже перфекционизм одолел, захотели сделать все константы настраиваемыми, и обосрали всю малину — и, конечно, вызвали тыщщи синих экранов.
S>>На ближайшие десять лет x64 достаточно, и константа 8:8 TB или сколько там, вполне прекрасна.
ЕМ>Ну да, один французский король тоже нечто подобное говаривал.
S>>Кончилось поколение — кончилась константа, бери другую.
ЕМ>Хорошо, что математики, несколько сотен лет назад придумавшие заменять конкретные числа буквами, так не думали.
Математики не в состоянии сделать ничего практического. Например, нельзя построить мост из одних букв, какая бы ни была математика. В какой-то момент придётся подставить вместо букв хотя бы длину и ширину цифрами.
Здравствуйте, Sharowarsheg, Вы писали:
S>Конкретно в моих адреса загрузки системных DLL не задаются, я же не пишу загрузчик системных DLL.
Это потому, что разработчики ОС избавили Вас от этой заботы, а могли бы полениться и потребовать предоставления адреса для загрузки каждой DLL.
S>Размеры массивов (битность индексов) — задаются константами 16, 21, 24, и 48 (в разных местах и применительно к разным сущностям, естественно).
А как Вы решаете, по какому конкретно адресу разместить первичный блок для кучи, по какому — следующий, и так далее?
S>Не помню, чтобы что-то куда-то не помещалось. MultiEdit с дос навигатором помещались везде. Первое, что перестало помещаться, был DOOM, для которого сделали DOS4GW.
Ну, у кого-то спектр используемых под досом программ исчерпывался ME, DN и DOOM, а кто-то работал с системами верстки, разработки софта, с САПРами и т.п., которые вместе со всеми потребными драйверами в 640 кб категорически не помещались.
S>Чтобы по старшему биту можно было узнать, это пользовательский указатель, или ядерный.
Какую объективную экономию ресурсов это дает? И почему бы тогда не пойти дальше, обеспечив по одному биту различение указателей кода и данных, выгружаемого и невыгружаемого пулов, и т.п.?
S>У микрософта в то время было достаточно денег, чтобы купить все те "жирные" корпорации, а также купить пользователей и в рабство обратить.
Во-первых, кто б им все это продал? Во-вторых, на чем бы они зарабатывали после покупки?
S>Это собственные микрософтовские программисты, которых тоже перфекционизм одолел, захотели сделать все константы настраиваемыми, и обосрали всю малину — и, конечно, вызвали тыщщи синих экранов.
И отсюда, конечно же, вывод: "нужно продолжать устанавливать константы наперед, а когда они начинают сдерживать — выбрасывать все старое и делать новое"?
S>Математики не в состоянии сделать ничего практического. Например, нельзя построить мост из одних букв, какая бы ни была математика. В какой-то момент придётся подставить вместо букв хотя бы длину и ширину цифрами.
А если бы математики не создали унифицированных методов расчета моста на основе переменных, и каждый новый мост приходилось бы обсчитывать с нуля, используя эмпирические константы, которые для одних случаев избыточны, а для других — недостаточны?
Re: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Затем в 32-разрядной винде было 2+2 Гб, которые героическими усилиями переделали в 3+1.
И очень зря. Не должен один процесс жрать больше 2 ГБ. А для 64-битных систем следует разбивать приложения на несколько процессов/библиотек.
ЕМ>или действительно есть серьезная необходимость изначально задавать эти адреса/размеры глобальными константами
Для стандартизации и хоть какого-то ограничения аппетитов быдлокодеров. Сейчас почти все ограничения сняли, и макаки пишут десктопные приложения на электроне. А страдают обычные юзеры, у которых через 5 лет "морально устаревает" самый топовый ПК. Раньше для ZX Spectrum с 48 КБ памяти и 8-битным процессором 3.5 МГц писали 3D шутеры и стратегии реального времени.
Как запру я тебя за железный замок, за дубовую дверь окованную,
Чтоб свету божьего ты не видела, мое имя честное не порочила…
М. Лермонтов. Песня про царя Ивана Васильевича, молодого опричника и удалого купца Калашникова
Re[19]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну, у кого-то спектр используемых под досом программ исчерпывался ME, DN и DOOM, а кто-то работал с системами верстки, разработки софта, с САПРами и т.п., которые вместе со всеми потребными драйверами в 640 кб категорически не помещались.
Как запру я тебя за железный замок, за дубовую дверь окованную,
Чтоб свету божьего ты не видела, мое имя честное не порочила…
М. Лермонтов. Песня про царя Ивана Васильевича, молодого опричника и удалого купца Калашникова
Re[2]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Worminator X, Вы писали:
ЕМ>>Затем в 32-разрядной винде было 2+2 Гб, которые героическими усилиями переделали в 3+1. WX>И очень зря. Не должен один процесс жрать больше 2 ГБ.
К этому времени уже было совершенно нормально иметь, например, файл базы данных на 50GB.
И хотеть этот файл замапить в память для прямого доступа.
Ограничение в 2GB этому мешало.
С другой стороны, костыль в виде 3+1 откровенно усложнял код и тормозил исполнение, поэтому переход на 64 бита надо было делать как только приблизились к этой границе.
The God is real, unless declared integer.
Re: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Сперва были и 640 кб доступной обычной памяти,
Я плохо представляю себе процессор (особенно в то время) с неограниченными размерами адресных регистров и количеством проводов на внешней шине.
А если мы имеем 20 бит, то потеря примерно половины из них на разные ROM, I/O и прочее — вполне естественна.
EM> и жестко заданные адреса областей внешних устройств, хотя все это можно было запихать в BIOS, и возвращать конкретные адреса по запросам.
Хм, а то, что BIOS запускался с опять же константного адреса F000:FFF0, ты уже не считаешь? Что IDT реального режима сидела по адресу 0:0?
Там местами, конечно, злоупотребляли фиксацией типа "MDA память на 0xB80000", но конфликты происходили в других местах.
Я не вижу твёрдых причин делать эти параметры переменными и требовать извлекать из какого-то справочника, если нет нескольких таких устройств (ресурсов, в общем случае). Там, где было (как компорты, в количестве от 1 до 8), BIOS таки давал такие данные по запросу.
Всегда есть какие-то постоянные параметры. Начиная с кодов команд процессора
EM> Затем в 32-разрядной винде было 2+2 Гб, которые героическими усилиями переделали в 3+1.
Эта переделка вообще потребовалась, потому что на 64 бита не успели быстро перейти. В остальном от неё проблем больше, чем пользы.
EM> В 64-разрядной винде снова 8+8 Тб. Сейчас читаю про макось — и там тоже сплошные явно определенные константы.
ЕМ>Это что-то вроде профессионального бега по граблям, или действительно есть серьезная необходимость изначально задавать эти адреса/размеры глобальными константами вместо того, чтобы определить их только внутри ядра, а всем внешним модулям (даже драйверам и системным службам) возвращать конкретные значения исключительно по запросам)?
Я не знаю, почему 8TB в винде. Но предполагаю, что это просто отражает некий порог, переход за который будет означать скачок в потреблении ресурсов, и этот скачок пока не оправдан.
Вот ещё вопрос: а то, что в автомобиле конкретные габариты и диаметр колёс, ты тоже будешь считать неоправданно зафиксированной константой?
А питающее напряжение в электросети?
The God is real, unless declared integer.
Re[6]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Pzz, Вы писали:
Pzz>>>В 64-х битах такое разделение диктует железо.
ЕМ>>Любое 64-разрядное железо диктует одну и ту же схему разделения адресов?
Pzz>x86, я имею ввиду. Не удивлюсь, если и ARM тоже, в порядке подражания.
У ARM основных линий 48 бит в адресе, но граница (старшие несколько бит) между двумя полуобластями регулируется.
Причём, адреса корневых страничных каталогов для обоих задаются раздельно. Это удобнее по сравнению с x86, где есть надоедливая проблема: если в результате управления памятью ядра меняются записи корневого каталога страниц, то эти изменения надо распространить на все процессы, и этим занимается отдельный блок контроля.
Вот что жаль, что в RISC-V вместо этого сделали практически полное повторение того, что в x86, и в результате там код MM должен тут тоже заниматься лишними плясками.
The God is real, unless declared integer.
Re[2]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Worminator X, Вы писали:
WX>Не должен один процесс жрать больше 2 ГБ.
Это все крайности: для одних — "сколько дадут, столько и сожрем", для других — "нельзя жрать больше N".
Жрать нужно столько, сколько объективно требует задача, с разумным (10-20-30%) допуском на неоптимальность. Для локальных, временных задач вполне допустимо хоть стократное превышение по ресурсам, если оно не выходит за четкие пространственно-временные рамки ("надо срочно сделать по базе отчет нового формата, плевать на оптимизацию, главное — быстро"). Беда в том, что такой подход нынче совершенно нормально применяется в массовом продакшене.
WX>А для 64-битных систем следует разбивать приложения на несколько процессов/библиотек.
Если суть задачи предполагает такое разбиение, то почему не делать этого для любых систем? А если достаточно компактный код занимается вычислениями, для которых потребны десятки гигабайт, то какой смысл его разбивать искусственно?
WX>Для стандартизации и хоть какого-то ограничения аппетитов быдлокодеров.
Для этого как раз лучше всего иметь в системе запросы "каков максимальный объем адресного пространства?", "сколько сейчас доступно памяти?", и вводить в обиход системы, где эти значения могут быть достаточно малыми. Тогда быдлокодерам придется хоть как-то соотносить свои аппетиты с тем, что может встретиться в реальности. А когда в реальности не существует 32-разрядных систем с пользовательским АП меньше 2 Гб, то аппетиты закладываются именно на это.
WX>Сейчас почти все ограничения сняли, и макаки пишут десктопные приложения на электроне. А страдают обычные юзеры, у которых через 5 лет "морально устаревает" самый топовый ПК.
Ну так и я о том же. Гарантированные большие цифры этому косвенно способствуют.
Re[2]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, netch80, Вы писали:
N>Я плохо представляю себе процессор (особенно в то время) с неограниченными размерами адресных регистров и количеством проводов на внешней шине.
Пока смена архитектуры влекла за собой смену программной модели, и программы с 8-разрядных ПК не переносились автоматически на 16-разрядные, а с 16-разрядных — на 32-разрядные, разумно было исходить из разрядности архитектуры.
N>А если мы имеем 20 бит, то потеря примерно половины из них на разные ROM, I/O и прочее — вполне естественна.
Господь с Вами, где там естественность? Половина от мегабайта — 512 кб, а на "разные ROM, I/O и прочее" попервости уходило чуть больше сотни.
N>то, что BIOS запускался с опять же константного адреса F000:FFF0, ты уже не считаешь? Что IDT реального режима сидела по адресу 0:0?
Это все жалкие копейки, какой смысл их вообще упоминать? Коню понятно, что ряд основных параметров неизбежно приходится фиксировать. Но этих параметров очень немного, подавляющее большинство остальных выбирается произвольно.
N>злоупотребляли фиксацией типа "MDA память на 0xB80000", но конфликты происходили в других местах.
Я не о конфликтах, а о фиксации без явной необходимости, как таковой.
N>Я не вижу твёрдых причин делать эти параметры переменными и требовать извлекать из какого-то справочника, если нет нескольких таких устройств (ресурсов, в общем случае). Там, где было (как компорты, в количестве от 1 до 8), BIOS таки давал такие данные по запросу.
То есть, протокол PnP Вы считаете стратегической ошибкой, и адреса/порты/прерывания до сих пор следовало настраивать перемычками?
N>Всегда есть какие-то постоянные параметры. Начиная с кодов команд процессора
Боюсь, Вы не поняли исходной идеи. Или поняли, но из природного упрямства решили довести ее до абсурда.
EM>>в 32-разрядной винде было 2+2 Гб, которые героическими усилиями переделали в 3+1.
N>Эта переделка вообще потребовалась, потому что на 64 бита не успели быстро перейти.
А если бы изначально, вместо фиксации 2+2, определили M+N, то переделки не потребовалось бы вовсе, а реализация запроса M и N была бы, наверное, в тысячи раз дешевле той переделки.
N>В остальном от неё проблем больше, чем пользы.
Как практически от любого костыля, призванного исправить последствия грубой непродуманности.
N>то, что в автомобиле конкретные габариты и диаметр колёс, ты тоже будешь считать неоправданно зафиксированной константой?
Если Вы о габаритах кузова, то они соответствуют как раз исходным константам архитектуры — разрядности магистрали и адресного пространства. Неоправданной фиксацией было бы, например, искусственное, произвольное разделение багажника на секции, из-за которого невозможно было бы загрузить предмет, не помещающийся в секцию.
А параметры колес как раз почти везде плавающие — на многие автомобили можно ставить диски трех-четырех смежных диаметров, а на каждый из таких дисков — шины разной высоты и профиля. Но диски/шины — физические объекты, поэтому их разумно выпускать в ограниченном наборе стандартных размеров, а не бесконечное количество любых возможных вариаций.
N>А питающее напряжение в электросети?
Это тоже исходный параметр. Неоправданной фиксацией константы было бы, например, произвольное ограничение величины тока, потребляемого из одной розетки.
Вторичный источник питания, по большому счету, способен выдавать произвольное напряжение ниже максимально возможного, поэтому фиксацию тех же 5 В в источниках для USB можно было бы тоже считать произвольной, но на момент стандартизации USB, источники с напряжением и током, управляемыми по цифровой шине, были чрезмерно дороги, и фиксация 5 В была разумным компромиссом. А вот если бы сейчас, в разгар дешевых цифровых интерфейсов и микросхем на все случаи жизни, для нового массового универсального интерфейса зафиксировали напряжение, скажем в 10 В, это стало бы неоправданным ограничением.
Re: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Сперва были и 640 кб доступной обычной памяти, и жестко заданные адреса областей внешних устройств, хотя все это можно было запихать в BIOS, и возвращать конкретные адреса по запросам.
Вызов стоит времени, в отличие от зашитой константы. В плюсики, вон, сейчас constexpr подвезли, тоже ради скорости
ЕМ>Затем в 32-разрядной винде было 2+2 Гб, которые героическими усилиями переделали в 3+1. В 64-разрядной винде снова 8+8 Тб. Сейчас читаю про макось — и там тоже сплошные явно определенные константы.
Ну, тут я хз, но напрашивается простая идея, что из одного битика адреса сделали флаг. И да, такое переделать, если много куда проросло (а оно наверняка хорошо проросло) стоит героических усилий.
ЕМ>Это что-то вроде профессионального бега по граблям, или действительно есть серьезная необходимость изначально задавать эти адреса/размеры глобальными константами вместо того, чтобы определить их только внутри ядра, а всем внешним модулям (даже драйверам и системным службам) возвращать конкретные значения исключительно по запросам)?
Ты ёще не знаешь (ну, или знаешь), как на спектруме извращались ради быстродействия. Сейчас-то конечно да, гигагерцы уже никто не считает, а раньше считали такты.
Здравствуйте, Евгений Музыченко, Вы писали:
aik>>А причина может быть простая — одним битом удобно управлять трафиком на системной шине: нет бита == RAM, есть бит == MMIO, и это, например, прибито гвоздями в железе.
ЕМ>В каких-нибудь микроконтроллерах это может быть и удобным, но не в вычислительных же (в широком смысле) системах.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Пока смена архитектуры влекла за собой смену программной модели, и программы с 8-разрядных ПК не переносились автоматически на 16-разрядные, а с 16-разрядных — на 32-разрядные, разумно было исходить из разрядности архитектуры.
8ми разрядные по идее на 16ти-разрядные должны бы переносится вообще без проблем, не вижу каких-то сложностей. А есть какая-то конкретика?
N>>то, что BIOS запускался с опять же константного адреса F000:FFF0, ты уже не считаешь? Что IDT реального режима сидела по адресу 0:0?
ЕМ>Это все жалкие копейки, какой смысл их вообще упоминать? Коню понятно, что ряд основных параметров неизбежно приходится фиксировать. Но этих параметров очень немного, подавляющее большинство остальных выбирается произвольно.
Тебе сейчас жалкие копейки, а тогда и другим это было важно.
ЕМ>А если бы изначально, вместо фиксации 2+2, определили M+N, то переделки не потребовалось бы вовсе, а реализация запроса M и N была бы, наверное, в тысячи раз дешевле той переделки.
Могу предположить, что тогда изначально всё было бы сильно дороже
N>>В остальном от неё проблем больше, чем пользы.
ЕМ>Как практически от любого костыля, призванного исправить последствия грубой непродуманности.
Или, наоборот, продуманности в рамках той ситуации. Проблема в том, что за модернизацию никто платить не хочет, и висит груз совместимости. А сразу сделать офигенски на все времена — это малореально, и на момент первой реализации слишком дорого.
ЕМ>Вторичный источник питания, по большому счету, способен выдавать произвольное напряжение ниже максимально возможного, поэтому фиксацию тех же 5 В в источниках для USB можно было бы тоже считать произвольной, но на момент стандартизации USB, источники с напряжением и током, управляемыми по цифровой шине, были чрезмерно дороги, и фиксация 5 В была разумным компромиссом. А вот если бы сейчас, в разгар дешевых цифровых интерфейсов и микросхем на все случаи жизни, для нового массового универсального интерфейса зафиксировали напряжение, скажем в 10 В, это стало бы неоправданным ограничением.
Ну, вот видишь, ты сам понимаешь, что ограничения рождались не просто так
Здравствуйте, Marty, Вы писали:
M>Вызов стоит времени, в отличие от зашитой константы.
И сколько тысяч раз в секунду Вам потребовалось бы получать фактический размер пользовательского АП?
M>В плюсики, вон, сейчас constexpr подвезли, тоже ради скорости
Сейчас?
M>напрашивается простая идея, что из одного битика адреса сделали флаг.
Именно так — некоторые функции ядра проверяли его командой test. Но с тем же успехом могли бы сравнивать командой cmp с переменной. Все эти функции, без исключения, вызываются относительно редко. Таких, где стоило бы экономить несколько тактов на обращении к памяти, там и близко нет.
M>такое переделать, если много куда проросло (а оно наверняка хорошо проросло) стоит героических усилий.
А могли бы изначально чуть подумать, и не геройствовать потом. Разве что исходно планировалось потом пилить бюджеты.
M>Ты ёще не знаешь (ну, или знаешь), как на спектруме извращались ради быстродействия. Сейчас-то конечно да, гигагерцы уже никто не считает, а раньше считали такты.
Когда-то я сам считал такты и байты, но исключительно по причинам объективного характера.
Re[3]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Вызов стоит времени, в отличие от зашитой константы.
ЕМ>И сколько тысяч раз в секунду Вам потребовалось бы получать фактический размер пользовательского АП?
Мне, при программировании прикладных приложений — вроде ни разу, а в ядре вполне может быть востребованной операцией.
M>>В плюсики, вон, сейчас constexpr подвезли, тоже ради скорости
ЕМ>Сейчас?
Ну да. Только в 11ом стандарте появились, но убогие, и их постоянно дорабатывают
M>>напрашивается простая идея, что из одного битика адреса сделали флаг.
ЕМ>Именно так — некоторые функции ядра проверяли его командой test. Но с тем же успехом могли бы сравнивать командой cmp с переменной. Все эти функции, без исключения, вызываются относительно редко. Таких, где стоило бы экономить несколько тактов на обращении к памяти, там и близко нет.
Ну хз. 640 Кб хватит всем. Кто ж думал, что всё так бурно попрёт, и будут писать софт на жиэсах. А заранее всё пытаться предусмотреть — это даёт высокую степень вероятности, что продукт так никогда и не выйдет.
M>>такое переделать, если много куда проросло (а оно наверняка хорошо проросло) стоит героических усилий.
ЕМ>А могли бы изначально чуть подумать, и не геройствовать потом. Разве что исходно планировалось потом пилить бюджеты.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Я плохо представляю себе процессор (особенно в то время) с неограниченными размерами адресных регистров и количеством проводов на внешней шине. ЕМ>Пока смена архитектуры влекла за собой смену программной модели, и программы с 8-разрядных ПК не переносились автоматически на 16-разрядные, а с 16-разрядных — на 32-разрядные, разумно было исходить из разрядности архитектуры.
Где это у нас автоматический перенос программ?
К нему только-только подходят (ну если не считать Ada, Erlang и Python, и то, как только подходим к задачам типа математики или нейросетей — всё, приехали).
N>>А если мы имеем 20 бит, то потеря примерно половины из них на разные ROM, I/O и прочее — вполне естественна. ЕМ>Господь с Вами, где там естественность? Половина от мегабайта — 512 кб, а на "разные ROM, I/O и прочее" попервости уходило чуть больше сотни.
A0000-BFFFF видеопамять всех видов
C0000-DFFFF область расширителей
E0000-FFFFF BIOS (да, занимал сильно больше 64KB, начиная ещё с AT)
Ну да, с запасом. В 1 из 3 (расширители) этот запас оказался лишним. В 2 из 3 (видеопамять и BIOS) стало не хватать, первое достаточно быстро поднялось до 256-512KB и ушло в отдельные адреса, второе — чуть медленнее, но микрухи ещё до EFI ставили вплоть до 512KB.
Конечно, если бы их поменяли местами, можно было бы непрерывным куском откусить от области расширителей, а не мапить в неё отдельным неудобным куском, как делали с XMS. Но и так разница между 640KB и 768KB не так долго была критичной.
И не надо вспоминать про "хватит всем", этот миф давно развенчан.
N>>то, что BIOS запускался с опять же константного адреса F000:FFF0, ты уже не считаешь? Что IDT реального режима сидела по адресу 0:0? ЕМ>Это все жалкие копейки, какой смысл их вообще упоминать? Коню понятно, что ряд основных параметров неизбежно приходится фиксировать. Но этих параметров очень немного, подавляющее большинство остальных выбирается произвольно.
Вот я и пытаюсь понять, где у тебя граница между "ряд основных" и "подавляющее большинство остальных".
N>>Я не вижу твёрдых причин делать эти параметры переменными и требовать извлекать из какого-то справочника, если нет нескольких таких устройств (ресурсов, в общем случае). Там, где было (как компорты, в количестве от 1 до 8), BIOS таки давал такие данные по запросу. ЕМ>То есть, протокол PnP Вы считаете стратегической ошибкой, и адреса/порты/прерывания до сих пор следовало настраивать перемычками?
А это уже от тебя встречный поиск границ
Нет, не считаю. Потому, что комплект аппаратуры стал вариабельнее. И по количеству (кто мешал впихнуть 4 ATA контроллера?), и по типу (вот у этой машины вообще нету ни ATA ни видео, зато есть два SCSI, один медный FiberChannel и COM-мультипортовка на 64 порта). И когда стало _легко_ делать вариабельные адреса, то это стали делать.
Заметь, MCA, на которой это впервые появилось, это ~1987. PCI это 1991. Прогресс был стремительным за это время, и возможность перешла из дорогого сегмента в общий. Но и то — вначале PCI имел подпорки для AGP, для ATA и ещё для чего-то, отдельными требованиями в стандарте. А это такая же фиксация.
Но и при этом полно зафиксированных вещей. Если ты посмотришь на описания северного моста, то у него на корневой PCI шине дофига фиксированных устройств, которые настраиваются через конфигурационное пространство PCI. Это сам корневой мост, это контроллер памяти, это ещё много чего. С приходом северного моста внутрь процессора суть не поменялась, там те же настройки, и BIOS начинает работу с их кручения. И там много ограничений в духе "Core 4-го поколения имеет только 40 (навскидку) физических линий адреса памяти", а в следующем поколении вдруг добавляют ещё 2 линии. Это всё естественные процессы развития.
N>>Всегда есть какие-то постоянные параметры. Начиная с кодов команд процессора ЕМ>Боюсь, Вы не поняли исходной идеи. Или поняли, но из природного упрямства решили довести ее до абсурда.
Повторяю: не из какого-то упрямства, а в порядке поиска границ. Ты сам допускаешь, что какие-то значения должны быть константными. Но чётких критериев разграничения не дал.
EM>>>в 32-разрядной винде было 2+2 Гб, которые героическими усилиями переделали в 3+1. N>>Эта переделка вообще потребовалась, потому что на 64 бита не успели быстро перейти. ЕМ>А если бы изначально, вместо фиксации 2+2, определили M+N, то переделки не потребовалось бы вовсе, а реализация запроса M и N была бы, наверное, в тысячи раз дешевле той переделки.
Какие нафиг N и какие M? Чему они могли бы быть равны?
Есть определённые правила оптимальности конфигурации, за пределами которых она становится перекошенной и оттого бесполезной. Не было причины делать память юзерленда менее 2GB, потому что не нужно ядру столько; и невозможно давать на толстой машине (2-4GB RAM) меньше 0.5GB ядру, потому что оно тогда только и делало бы, что гоняло байтики между буферами. В линуксе тех времён было такое понятие, как bounce buffers. Почитай про него.
Вот потому и делали 2:2, 3:1 и для особых извращенцев — 3.5:0.5, но в последнем случае уже гнали калёной метлой на 64-битные машины, на которых не надо было упираться в ограничения и работали они уже лучше, чем в таком кривом варианте.
N>>В остальном от неё проблем больше, чем пользы. ЕМ>Как практически от любого костыля, призванного исправить последствия грубой непродуманности.
Ну расскажи, в чём именно непродуманность.
N>>то, что в автомобиле конкретные габариты и диаметр колёс, ты тоже будешь считать неоправданно зафиксированной константой? ЕМ>Если Вы о габаритах кузова, то они соответствуют как раз исходным константам архитектуры — разрядности магистрали и адресного пространства.
Нѣтъ! Им соответствует функциональность типа "возить до 4 человек весом до 100 кг с грузом в объёме до двух обычных чемоданов, со скоростью до 150 км/ч". А какого размера будет при этом машина — это уже как раз вопрос реализации.
EM> Неоправданной фиксацией было бы, например, искусственное, произвольное разделение багажника на секции, из-за которого невозможно было бы загрузить предмет, не помещающийся в секцию.
Чудесно. У меня что в старой, что в новой машине такое разделение есть. Под основным дном багажника место для запасного колеса. И да, я туда рядом с колесом закидываю всякие мелочи типа ключей, но не смог впихнуть электронасос для колёс. И я вполне могу сказать, что это разделение произвольно. Но я и производителей вполне понимаю, для типового применения всё сделано правильно.
N>>А питающее напряжение в электросети? ЕМ>Это тоже исходный параметр. Неоправданной фиксацией константы было бы, например, произвольное ограничение величины тока, потребляемого из одной розетки.
Ну так и оно тоже есть. Большинство наших розеток ограничены 10A. А если я хочу 10.8? Ставить другие розетки и вилки.
Вернёмся от аналогий к основному вопросу. Я всё-таки не вижу, где эти ограничения были бы настолько неоправданны, что заставили бы страдать индустрию без причины на длительный срок. Вместо этого я вижу, что как только упирались в них, достаточно быстро находился вариант решить проблему переходом за следующий порог, который при этом был в разы дальше. Но чтобы без порога вообще — такого не бывало, потому что мы в реальном мире.
The God is real, unless declared integer.
Re[4]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Marty, Вы писали:
ЕМ>>В каких-нибудь микроконтроллерах это может быть и удобным, но не в вычислительных же (в широком смысле) системах.
M>В них тоже, почему нет
Где-нибудь в 80-х, когда декодеры адресов шины нередко делали на элементарной рассыпухе, это имело хоть какой-то смысл. В 90-х, когда все уже было на [С]БИС — почти никакого.
Re[5]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>В каких-нибудь микроконтроллерах это может быть и удобным, но не в вычислительных же (в широком смысле) системах.
M>>В них тоже, почему нет
ЕМ>Где-нибудь в 80-х, когда декодеры адресов шины нередко делали на элементарной рассыпухе, это имело хоть какой-то смысл. В 90-х, когда все уже было на [С]БИС — почти никакого.
Микроконтроллеры сейчас тоже не на рассыпухе, но для них ты это оставляешь
Здравствуйте, Marty, Вы писали:
M>в ядре вполне может быть востребованной операцией.
В ядре эта операция востребована только при проверке адресов, а такие проверки сопутствуют только достаточно редким и/или масштабным операциям. Разница между проверкой одного разряда и сравнением с переменной там даже в тестах будет ниже статистических погрешностей.
M>заранее всё пытаться предусмотреть — это даёт высокую степень вероятности, что продукт так никогда и не выйдет.
Да, когда предусматривание требует сколько-нибудь заметных затрат. А затраты на обоснованный выбор фиксированной границы — 640, 512 или 736 — по определению больше затрат на реализацию через переменную и системный запрос. Только выбор наобум может быть дешевле.
