133

«Байкал Электроникс» и «Базальт СПО» создают отечественный дистрибутив Linux для архитектуры ARM

Разработчик интегральных схем «Байкал Электроникс» и «Базальт СПО», российская софтверная компания, работающая в области открытого программного обеспечения, объявляют о первых результатах сотрудничества в сфере разработки прикладного и служебного программного обеспечения.

В ходе сотрудничества будет создано полнофункциональное программное обеспечение для процессорных систем на базе архитектуры ARM v8 (AArch64).

Выпуск готовых вариантов операционных систем на базе Linux, как серверных, так и клиентских, запланирован до конца текущего года. На данный момент завершен первый этап взаимодействия «Байкал Электроникс» и «Базальт СПО».

В ходе этого этапа разработана система сборки и репозитория для процессора «Байкал-М» на основе архитектуры ARM v8 (AArch64). Репозиторий собран на основе примерно 10 тысяч пакетов проекта Sisyphus, одного из крупнейших в мире банков пакетов свободных программ, созданного российскими разработчиками ПО.

Репозиторий доступен для тестирования — www.altlinux.org/Ports/aarch64 На втором этапе сотрудничества компаний предполагается тестирование на различных системах AArch64, на третьем — сборка дистрибутивов различного назначения и тестирование на опытных образцах процессора «Байкал-М».

"Разработка отечественных универсальных аппаратно-программных решений — наше давнее желание, которое сейчас, наконец, осуществляется, — рассказал Алексей Новодворский, генеральный директор «Базальт СПО», — Наша совместная работа с разработчиками отечественных аппаратных систем и программных прикладных решений существенно повысит технологическую независимость отечественных решений. У нас есть большой опыт разработки систем для 32-битных процессоров ARMv7 и работа над 64-битными процессорами — естественное развитие наших компетенций".

«Мы рады сотрудничать с профессиональной командой, имеющий большой опыт разработки свободного программного обеспечения и успешные проекты с операционной системой Linux. Готовность софтверной экосистемы к моменту выхода разрабатываемого процессора „Байкал-М“ позволит оперативно создавать востребованные рынком конечные устройства на его базе. Мы будем и дальше развивать наше партнёрство», — поделилась генеральный директор «Байкал Электроникс» Светлана Легостаева".

В настоящий момент «Байкал Электроникс» и «Базальт СПО» рассматривают перспективные проекты сотрудничества в создании систем для аппаратной платформы процессора «Байкал-T1» (MIPS 32 бита). Информация об упомянутых компаниях: ОАО «Байкал Электроникс» специализируется на проектировании систем на кристалле на базе архитектур ARM и MIPS. Разработки компании предназначены для использования на российском и международном рынках в энергоэффективных компьютерных и промышленных системах с разным уровнем производительности и функциональности. www.baikalelectronics.ru

ООО «Базальт СПО» — российский разработчик программного обеспечения. Компания создана участниками и пользователями проекта ежедневно обновляемого репозитория пакетов свободных программ Sisyphus (Сизиф). Цель компании — развитие основной инфраструктуры репозитория, его расширение на новые аппаратные архитектуры.

