стань автором. присоединяйся к сообществу!
Добавить новость можно всем, без премодерации, только регистрация
Лого Сделано у нас
131
arslan.ayupoff 28 января 2016, 00:06 15 Информационные технологии

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

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

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

читать полностью
Источник: politikus.ru

Поделись позитивом в своих соцсетях


Байкал Электроникс, Базальт СПО.
все комментарии
  • 0
    rvk rvk
    28.01.1619:37:58

    А сори. вспомнил про PAE. Только там максимально поддерживается 64Гб. Плюс это скорее все-таки некоторая переходная технология от 32 к чистым 64-и разрядным процессорам. И в этом случае у отдельной программы все равно остается лимит на максимум 4Гб памяти.

    #741035 ↑
    • 0
      Нет аватара guest
      28.01.1620:40:47

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

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

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

      #741056 ↑
      • 0
        rvk rvk
        28.01.1622:23:46

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

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

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

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

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

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

          #741102 ↑
          • 0
            rvk rvk
            28.01.1623:25:19

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

            #741117 ↑
          • 0
            Нет аватара guest
            29.01.1612:15:46

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

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

            Отредактировано: Вася Козлов~13:17 29.01.16
            #741284 ↑
        • 1
          Нет аватара guest
          29.01.1601:48:17

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

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

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

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

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

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

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

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

          Поэтому:

          Еще раз,

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

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

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

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

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

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

            #741408 ↑
            • 0
              Нет аватара guest
              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-х битные — это же куда как круче звучит и можно срубить побольше бабла    

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