• TrustZone: аппаратная реализация в ARMv7A
    +1
    Спасибо за статью, редко когда встречаешь хорошие материалы по ARM на русском. Всё больше документацию читать приходится.

    Но у вас, честно говоря есть неточность, когда говорите, что ARM не предоставляет никаких средств для разделения обычной памяти между Secure и Non-Secure. ARM предоставляет IP-блок под названием TZC-400, имеющий порты AXI Slave для подключения к Interconnect и AXI-Lite Master для подключения к Memory Controller. То есть, если на пальцах, этот блок вставляется между интернетом и контроллером памяти, фильтрует запросы и настраивается программно. Другой вопрос, что не во всех SoC это IP присутствует.
  • Самое сложное в программировании это…
    0
    Могу предоставить только один случай, когда знание алгоритма вытеснения и протокола когерентности, реализованных в конкретном CPU, может помочь — если вы ищете баги в реализации контроллера кэша.
  • Самое сложное в программировании это…
    0
    Прикладным программистам надо знать размер кэшлайна, чтобы не допускать false sharing без необходимости. Системному программисту необходимо кроме того знать, в каких случаях железо не обеспечивает когерентность, чтобы при необходимости обеспечить её программно. Как поможет знание алгоритмов вытеснения и протоколов когерентности, реализованных в конкретном CPU, мне, честно говоря, непонятно.
  • Самое сложное в программировании это…
    –3
    Ну, как сказать, всё-таки это проблема разработчиков железа, программист на неё не влияет. Да и на некоторых задачах вытеснение случайной строки кэша бывает лучше для производительности чем всякие хитроумные алгоритмы.
  • Самое сложное в программировании это…
    –2
    Про цитату не знал. А касательно инвалидации, в силу специфики проектов, над которыми работаю, первая ассоциация — инвалидации процессорного кэша (ну, того, который L1, L2 etc). А в ней ничего сложного обычно нет. В любом случае, спасибо за разъяснение (-:
  • Самое сложное в программировании это…
    0
    Простите, может я не в теме. А что сложного в инвалидации кэша?
  • Загрузка ОС на ARM
    0
    В ARMv8 есть Secure Timer, который недоступен для OS (-:
  • Загрузка ОС на ARM
    0
    Cortex-A9 technical reference manual — это документ *на конкретную реализацию* процессора архитектуры ARMv7-A. Архитектурный документ называется «ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition». И если вы говорите об архитектуре, значит говорите именно в терминах этого документа.
  • Загрузка ОС на ARM
    0
    Если по существу, то Non-secure OS даже не должна специально дёргать TEE. TEE может на старте правильно настроить таймер и контроллер прерываний (он в ARM тоже няшка) и периодически получать управление. Non-secure OS даже не заметит (-:
  • Загрузка ОС на ARM
    0
    Ещё раз: это документ на реализацию конкретного IP, а не на архитектуру. Согласен, архитектура кэша в ARM красивая. Только описывается она в терминах Instruction cache и Data cache, а так же Point of Unification, Point of Coherency и Point of Persistency (для ARMv8.1-A), но ни как не L1 и L2.
  • Загрузка ОС на ARM
    0
    Статья мне в целом нравится, но это вопросы терминологии. Для тех, кто с этим работает, статья ничего нового и не расскажет. А для тех, кто не в теме, но интересуется, может внести некоторую путаницу. Поэтому, на мой взгляд, осторожней надо с терминами.
  • Загрузка ОС на ARM
    +1
    По поводу того, что архитектура ARM не позволяет включить L2 cache из Non-secure State. Давайте всё-таки будем точны в терминах: ARM-архитектура вообще не описывает кэш в терминах L1, L2 и тому подобных. Соответственно, архитектура и не может запрещать или разрешать включать или отключать кэш определённого уровня, это делается в документе на конкретную реализацию процессора. Например, в Cortex-A75 L2 кэш может включаться совсем не так, как это происходит в Cortex-A35, к примеру. А возможны и процессоры совсем без кэша.
  • Загрузка ОС на ARM
    +1
    Странно, что Cortex серии R отнесены к application-процессорам. Они всё-таки realtime-процессоры. У них нет mmu, вместо него используется memory protection unit. Ну, кроме процессоров архитектуры ARMv8-R, в которых ожидается и mmu и mpu (но на них ещё и документация-то не опубликована). Поэтому запуск linux на них хотя и возможен, мне не представляется целесообразным. Эти процессоры скорее подходят для RT OS, собственно для этого они и предназначены.
  • История предсказания переходов с 1 500 000 года до н.э. по 1995 год
    0
    Согласен. Только декодирование — процесс достаточно быстрый, и, соответственно, на out of order CPU о том, что инструкция является переходом, может быть известно сильно раньше, чем она реально начнёт исполняться. Что же касается двухстадийного конвейера, который нам упорно рисуют в статье, так в нём вообще можно обойтись без предсказания переходов — человечество изобрело такое понятие как delay slot.
  • История предсказания переходов с 1 500 000 года до н.э. по 1995 год
    0
    Современные процессоры не читают по одной инструкции — они гребут код, что называется, «большой лопатой». В частности, мне приходилось видеть CPU, который читает по 2 кэшлайна кода за такт.
  • История предсказания переходов с 1 500 000 года до н.э. по 1995 год
    +1
    Сорри, там не 'инвалид рожать', а инвалидировать. Это всё грёбаная автозамена в андроиде
  • История предсказания переходов с 1 500 000 года до н.э. по 1995 год
    0
    В случае x86 ни branch predictor ни кэш инвалид рожать не нужно. Что касается ARM, там инструкция branch predictor invalidate действительно присутствует, но с некоторых пор ничего не делает и оставлена в целях совместимости. Кэш же в ARM программист обязан инвалидировать в случае self-modified code, а именно, если код был перезаписан, программист обязан выполнить Data Cache Clean by VA at Point of Unification и Instruction Cache Invalidate by VA at Point of Unification. Связано это с тем, что в ARM кэш инструкций согласно архитектуре не является когерентным.
  • Почему я до сих пор использую Vim?
    +2
    В emacs есть evil-mode, режим, в котором он мимикрирует под vim. Так что есть там нормальный текстовый редактор (-:
  • Быстрое удаление пробелов из строк на процессорах ARM
    0
    Интересно было бы посмотреть, как эта задача решается с примирением ARM Scalable Vector Extension, только вот его в железе ещё нет )-:
  • Работа с гетерогенными контейнерами с C++17
    0
    Вопрос по reduce: а нельзя было использовать std::bind вместо лямбды?
  • Одинарная или двойная точность?
    0
    Под определение «дважды подряд выполнили операцию на одних и тех же исходных данных — получили разные результаты» скорее подойдёт термин «невоспроизводимый».
  • Одинарная или двойная точность?
    0
    Ну, не знаю, для меня 1.4 раза — это уже «весьма», особенно когда я наблюдаю, как народ борется за лишние 5% перфоманса.
  • Одинарная или двойная точность?
    0
    Чтобы быть более конкретным, в данном случае я исхожу из позиции Design Validation, когда процессорные инструкции оцениваются с точки зрения «для вот таких значений регистров на входе должно получиться строго конкретное значение результата, путём выполнения преобразований, описанных документацией».
  • Одинарная или двойная точность?
    0
    Нет, естественно, реальное железо это конечный автомат, в котором полностью непредсказуемого результата не будет — результат будет рассчитан по каким-то правилам. Но покуда эти правила не определены в архитектурной документации, результат называется непредсказуемым, на него нельзя закладываться пользователям, и это даёт RTL-дизайнерам пространство для оптимизации железа.
  • Одинарная или двойная точность?
    0
    Смещение может быть, а может и не быть, в зависимости от конкретной реализации FPU, и нигде это не описано точно для конкретной модели FPU. Это и называется «непредсказуемо». Другими словами, если в документации нет описания, позволяющего гарантированно точно рассчитать значение младшего бита в регистре после выполнения операции, значение этого бита в результате операции является непредсказуемым. То есть на конкретное поведение нельзя закладываться. Завтра Вы купите новый процессор, и в нём FPU будет реализован по-другому.
  • Одинарная или двойная точность?
    0
    В том и вопрос: производитель CPU совершенно открыто говорит: x87 это legacy. Не нужно его использовать без крайней необходимости.

    И да, я нигде не говорил о том, что x87 в разы медленнее, не надо мне приписывать чужих слов. Я говорил, что он просто медленнее, вы и сами это признали.
  • Одинарная или двойная точность?
    +2
    Пардон, ошибся, не ARMv8.1, а ARMv8.2.

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

    Я, конечно, не специалист в вычислениях, но в интернетах пишут, что half precision арифметика вполне неплохо показывает себя в задачах, связанных с deep learning. Так что, может быть не стоит считать, что нужны только double precision?
  • Одинарная или двойная точность?
    +1
    Ага, 64-битная архитектура ARMv8.1 с аппаратной виртуализацией — это очень встроенные решения. Осталось только понять, куда они встроены (-:
  • Одинарная или двойная точность?
    0
    На SSE есть ещё способ поднять performance — отказаться от обработки denormal, включив FTZ и DAZ, что заставит все denormal числа интерпретировать как нули. Как я понимаю, в x87 такой возможности нет.
  • Одинарная или двойная точность?
    0
    Что ж тогда ARM вообще half precision вычисления вводит в ARMv8.1? Они-то вообще на 16-битных числах.
  • Одинарная или двойная точность?
    0
    Да, и если уж речь зашла про Optimization reference manual, там тоже написано, что x87 может работать медленнее:
    Assembly/Compiler Coding Rule 63. (M impact, M generality) Use Streaming SIMD Extensions 2 or Streaming SIMD Extensions unless you need an x87 feature. Most SSE2 arithmetic operations have shorter latency then their X87 counterpart and they eliminate the overhead associated with the management of the X87 register stack.
  • Одинарная или двойная точность?
    0
    Относительно неточных вычислений, можно прочитать в «Intel® 64 and IA-32 Architectures Software Developer’s Manual», том 1, раздел 8.3.10, «Transcendental Instruction Accuracy»:

    The accuracy of these instructions is measured in terms of units in the last place (ulp).

    With the Pentium processor and later IA-32 processors, the worst case error on transcendental functions is less
    than 1 ulp when rounding to the nearest (even) and less than 1.5 ulps when rounding in other modes.


    Если это интерпретировать, получается, что младший бит в половине случаев будет неправильным. Чтобы он был правильным, необходима точность 0.5 ulp или лучше.
  • Одинарная или двойная точность?
    0
    Согласен, Intel публикует некоторые микроархитектурные данные. Только приведённая Вами таблица ничего не говорит об исполнительных устройствах. Она говорит, на какие порты scheduler может отправить микрооперацию конкретной группы. То есть, если x87 и AVX FP обрабатываются портом 0, это не значит, что за это отвечает одна и та же логика.

    И если посмотреть на что-нибудь свежее, типа Skylake (схема 2-1 приведённого Вами документа), то там вообще не говорится про x87 и MMX. Что может говорить о том, что обработка этих инструкций вытащена из общего пайплайна и лежит где-то сбоку. Это, как вы понимаете, не способствует производительности этих инструкций.
  • Одинарная или двойная точность?
    0
    Эммм…
    А что вы предлагаете использовать вместо float?
  • Одинарная или двойная точность?
    0
    Не может публично доступная документация Intel говорить о том, что SSE и x87 реализованы на одном и том же исполнительном устройстве. Это детали реализации, которые не раскрывает ни один разработчик CPU. Архитектурная документация описывает только то, каким будет результат вычислений, а не то, как он будет достигнут в железе.
  • Одинарная или двойная точность?
    +3
    Насколько я помню, SSE — это не только про SIMD, там есть и скалярные операции. Поэтому, собственно, нормальные компиляторы и не генерируют кода с инструкциями x87, если без этого можно обойтись.
  • Одинарная или двойная точность?
    0
    Что касается управления точностью: если особая точность не нужна, можно вообще включить режим denormal flush to zero. Работает в этом режим обычно пошустрее. Ну и в 32-битном ARM единственная возможность использовать векторизацию — это использовать single precision арифметику и denormal flush to zero.
  • Одинарная или двойная точность?
    +1
    В Intel 80-битная арифметика — это legacy 1980 года издания. Если процессор поддерживает наборы инструкций SSE и SSE2 (вообще все процессоры Intel начиная с Pentium 4), single и double precision floating point там считается гораздо быстрее, чем в формате 80bit x87. И расчёты в SSE/SSE2 происходят именно в 32-битном и 64-битном форматах. Почитайте что ли архитектурную документацию на досуге.
  • Одинарная или двойная точность?
    0
    Инструкции из набора x87 это legacy, в процессорах эти инструкции работают весьма медленно. И если нет требований именно к точности вычислений, лучше про них вообще забыть. Но выполнять точные вычисления на x87 это так себе занятие. В документации описаны ситуации, когда младший бит мантиссы результата принимает непредсказуемое значение. К сожалению, прямо сейчас я не смогу предоставить ссылку на конкретный раздел документации, но если интересно, завтра могу уточнить.
  • Про память, теги и когерентность
    0
    Ну, MIPS — вообще интересная архитектура. Там аппаратный Translation Table Walk является сильно опциональным с точки зрения архитектуры, если я не ошибаюсь.