«Базальт СПО» специализируется на разработке комплексных решений уровня предприятия на основе свободного программного обеспечения. Компания принимает участие в международных проектах и интегрирует в них собственные разработки. basealt.ru


  • 0
    Андрей Немо Андрей Немо
    28.01.1620:40:47

    Нет, именно 64 терабайт. Одно но, вся выделяемая память будет сегментирована, на блоки размеров в 4Гб. То есть как в старом досе, только размер сегмента побольше.

    И еще. Это не переходная модель. Это полноценная реализация виртуальной адресации, когда на аппаратном уровне можно было выполнять множество задач, расположенных в одних и тех же адресах. То есть это задачи так думали, а процессор им подставлял другие участки памяти. У 64-х битных как раз эта фича кастрирована, поскольку 64-х битный линейный адрес и так дает на сегодня неограниченный запас по памяти.

    PS: Кстати, были таки материнки, с 36-разрядной памятью! Очень редкий зверь.

    • 0
      rvk rvk
      28.01.1622:23:46

      2^36 = 68719476736 = 68719476736/1024/1024/1024=64Гб

      Это, конечно много, но для обычных ПС, для серверов это уже может быть в ряде случаем маловато. Например, сервера на которых работает этот сайт имеют по 32Гб памяти.

      То есть это задачи так думали, а процессор им подставлял другие участки памяти.
      Это у нас программистов называется «костыль»     Еще раз, PAE, как собственно и тот же HIMEM это есть некий компромисс, некая переходная технология, а 64-х битные процессоры уже предоставили полноценную реализацию адресации сверх 4Гб.

      • 0
        Нет аватара silicoid
        28.01.1622:58:29

        для времен середины 90х, когда появилась 36 битная адресация, это было чуть больше, чем дохрена ))

        Сейчас -- да, но сейчас никто не пользуется параллельной адресной шиной

        • 0
          rvk rvk
          28.01.1623:25:19

          для времен середины 90х, когда появилась 36 битная адресация, это было чуть больше, чем дохрена
          Когда-то и 640 Кб было чуть больше чем дохрена    

        • 0
          Вася Козлов Вася Козлов
          29.01.1612:15:46

          //Сейчас -- да, но сейчас никто не пользуется параллельной адресной шиной//

          Прежде чем писать чухню, скачайте datasheet на микросхемы DDR2/DDR3/DDR4 памяти с микрон_точка_сом или гугла и посмотрите какая там шина адреса последовательная али параллельная.

          Отредактировано: Вася Козлов~13:17 29.01.16
      • 1
        Андрей Немо Андрей Немо
        29.01.1601:48:17

        Это, конечно много, но для обычных ПС
        Это Пентиумы, то есть конец 90-х. В то время для домашнего компа было за счастье 32Мб памяти. И даже серваки не мечтали хотя бы о 1Гб. Так что 64Гб — это была фантастика и понятно, что не получило распространения — просто нахрен никому не нужно было столько памяти, а переплачивать лишь за возможность никто не хотел. Они просто опередили свое время.

        Это у нас программистов называется «костыль"
        Рискну предположить, что Вы не системный программист     Иначе мне трудно понять, как основу защищенного режима можно назвать костылём. Без механизма виртуальной адресации нереально реализовать безопасный доступ различных задач к общим ресурсам, например подпрограммам DLL. Без него нельзя изолировать задачи друг от друга. На нем основано мэппирование памяти. В конце-концов, без него очень трудно реализовать механизм файла-подкачки.

        При переходе с 32 на 64 бит выкинули:

        1. Реальный режим

        2. Режим виртуального 8086

        3. Аппаратное переключение задач

        4. Абсолютную адресацию, т. е. все адреса теперь только косвенные!

        Это все. Механизм адресации остался прежним. Они только урезали его, выкинув возможность работы с физической адресацией. То есть, все 64-х битные программы могут работать исключительно в режиме виртуальной адресации и никак иначе!

        Поэтому:

        Еще раз,

        PAE, как собственно и тот же HIMEM это есть некий компромисс, некая

        переходная технология

        я не понял, о чем Вы. Никакой революции с переходом на 64 бита не произошло, изменения минимальны и носят скорее косметический характер — выкинули неиспользуемое и расширили набор регистров, так как с переходом на 64 бита упала производительность и ее нужно было как-то компенсировать.

        • 0
          Нет аватара 99Andrei
          29.01.1617:00:20

          переходом на 64 бита упала производительность

          Субъективно на 64-битной машине с 64-битным дебианом графический рабочий стол работает ощутимо быстрее, чем с 32-битным дебианом +PAE.

          • 0
            Андрей Немо Андрей Немо
            29.01.1618:34:03

            Это вопрос к драйверам видеокарты и системе. Дело в том, что процессоры имеют много схожего. Разрядность шины данных еще с Pentium составляет 64 бита, вплоть до Core 2 Duo. Разрядность шины адреса у процессоров с PAE тоже 64 бита, хотя используются только 36 бит. Механизм защищенного режима у 32 и 64-х битных процессоров практически одинаков. Так что увеличение производительности на 64-х битных системах достигается за счет того, что параметры для функций API передаются в регистрах, а не в стэке, как это было на 32-х битных ОС. Учитывая огромное количество вызовов различных подпрограмм даже для отрисовки простого пикселя — это даст ощутимый прирост. PAE здесь ни при чем    

            Говоря про упадок производительности, имелось в виду следующее:

            1) При 64-х битной адресации в кэшах умещается меньше слов данных (в два раза!).

            2) 64-х битное АЛУ по определению будет работать дольше 32-х битного, в силу обработки большего количества бит. Для примера, при создании Pentium-4 было решено перейти на 16-ти битное АЛУ, именно в целях повышения быстродействия, поскольку подавляющее большинство вычислений вполне умещается в 16 бит. В результате, на простых приложениях 16-ти битное АЛУ Pentium-4 с легкостью обставляло 32-х битное АЛУ Pentium-3. На 32-х битных вычислениях оно конечно проигрывало, но таких очень мало.

            3) При 32-х битной адресации процессору нужно выбирать из памяти меньше байт на команду, чем при 64-х, что тоже сказывается на скорости. Программы под 32 бита в среднем меньше 64-х битных в 1.5-3 раза.

            Единственный вариант повышения производительности 64-х битных машин — это увеличение кэша и добавление новых регистров. Вот последнее и позволяет наиболее эффективно нивелировать отставание от 32-х битных. Для примера, первые процессоры Z80 на схожей с 8080 частоте превосходили их в 1.5-3 раза, именно за счет увеличения в два раза регистров.

            С другой стороны, а кто мешал добавить регистров в 32-х битные процессоры? Да никто, просто маркетологи сочли это бесперспективным, в отличии от перехода на 64-х битные — это же куда как круче звучит и можно срубить побольше бабла    

Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,