Board.KolibriOS.org

Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.

Serge wrote:Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.

Горацио, бывают заморочки
с которых все ботаники фигеют.

У.Шекспир, Гамлет, акт 1.

Serge wrote:Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.

Сильно напомнило:

С Хабра, обсуждение даты релиза iPhone 5:
stalkerxxl: В этот день миллионы счастливых обладателей iPhone 4S в одно мгновение станут нищебродами =))

Serge! Я не имел в виду, что 64-битную версию KolibriOS не имеет смысла делать ...

FireWall
Тем не менее ядро как раз и есть эта массовая пользовательская задача. Потому что все мы им пользуемся, даже если и не задумываемся над этим. И для ядра современного компьютера 4Гб адресного пространства уже мало. А для 99.9% массовых пользовательских программ "не игрушек" достаточно 32 бит.

Serge
Обычно я тебе верю, потому что ты аргументируешь. В данном случае прозвучало лишь заявление и никакой почвы под ним не подведено.

Но у ядра есть PAE и PSE-36 ! И я как раз говорю о массовом пользователе, а не о специфических профессиональных задачах.

Другое дело, что легче создать универсальную операционноу систему (и это ничего, что она на компьютере массового пользователя будет тупо занимать место), чем две различные (одну - компактную и 32-х битную для массового использования, другую - продвинутую и 64-х битную для отдельных профессиональных а также обыденных серверных и корпоративных нужд (для настоящих корпоративных и научных всё равно нужен суперкомпьютер)). То же относится и для аппаратных платформ ... Вот и усаживают всех нас на сильно усечённую корпоративно-серверную платформу (рынок, мать твою)

Аргументация.

Посмотрим на код sys_ipc_send.

Теперь представим что 32-х битные приложения Колибри работают под 64-х битным ядром.
Адресное пр-во каждого процесса помимо обычного мапинга на адреса 0 - 2Гб также мапится на адреса 512Гб + номер_слота*2Гб. Соответственно в режиме ядра есть одновременный доступ к адресным пространствам всех процессов и копирование ipc можно сделать простым rep movsq. Цена вопроса 4Кб для одной таблицы PML3 или 8 для двух таблиц если увеличить доступное приложению пространство до 4 Гб. Это только один пример.

Ну сэкономим время заметно меньшее необходимого для ring3 -> ring0 -> ring3 (это для вычисления и копирования нескольких (в случае KolibriOS в 99,9% - одной, самой первой) последовательных записей из таблицы PD процесса на стандартный участок PD текущего контекста , соответствующий верхней области адресного пространства)

Удобно то оно конечно удобно (для программиста, пишущего ядро), но меня умиляет наблюдать за тем, как в Menuet64 в регистрах общего назначения мелькают скорее 16-и битные числа. (что-то вроде 0x00000000000xxxxx) Вы предлагаете разнообразить их чем-то вроде 0x000000хх000xxxxx. ну будет выглядеть чуть веселее. Но, на мой взгляд, - это из области "бешенства с жиру".

64битная система хороша тем, что можно обойтись вообще без маппинга памяти

FireWall прав, 64-битная адресация генерит гораздо более рыхлый (и потенциально более медленный) код.

И это еще очень большой вопрос, что для истории важнее - наличие 8 новых длинных регистров или отсутствие 32 (а то и 48) бесполезных нулей в каждом адресе.

Я опять в ту же тему: истина всегда должна быть где-то посередине...

Кстати, если говорить конкретно о KolibriOS, то идею одновременного доступа ко всем приложениям со стороны ядра можно осуществить и в текущем 32-битном варианте, выделив 4Мб*256 = 1Гб адресного пространства для повторного отображения приложений, для которых хватает 4 Мб.

А в целом дискуссия приобретает так сказать "философский характер": у каждого может быть своё мнения по поводу того, что он считает комфортным, достаточным и необходимым.

Мои философские взгляды таковы:
(1) Минимальная оправданная конфигурация для 64-битного процессора начинается с 4Гб оперативной памяти на борту. Такая нормальная - 16 Гб
(2) Выше названные удобства 64-битной адресации считаю мелкими в том смысле, что
- с одной стороны: ради них переходить с 32-х бит на 64 - НИ В КОЕМ СЛУЧАЕ;
- если же у нас на борту 64-процессор - грех не воспользоваться.

Другой вопрос, что заставить использовать MMX или SSE для 64-битной арифметики компилятор gcc (вместо цепочечного использования 32-х битных GPR) мне так и не удалось Поэтому информация, говорящая, что при перекомпиляции приложения с 32-х бит на 64-бита приложения начинает исполняться быстрее - сущая правда. Тому причиной:
- большее число регистров (а значит меньший поток данных процессор <-> память, связанный с временными данными и соглашениями вызова),
- неумение компиляторов рационально использовать MMX и XMM регистры (а в этом случае 64 битная арифметика на x86_64 будет существенно быстрее).
Как говориться, 64-битность x86_64 тут ни причём. (Для пояснения выскажу гипотезу, что если бы против 16-ти 64-х битных регистров в X86_64 с теперешними компиляторами, поставить 32 32-х битных регистров (в compatability mode) + научить компиляторы рационально использовать всё это хозяйство (перекомпилировать всё равно потребуется - на нормальном компиляторе ) - то этот рациональный 32-х битный код в compatability mode исполнялся ещё быстрее)
-----------------------------------
Дополнение:

Похоже, что 64-битную арифметику на IA32 осуществить хоть и можно - но сложно ( (1) использовать SSE2 (2) преобразование : i64_t -> Fpu -> i64_t). Так что ещё один маленький аргумент не в мою пользу

Давайте поставим вопрос другим ребром: а на кой нам вообще сдались 64 бита?

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

Конкретных прикладных задач очень немного - их можно перечислить по пальцам:
1) трассировка проводов на многослойных печатных платах
2) очень реалистичный многолучевой рендеринг
3) строительный, оптомеханический и аэрокосмический трехмерный дизайн
4) оптимизация временных задержек между логическими вентилями на очень сложных процессорах и FPGA
5) обратные задачи в определении целей (на зашумленных сигналах) в радиолокации и распознавание трехмерных объектов по 2-мерному видеоряду
6) обработка временных рядов и долгосрочное прогнозирование в метеорологии и гидрографии.
7) некоторые задачи тепло-массопереноса, химической кинетики и газодинамики
8 (может забыл чего?) - дополните кто еще что-нибудь вспомнит. (ядро не предлагать )

Все перечисленные задачи настолько сложны и ресурсоёмки, что им ВСЕГДА выделяют практически монопольный приоритет в любой реальной системе.
В Колибри для ОДНОЙ подобной задачи вполне можно выделить отдельную голову, и гонять ее в монопольном 64-битном режиме.
При этом ядро и подсистема ввода-вывода остаются в 32-битном поле, взаимодействуя с 64-битной головой через общие страницы памяти и MSI-прерывания.

Simvolnye vychisleniya

(1) Для символьных вычислений не нужно >4Гб адресного пространства (обычно), но при наличии 64-битных регистров (вместо 32-х битных) почти всегда наблюдается существенное увеличение производительности (например, на числах с произвольной точностью при умножении производительность может возрасти больше чем в два раза).

(2) Многоканальная студийная звукозапись, когда весьма желательно иметь возможность разместить весь проект, содержащий порой >32-х каналов (это на CD 1 минута занимает 10 Мб, при студийном качестве - это > 40Мб, так что на 40 дорожек по 10 минут каждая будет 40 * 40 * 10 = 16000 Мб).