Представитель компании ARM опубликовал (https://lkml.org/lkml/2012/7/6/525) в списке рассылки ядра Linux набор из 36 патчей с начальной поддержкой AArch64, 64-битной архитектуры ARMv8. ARMv8 поддерживает два режима работы - AArch64 и AArch32. В режиме AArch32 предоставлется классический набор 32-разрядных инструкций, используемый в архитектуре ARMv7.
64-рязрядная архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров (31 64-разрядный регистр), новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON. При этом размер непосредственно инструкций по прежнему укладывается в 32 бита, а сами инструкции в большинстве совпадают с набором A32 (различия только в дополнительных регистрах, наименовании регистров, 64-разрядных аргументах и расширенной адресации памяти). Архитектура ARMv8 также отличается поддержкой уровней обработки исключений: EL0 - режим пользователя, EL1 - режим ядра, EL2 - режим гипервизора, EL3 - secure monitor.Новое ABI LP64 использует достоинства более крупного регистрового файла (http://ru.wikipedia.org/wiki/%D0%A0%D0%B... и делает аппаратную поддержку вычислений с плавающей запятой обязательной. Документация по набору команд была опубликована ранее, однако теперь доступны и готовые патчи с поддержкой новой архитектуры для ядра Linux (около 23 тысяч строк кода). Сборка кода под данный набор команд производится с использованием инструментария на базе опубликованных в конце мая (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html) патчей для GCC с поддержкой AArch64 (aarch64-none-linux-gnu-toolchain). Примечательно, что реализация архитектуры AArch64 для ядра Linux обеспечивает полную поддержку запуска 32-битных ARMv7-программ (ARM EABI), за исключением некоторых инструкций, объявленных устаревшими.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTEzNDg
Новость: http://www.opennet.me/opennews/art.shtml?num=34285
ну шикарно же! ждем ARM-серверов в массах!
как у АРМов дела с котроллерами памяти на кристалле, гипертранспортами между ядрами/процессорами, RDMA?
> как у АРМов дела с котроллерами памяти на кристалле,
> гипертранспортами между ядрами/процессорами, RDMA?А как донавесит чипмэйкер так и будет. ARM предоставляет ядра, а желающие донавешивают периферию как им там надо под их задачу или позиционирование их чипа на рынке.
ошибаешься. В смысле, в серверном мире так не катит. Либо разработчик сразу делает архитектурные закладки для кооперативной работы кристаллов, либо кристалл вылетает в другие ниши.
Угу, расскажите больше. Учитывая, что на десктопном железе крутится масса сервисов, с гугла начиная.
Про гугл - наглая ложь. У них весьма нефиговое серверное железо.
> как у АРМов дела с котроллерами памяти на кристалле, гипертранспортами между ядрами/процессорами,
> RDMA?RDMA процессору ортогонально.
нет, не ортогонально, по крайней мере для современного серверного CPU, а не образца начала 9х
Новые команды насколько я понимаю должны прибивать производительности ARM?
Забавная опечатка.
:) по Фрейду.
Если в принципе возможно, то хорошо бы было ещё такое промежуточное ABI: 64 бит данные и 32 бит адреса. Для роутеров-мыльниц самое то.
Для таких применений будет достаточно 32битных ядер от ARM.
Смотря для каких таких применений. Допустим шифрованию трафика операции с 64-разрядными данными категорически не помешают.
с 64- и 128-битными числами и векторами NEON и так умеет работать
> с 64- и 128-битными числами и векторами NEON и так умеет работатьПлюс у половины чипов для таких применений есть аппаратные акселераторы для оффлоада всяких там sha и прочих aes-ов. А кому надо что поэкзотичнее и на скорости гигабит и более - ну напишете полкило на асме с simd командами, не развалитесь.
>с 64- и 128-битными числами и векторами NEON и так умеет работатьЦелочисленные операции с адресами IPv6 удобнее как-то в РОНах делать, чтоб без переделки кода сетевого стека на ASM.
> Целочисленные операции с адресами IPv6 удобнее как-то в РОНах делать, чтоб без
> переделки кода сетевого стека на ASM.Прошу прощения, а вот нефиг было самим себе придумывать грабли в виде 128-битной адресации. Теперь весь мир из-за каких-то теоретиков-идеалистов обязан будет мучаться. ССЗБ.
Я, конечно, жуткий скептик, но с моей точки зрения - IPv6 не взлетит даже после кончины адресов IPv4. Как раз из-за своей оторванности от реального мира.
Не мучаться, а подкрутить соответствующим образом железо. И подкрутит, куда он денется - хотя бы потому что альтернативу IPv6 никто разработать не удосужился, а нужен он уже сегодня (скорее вчера даже).
> Не мучаться, а подкрутить соответствующим образом железо. И подкрутит, куда он денется
> - хотя бы потому что альтернативу IPv6 никто разработать не удосужился,
> а нужен он уже сегодня (скорее вчера даже).Да не похоже, что нужен. Был бы нужен - за 20 лет бы что-то сдвинулось. А воз и ныне там.
>> Не мучаться, а подкрутить соответствующим образом железо. И подкрутит, куда он денется
>> - хотя бы потому что альтернативу IPv6 никто разработать не удосужился,
>> а нужен он уже сегодня (скорее вчера даже).
> Да не похоже, что нужен. Был бы нужен - за 20 лет
> бы что-то сдвинулось. А воз и ныне там.А вы сейчас попробуйте получить сеточку ipv4 адресов, /22 например.
> А вы сейчас попробуйте получить сеточку ipv4 адресов, /22 например.Буквально месяц назад получал.
А вы попробуйте по IPv6 заиметь нормальную связность с более, чем 0.1% ресурсов Сети, не имея IPv4. Да и просто заиметь связность по IPv6 без туннелирования.
Ну забрали какой-то кусок остатков. Статистика занятости IP-адресов всем известна.
20 лет потребности особой не было, просто разумные люди понимали,что рано или поздно она появится. И вот - появилась. И связность вполне себе растёт. Если в датацентрах железо - связность по IPv6 между ним будет почти с гарантией. А в Европе/Штатах - будет точно. А что конечные провайдеры не подтягиваются - дело времени. По крайней мере ситуация явно лучше, чем год назад, судя по результатам Дня IPv6.
> Ну забрали какой-то кусок остатков.Угу.
Чувствую, скоро все будем прикидываться африканцами и просить ip-шники у AFRINIC.
>с 64- и 128-битными числами и векторами NEON и так умеет работатьNEON в маршрутизаторе? Мсье знает толк.
Hmm... Why not?
но зачем?
> Если в принципе возможно, то хорошо бы было ещё такое промежуточное ABI: 64 бит данные и 32 бит адреса.этот костыль только для убогих х86 актуален, у ARM есть режим thumb.
> этот костыль только для убогих х86 актуален, у ARM есть режим thumb.Правда не совсем понятно как оно влияет на размер указателей (адресов), etc. Если некто может адресовать более 2^32, ему таки придется все 64 бита тогда ворочать :)
ARM изначально может более 4 гигов ворочить.
слишком толсто
Пора уже на 128 бит переходить.
Вы хоть представляете насколько это не нужно? Тут уж точно только память лишняя жраться будет. Нужны регистры более 64-бит? Используйте AVX с 256-битными регистрами.
> Вы хоть представляете насколько это не нужно? Тут уж точно только память
> лишняя жраться будет. Нужны регистры более 64-бит? Используйте AVX с 256-битными
> регистрами.Так мужики, профита не будет, пока вся шина не будет той же разрядрнсти.
> Так мужики, профита не будет, пока вся шина не будет той же разрядрнсти.Use GPU, Luke. Тут тебе и регистров 100500 штук, и 256-битная шина - нормальное явление, и SIMD хоть отбавляй. Вы этого хотели? Нате :)
Иди в школу ламерюга, учи что такое компутерная шина.
Разработчики QPI смотрят на pavlinux как на сами понимаете что.
Интересно а кому оно надо? Основные численные вычисления в любой проге не превышают разрядности в 32-бита. Адресация в террабайты также мало востребована. Если int станет 128-битным то тупо увеличится размер программы и затраты на аппаратные ресурсы, без малейшего прироста в производительности. Или просто вкуснее то, что толще?
ты немного отстал от времени, на лет эдак десять. 128битный регистр, конечно, навряд ли будет в ближайшее столетие востребован, но 32битные числа давно уже перестали удовлетворять большинство программ. Приём, как с точки зрения адресации (привет, придурок, +4г файлы), так и с вычислениями (собственно, та же адрессация)
> (привет, придурок, +4г файлы), так и с вычислениями (собственно, та же адрессация)Умникам не понятно, что 32р хватает для большинства применений, а если иногда нужно что то сделать с 64р, то и 32р регистры подойдут. что до адресации, то придуркам конечно полезно почитать про то почему сейчас делают 32р аби на 64р системах.
А на 16-ти битах 8086 файлы по-твоему были ограничены 64К? А про размеры винчестеров уже и вспоминать не хочется, а то шаблончик в клочья разлетится. Эх, молодежжжж...
> Приём, как с точки зрения адресации (привет, придурок, +4г файлы)Не путаете с 32 битными файловыми системами?
С 4гиговыми файлами можно работать и в 16битном режиме.
А с PAE можно видеть больше 4 гиг оперативки.> так и с вычислениями (собственно, та же адрессация)
Вам конструкции "long long", "long double" ничего не говорят?
Да ладно, ну решил человек, что без memory mapping жизни нет. Его дело.
Хорошая новость. Маршрутизаторы и прочее потребительское железо тоже со временем перейдут на эту архитектуру. Один вопрос возникает: почему не получила в свое время сравнимого с ARM распространение MIPS и MIPS64? Ведь MIPS сравнима с ARM по своим характеристикам, а в чём-то и превосходила ARM?
Особенно круто будует когда вот такое влезет в наручные часы и будет по цене китайского тетриса :)
MIPS вообще-то тоже давольно расспространена (роутеры, бытовая элекроника итд)
Компания SGI делала на MIPS мощные рабочие станции, стоившие бешеных денег (до сих пор работают). Мне тоже интересно, почему сейчас мипс интересен только как затычка слота для роутеров, а АРМ уже на серверах и мобильных устройствах - характеристики-то вроде сравнимы. На MIPS уже давно было 64 бита
> Компания SGI делала на MIPS мощные рабочие станции, стоившие бешеных денег (до
> сих пор работают). Мне тоже интересно, почему сейчас мипс интересен только
> как затычка слота для роутеров, а АРМ уже на серверах и
> мобильных устройствах - характеристики-то вроде сравнимы. На MIPS уже давно было
> 64 битаВ ARM напихивают много всякой акселерации, интересной в основном для мобильных устройств - телефонов, планшетов, etc. + лицензирование.
У MIPS с лицензированием всё несколько проще, и в них чаще всего пихают только сетевой модуль. Как раз "то, что доктор прописал" для роутерных платформ.
В целом платформы уже очень специализировались. ARM - мобильный рынок, MIPS - сетевое железо. Вероятно, стараются не конкурировать по нишам.
> В ARM напихивают много всякой акселерации,Ни разу не обязаны. Это на усмотрение производителя. И вообще, cortex-M0 - это тоже типа ARM. А теперь найдите там акселераторы. Ну, всякие "стандартные" навороты типа DMA мы не учиываем :)
> интересной в основном для мобильных устройств - телефонов, планшетов, etc.
...за то что мало жрет и при том довольно шустро считает.
> + лицензирование.
MIPS в принципе тоже лицензирует. Но делает это менее внятно. За что и страдает, видимо.
> У MIPS с лицензированием всё несколько проще, и в них чаще всего
> пихают только сетевой модуль. Как раз "то, что доктор прописал" для
> роутерных платформ.Еще там потребление менее критично и отсутствие агрессивных powersave режимов и изменения частоты - не является проблемой.
> В целом платформы уже очень специализировались. ARM - мобильный рынок, MIPS -
> сетевое железо. Вероятно, стараются не конкурировать по нишам.В целом - и то и другое как бы просто процессоры. То что одних чаще юзают в одном месте а других в другом - мало что означает. ARM бывает в роутерах, в сетевых плеерах и NAS - он вообще чаще MIPS. А на MIPS кто-то пытался телефон делать. Но это сложнее - там агрессивная экономия питания нужна а у MIPS в этом плане наработок меньше.
Cortex-M0 - это уже уровень микроволновки :) или самого тупого управления для MP3-плеера (если выносить декодер на отдельный чип). Т.е. мелочевка. Там MIPS'ы почти не применяют, они сидят сегментом выше.
> пытался телефон делать. Но это сложнее - там агрессивная экономия питания нужна а у MIPS в этом плане наработок меньше.Power consumption also seems to be the strong side of the MIPS architecture. The JZ4770 SOC consumes only 0.25W under 100% CPU and video engine load (1080p playback), which is significantly less than ARM competitors. Naturally, as you beef up the GPU and add a second core, the power consumption will go up, but still below ARM-based products.
http://vr-zone.com/articles/mips-architecture-crashes-arm-x8...
>Вероятно, стараются не конкурировать по нишам.Очень даже стараются конкурировать. Просто не очень получается. Ну так с арм конкурировать (пока) ни у кого особо не получается.
http://promwad.ru/news/13-07-2011-mips-vs-arm.html
И телевизоры нормальные жеж с мипс и линуксом
хинт: лицензирование
И что в плане лицензирования принципиально отличается у ARM и MIPS?
Роутеров на MIPS на порядки больше, чем роутеров на ARM. По числу доступных моделей.
А сейчас не превосходит что-ли? Если это не маркетинговый буллшит http://panchul.livejournal.com/202444.html - вполне ничего так.