Ghost
От того что поменяется 5% кода система не станет 64-х битной. Сишный код как ни странно тоже ведь на 32-х битность рассчитан и без изменения он не станет использовать 64-х битную адресссацию.
Плюс ты еще не учитываешь приложения которые уж точно придется переписывать больше чем 5%, ИМХО намного больше.
Я вот час работаю программистом майнфрейма и наблюдаю ситуацию - не смотря на то что 64-х битный режим уже есть очень давно, до сих пор присутствуют приложения с адресным пространством как 24, так и 31 бита. Причем их подавляющее большинство.
>>> Российский софт за 70 млн рублей <<<
ну, не вижу я реальной необходимости в 64 битной адресации, тем более для Колибри... Мы существующие возможности пока используем на 0,Х %...
*****:
;дух машины, мой бубен сильнее твоей тупости
*****:
;дух машины, мой бубен сильнее твоей тупости
*****:
В том то и дело, что в проекте люди не видят необходимости в 64х битах, а тендеры делают с перспективой на будующее, кроме того 64 бита, не такое уже и будующее, основной x86 рынок сейчас 64х битный.
а почему сразу не 128 бит???
Делаем примитивную вещь, открываем Яндекс Маркет, смотрим каталог процессоров с фильтром:
Поддержка AMD64/EM64T - нет - 10 результатов (линеек), они уже даже не выпускаются
Поддержка AMD64/EM64T - есть - 28 результатов (линеек), часть и из этих уже не выпускается...
Глупо наверное выставлять тендер на 32х битную ОС если такие процы уже не выпускаются?
Кроме того дело не только в 64х битной адресации, но и в арифметике, и сопутствующих технологиях идущими с современными процами. Кстати поддержка 64х бит не отменяет 32 ).
История про майнфрейм вполне объяснима, если вспонить что почти весь софт там коммеческий, и далее много вариантов:
- софт старый, конторы выпустившей его уже нет, сорцов нет....
- владельци майнфреймя экономят на покупке лицензии на новую версию....
- наконец аппаратные особенности системы, повышающей производительность в таких режимах...
При упоминании про FreeBSD имелся в виду этот файл
Я не говорю что нам нужны 64 бита, просто топик про разгработку гос. ОС, и как я уже сказал, к гадалке не ходи, нужна поддержка MIPS/x86/x86-64 плюс возможность переноса на мифический российский процессор, который разработают в будующем...
Поддержка AMD64/EM64T - нет - 10 результатов (линеек), они уже даже не выпускаются
Поддержка AMD64/EM64T - есть - 28 результатов (линеек), часть и из этих уже не выпускается...
Глупо наверное выставлять тендер на 32х битную ОС если такие процы уже не выпускаются?
Кроме того дело не только в 64х битной адресации, но и в арифметике, и сопутствующих технологиях идущими с современными процами. Кстати поддержка 64х бит не отменяет 32 ).
История про майнфрейм вполне объяснима, если вспонить что почти весь софт там коммеческий, и далее много вариантов:
- софт старый, конторы выпустившей его уже нет, сорцов нет....
- владельци майнфреймя экономят на покупке лицензии на новую версию....
- наконец аппаратные особенности системы, повышающей производительность в таких режимах...
При упоминании про FreeBSD имелся в виду этот файл
Я не говорю что нам нужны 64 бита, просто топик про разгработку гос. ОС, и как я уже сказал, к гадалке не ходи, нужна поддержка MIPS/x86/x86-64 плюс возможность переноса на мифический российский процессор, который разработают в будующем...
Там только переход в long mode. А начальные таблицы страниц подготавливаются здесь Думаю таких файлов ещё много, но это не принципиально.При упоминании про FreeBSD имелся в виду этот файл
64 бита нужны не столько приложениям, сколько ядру операционный системы. Например менеджер страничной памяти в первых версиях Линукс мапил всю ОЗУ (64 Мб ) в адресное пространство ядра (0хс0000000+). Но 4Гб уже некуда мапить. Такая проблема у всех систем.
Ещё один плюс 64 бит возможность создать системы с единым пространством адресов.
Кстати в AMD64 размер адресов по умолчанию 64 бита а данных - 32 бита. Все 64-х битные регистры кодируются с префиксом rex. Не случайно Интел назвал расширение EMT64.
Serge
Согласен что в некоторых случаях применение 32-х бит оправдано, но в некоторых имелся бы неслабый прирост.
Вообще разработка 64-х битной версии Колибри потребует очень большой предварительно продуманной теоретической базы, что граблей было поменьше. Ну, и соответсвенно - а кто готов этим всем заниматься в полном объеме? Если использовать те же ресурсы, что мы применяли для Колибри, то действительно сразу и напрашивается вопрос "...почему не 128?..." потмоу что за отведенный промежуток мы опять придем к тому к чему пришли сейчас. Ну никак не получается догнать поезд пешком...
Да, и о портируемости можно забыть. Хотя все вроде заикаются о Си и т.д. и т.п., однако в расчет не принимается, что портируемость нужно обсепечивать уже в период проектирования.
Не согласен, на кой ляд делать половинчатые решения? Если уж использовать 64-х разрядные команды и регистры, так не только в ядре.64 бита нужны не столько приложениям
Согласен что в некоторых случаях применение 32-х бит оправдано, но в некоторых имелся бы неслабый прирост.
Вообще разработка 64-х битной версии Колибри потребует очень большой предварительно продуманной теоретической базы, что граблей было поменьше. Ну, и соответсвенно - а кто готов этим всем заниматься в полном объеме? Если использовать те же ресурсы, что мы применяли для Колибри, то действительно сразу и напрашивается вопрос "...почему не 128?..." потмоу что за отведенный промежуток мы опять придем к тому к чему пришли сейчас. Ну никак не получается догнать поезд пешком...
Да, и о портируемости можно забыть. Хотя все вроде заикаются о Си и т.д. и т.п., однако в расчет не принимается, что портируемость нужно обсепечивать уже в период проектирования.
Никто не делает половинчатых решений. Если софт был правильно написан для 32-х бит он просто перекомпилируется. Я не помню в ATI-шных дровах специальных кусков кода для 64-х бит. Есть несколько макросов для компиляции под big endian платформы. И всё. Это в драйвере !
Ну, знаешь то что компании не используют 64-х битную адрессацию в драйверах еще не говорит, что это есть правильно. Здесь возможен принцип - "работает - не трогай", т.е. оставили как есть. С другой стороны если само устройство не поддерживает 64-х битную адрессацию, тогда да имеет смысл вышесказанное.
Mario
Ты не понял. Этот код компилируется без изменений и на 32 и на 64 бита.
Ты не понял. Этот код компилируется без изменений и на 32 и на 64 бита.
Serge
Да, понял я про что ты писал. Я лишь не согласен с тем, что код без задумки програмиста не может быть от балды 32-х битным или 64-х битным. Если уж написано для 32-х битов то и будет 32-бита использовать.
Да, понял я про что ты писал. Я лишь не согласен с тем, что код без задумки програмиста не может быть от балды 32-х битным или 64-х битным. Если уж написано для 32-х битов то и будет 32-бита использовать.
Большинству алгоритмов ровно до разрядности, открой кнута, там вообще абстрагируются от такой мелочи. На деле если программа была написана на ЯВУ для 32бит, то алгоритмически это лишь упирается в структуры данных, причем на 64бита эти структуры будут работать точно так же... А вот код x86 и x86-64 по сути совершенно разный, но используя ЯВУ об этом не нужно задумыватся. Сортировка массива, обращение к контроллеру (как правило порты однобайтные), алгоритм балансировки процессов к разрядности не привязаны, если вводить нужные абстракции (например структуры (struct) для С/С++). Не спорю, есть в ядре код привязанный к процессору, но его 5-10%.
Who is online
Users browsing this forum: No registered users and 1 guest