Для arm7 что это
Немного о архитектуре процессоров ARM7TDMI
В последнее время я часто встречаю о самых разных устройствах, работающих на процессорах с архитектурой ARM. В этой статье я хочу начать рассказ о архитектуре процессоров ARM7TDMI (не путать с ARMv7). ARM7TMI — это довольно таки устаревшее семейство, но оно довольно таки широко используется в разных embedded устройствах. Так как моя работа очень плотно связанна с разработкой таких устройств — то я довольно неплохо ориентируюсь именно в этом семействе. Но если кому-то будет интересно — могу рассказать и о более новых семействах ARM.
Общее описание
Надо сказать, что ARM — это просто архитектура, на основании которой построено множество разных процессоров. У них может быть совершенно разная периферия, разные методы взаимодействия с периферией, разная частота и энергопотребление, но объединяет их одно — процессорное ядро ARM.
ARM7 с одной стороны довольно таки прост (особенно по сравнению с x86), с другой стороны — имеет большую производительность и меньшее энергопотребление. Но меньший набор команд и тот факт, что длинна команды фиксирована приводит к увеличению объема программ.
Отличия от x86
Надеюсь, многие из читающих эту статью хотя бы в общих чертах знают архитектуру x86 🙂
Чем же ARM7 отличается от x86?
Регистры
ARM имеет 32 регистра длинной 32 бита. На самом деле одновременно доступно только 16 из них. Остальные регистры переключается вместе с режимами процессора. Все регистры совершенно одноправны (сравните с x86, где даже регистры общего назначения имеют разные свойства). Правда один из регистров, r15, используется как счетчик инструкций (program counter), у него даже есть псевдоним — pc. Так что очевидно, что его не стоит использовать в качестве регистра общего назначения 🙂
Другой регистр, r14 используется как указатель стека (stack pointer) и имеет псевдоним sp. Но его никто не мешает использовать как обычный рабочий регистр, если вам вдруг совершено не нужен стек. Хотя и это и не рекомендуется.
Третий регистр, r13 по соглашению хранит адрес возврата из текущей функции. Точно и как и предыдущий регистр его можно использовать как рабочий.
Остальные 13 регистров программист (правда, чаще — компилятор) может использовать как хочет.
Плюс, есть ещё 2 выделенных регистра состояния процессора. На самом деле один и тот же регистр, просто одна его ипостать содержит сохраненные данные после переключения режима.
Режимы работы
Процессор может работать в 7 разных режимах: User, FIQ, IRQ, Supervisor, Abort, System, Undefined. 4 из этих режимов (FIQ, IRQ, Undefined, Abort) слушат для обработки исключительных операций — обработка быстрого прерывания, обработка обычного прерывания, попытка выполнить неизвестную инструкцию, попытка обратиться к несуществующей области памяти (или по невыровненому адресу). Режимы Abort и Undefined позволяют сделать эмуляцию инструкций сопроцессора и добавить поддержку виртуальной памяти соответственно.
Остальные три режим служат для защиты операционной системы от прикладных программ.
Любопытно что все режимы (кроме System) имеют свои регистры r13 и r14. Таким образом при переключении режимов нет надобности сохранять значения вершины стека и адрес возврата.
Набор команд
Прочее
В общем, если кому-то будет интересно — могу рассказать подробнее об АРМах, конкретно о процессоре AT91SAM7x, о embedded разработке вообще и в частности.
Определение типа архитектуры процессора Android-устройств
Часто при загрузке Андроид-приложений на сайтах предлагающих такую возможность, у пользователей есть возможность выбора файлов для различных архитектур системы. И тут возникают сложности — какую из загрузок нужно скачивать и устанавливать.
Архитектура процессора — это, простыми словами, схема по которой работают части процессора между собой, а также набор команд с помощью которых они «общаются» с другими частями устройства.
Многие разработчики делают универсальные приложения и игры, которые подходят под любые архитектуры процессоров. Но некоторые из них создают несколько версий программ специально «заточенных» под ту или иную архитектуру. При установке такого продукта из Google Play, сервис автоматически определяет все необходимые параметры установки и загружает на пользовательское устройство необходимые файлы. Пользователю не нужно думать над тем какой файл скачать.
Если же установка (по той или иной причине) из Google Play невозможна или нежелательна, пользователь может скачать файл APK на стороннем сайте. С его помощью можно установить приложение или игру «в ручном режиме». Вот тут-то, если на сайте есть несколько вариантов таких файлов, и появляются муки выбора.
На сегодняшний день, сайты предлагающие файлы для установки приложений и игр могут распространять APK-файлы следующих архитектур: armeabi-v7a, arm64-v8a, x86 и x86_64.
Ниже мы несколько более детально рассмотрим разные типы архитектуры для Android-устройств. Вы можете пропустить этот блок и перейти к следующему, но все-таки мы бы рекомендовали ознакомиться с этой информацией для более ясного понимания.
Файлы начинающиеся на «x86» и «arm» не являются взаимно совместимыми — вы должны использовать версию, предназначенную для конкретной архитектуры устройства.
Также, если ваш девайс имеет 32-разрядный процессор, 64-разрядный файл на нем работать не будет. А вот 64-разрядные процессоры обратно совместимы, поэтому на него можно устанавливать 32-разрядный файл.
Исходя из вышесказанного, можно составить такие правила совместимости:
В большинстве случаев телефоны используют архитектуру ARM. Более дешевые устройства используют версию armeabi-v7a, более мощные — версию arm64-v8a. Поэтому, если сомневаетесь в том, какую версию файла выбрать, выбирайте ту, которая имеет отметку «armeabi-v7a».
Определение архитектуры процессора устройства
Теперь, когда мы разобрались с теоретической частью, пора определить — на какой архитектуре разработан ваш телефон или планшет.
Для этого можно воспользоваться инструкцией к устройству (но в ней не всегда можно найти нужную информацию) или же найти данные в интернете. Но лучше всего это сделать с помощью специального приложения.
Самый простой способ!
Droid Hardware Info
Если вышеописанный способ вас чем-то не устраивает или же вы хотите получить более расширенные данные о системе вашего устройства, воспользуйтесь приложением Droid Hardware Info.
Установите эту утилиту в Google Play или с помощью APK-файла (скачав его на сайте Biblprog). Для получения нужной нам информации запустите Droid Hardware Info, перейдите на вкладку «Система» и обратите свое внимание на раздел «Процессор».
Как вам данная инструкция? Все ли понятно? Если у вас появились дополнительные вопросы или же возникли замечания к информации выложенной на данной странице — не стесняйтесь. Напишите в комментариях!
Русские Блоги
Android arm64-v8a, armeabi-v7a, armeabi, x86 подробное объяснение
Недавно при упаковке с флаттером я столкнулся с ситуацией, когда упаковка не могла быть напечатана. Я долго проверял причину и обнаружил, что это было вызвано отсутствием конфигурации руки. После того, как она была экипирована, она разыгралась. Я воспользовался этой возможностью, чтобы изучить abi с нуля.
перед началом
Прежде чем начать, вам нужно знать lib, libs и т. Д.
1. lib и libs
Ссылки на те, что помещены в lib, включены в библиотеки.
Файлы, помещенные в библиотеки, будут автоматически включены редактором. Так что не ставьте API в библиотеках.
Содержимое библиотеки lib не будет упаковано в APK, содержимое библиотеки li будет упаковано в APK
Введение в архитектуру
Нет картины без правды: 
Существует только один неизвестный телефон с операционной системой Android 4.3, который использует архитектуру v7. 
Для 64-битных телефонов и 64-битных процессоров
Поскольку новый 64-разрядный процессор в настоящее время включает в себя две архитектуры, а технология процесса не была улучшена (28 нм), в то же время на мобильных телефонах и планшетах площадь чипа строго ограничена и не может быть чрезмерно увеличена, что приводит к среднему распределению 64-разрядных процессоров ARM. Количество транзисторов в каждой архитектуре резко сократилось, то есть из 32-разрядной архитектуры 64-разрядных процессоров для 32-разрядных процессоров с одинаковыми характеристиками они не только не улучшились, но и производительность снизилась в определенном масштабе. Однако производители процессоров должны объяснить потребителям, как лучше продвигать 64-разрядные системы, поэтому производители должны повысить производительность в других аспектах, чтобы компенсировать потери, вызванные сокращением числа транзисторов ЦП. Например: замените более мощный графический процессор, увеличьте пропускную способность памяти, многоядерный виртуальный одноядерный для повышения производительности одноядерного, совместные поставщики программного обеспечения для работы, чтобы изменить веса работы (повысить оценку GPU, снизить вес процессора) и т. Д. Таким образом, приобретая сильные стороны и избегая недостатков и, наконец, попадающих в руки потребителей, они работают с запущенным программным обеспечением, оно действительно улучшилось, пользователи довольны, карманы производителя также выпирают.
Таким образом, битовый процессор ARM64 более точно называется ARM32 + 64 в строгом смысле слова. По сравнению с битовым процессором ARM32, он имеет место для регресса и возможности для улучшения, но именно из-за регрессии, который стимулировал прогресс ARM Определено, что он внесет смелые и смелые изменения, и это должно быть улучшением. Но действительно ли ARM64 полезен для мобильных телефонов? Я могу только сказать, что это действительно бесполезно в данный момент, но это может произойти в будущем. (Собранный в другом месте) Таким образом, в строгом смысле ARM64-битный процессор более точно называется ARM32 + 64. По сравнению с ARM32-битным процессором он имеет некоторые недостатки и возможности для улучшения, но это из-за Эта регрессия подтолкнула ARM к решимости добиться прогресса, что позволило ему внести радикальные изменения, что, по-видимому, является улучшением. Но действительно ли ARM64 полезен для мобильных телефонов? Я могу только сказать, что это действительно бесполезно в данный момент, но это может произойти в будущем. (Искал в другом месте)
Однако Google официально объявил об обязательной 64-битной архитектуре в начале этого года.： 
Еще в январе этого года (2019 г.) Google выпустил уведомление о том, что с 1 августа этого года перечисленные приложения, помимо предоставления 32-разрядных версий, также должны предоставлять 64-разрядные версия.
Следовательно, больше невозможно принудительно использовать только архитектуру armeabi перед проектом.
Что конкретно означает поддержка 64-битной версии?
Если ваше приложение написано полностью на Java или Kotlin и не содержит никакой встроенной поддержки, то это означает, что приложение уже поддерживает 64-битную версию.
Однако в приложении используется любая встроенная поддержка (например, библиотека), поэтому вам необходимо обеспечить разные версии поддержки этих файлов и разных архитектур ЦП.
Следует отметить, что иногда в нашем собственном коде встроенная поддержка действительно не используется, но в нее включены некоторые сторонние библиотеки, используемые в приложении.
В настоящее время наиболее надежным способом является анализ файла APK, созданного окончательной упаковкой, для определения необходимости обеспечения поддержки 64-разрядной архитектуры.
Конфигурация упаковки
Трещина
Эта команда может быть заключена в соответствии с различными правилами, такими как abi, плотность экрана (например, ldpi, hdpi и т. д.)
Включить включено, а исключить не включено. Каждый элемент, включенный в конфигурацию, будет генерировать пакет apk.
Фильтр ndk
Эта инструкция может быть настроена для упаковки только той библиотеки, которую вы настраиваете, и она не будет упакована, если она не настроена, что очень гибко.
Эта конфигурация упакует библиотеку so из трех пакетов armeabi, armeabi-v71, arm64-v8a в apk, в отличие от split, которая будет воспроизводить apk для каждого пакета.
Конец эпохи ARMv7 или же немного о портировании игр
Вступление
Разбор apk
Итак, что такое .apk? APK файл представляет из себя немного модифицированный ZIP архив, который содержит ресурсы игры и игровой движок. Выглядит он примерно так:
Папка lib — ключевая точка при переносе между архитектурами. Она содержит библиотеки движка нашей игры.
* armeabi — armv6 библиотеки (не актуально)
* armeabi-v7a — armv7 библиотеки (при отсутствии папки — отсутствует и поддержка архитектуры)
* arm64-v8a — armv8 x64 библиотеки
Перенос
Шаг #1
Первым делом нам нужно узнать, возможно ли портировать игру. Для этого нужно определить движок игры. К примеру, файл lib/libunity.so — принадлежит Unity Engine, а по наличию папки assets/x-renpy можно догадаться, что игра разработана на RenPy Engine. Если у игры движок не является собственным, то переходим к шагу два.
Шаг #2
Шаг #3
Мы нашли подходящего донора, теперь нам нужно добавить папку lib/armeabi-v7a в наш (name).apk. Добавляем и видим следующее:
В самом начале, как я уже сказал, APK файл представляет из себя немного модифицированный ZIP архив, а после изменения его содержимого он становится обычным ZIP’ом.
Шаг #4
Для того, чтобы ваше устройство могло установить ваш (name).apk файл, его нужно «подписать». Для этого есть несколько различных утилит, к примеру apk-signer.
Шаг #5
Будь добрым человеком, выложи свой порт для общего пользования, к примеру, в топик игры на том же 4PDA. 😉
ARM7TDMI-S (ARMv4T) vs. Cortex-M3 (ARMv7-M)
Уже добрый десяток лет на рынке представлено множество микроконтроллеров на ядре ARM7TDMI. Это довольно мощное ядро для однокристальных решений. Оно имеет разрядность 32 бита и частоту работы до 100МГц, мало того, ядро однотактовое, т.е. некоторые инструкции исполняются за 1 такт (преимущественно операции с регистрами, без обращений к внешним шинам процессора). Ядро ARM7TDMI на голову превосходит по вычислительным возможностям все 8-ми и 16-ти битные чипы (AVR, MSC-51, PIC12/PIC16/PIC18/PIC24, MSP430, etc).
Однако, относительно недавно, компания ARM представила новое семейство ядер Cortex, нас будет интересовать его разновидность Cortex-M3, которая предназначается как раз для замены ARM7TDMI в нише однокристальных решений.
Работать с чипами NXP LPC1300, а точнее LPC1343, основанных на ядре Cortex-M3, мне посчастливилось сразу после их официального выхода. Сейчас под них уже перенесена пара проектов. И скажу Вам, как «матерый» программист под ARM: они мне очень понравились, хотя и имеют свои приколы в архитектуре.
Итак, Cortex-M3 призван заменить ARM7TDMI. При его разработке ARM Ltd. ставила перед собой целью без существенного усложнения логики схем процессора нарастить функционал, добавить полезные инструкции, увеличив тем самым плотность кода и производительность. Из-за этого пришлось пойти на беспрецедентный шаг: впервые ядро ARM несовместимо по бинарному коду с предыдущими семействами. Собственно это произошло по той причине, что Cortex-M3 не умеет исполнять 32-битный код ARM.
Все предыдущие ядра имели 2 режима работы и в каждом из них был свой набор команд. Эти режимы назывались ARM и Thumb. Первый работал с 32-битным полным набором инструкций, а 2ой с упрощенным набором 16-битных инструкций. На самом деле ядро всегда исполняло ARM-код, однако в Thumb-режиме подключался некий дешифратор, который налету «мапил» 16 битные инструкции в их 32-битные аналоги.
В Cortex-M3 отказались от 32-битного кода как класса. В семействе Cortex присутствуют еще несколько ядер (Cortex-M0,M1,A0-A3). M3 располагается посередине. M0,M1 — еще сильнее упрощены, а вот A-серия наоборот предназначена для тяжелых и высокопроизводительных приложений, и нее возможность исполнения ARM-кода убирать не стали.
Массивность и низкая плотность кода — большая проблема ARM-ядер, 32 бита на любую операцию дают о себе знать, плюс невозможно закодировать в инструкции константу более 1 байта. Именно из-за этого и введен дополнительный набор инструкций Thumb. Он обеспечивает большую плотность кода (в среднем выигрыш 20-30%), хоть и принося в жертву 5-10% производительности.
В Cortex идея Thumb кода была развита. Набор 16-битных инструкций Thumb был расширен, набор инструкций обозвали Thumb-2. При компиляции в него падение производительности (по сравнению с чистым ARM-кодом) составляет лишь единицы процентов, а вот экономия по объему все те же 20-30%.
Отдельного внимания в наборе Thumb-2 заслуживают такие высокоуровневые инструкции как IT (конструкция с ее применением представлена ниже), вообще, система команд просто напичкана «фичами», призванными повысить оптимизацию при компиляции Си-кода. Итак, конструкция на Thumb-2:
CMP r0, r1
ITE EQ ; if (r0 == r1)
MOVEQ r0, r2 ; then r0 = r2;
MOVNE r0, r3 ; else r0 = r3;
Нечто похожее, можно сделать и в наборе инструкций ARM:
CMP r0, r1 ; if (r0 == r1)
MOVEQ r0, r2 ; then r0 = r2;
MOVNE r0, r3 ; else r0 = r3;
А в чистом Thumb придется несколько «извратиться»:
Хотя если посчитать объемы, то получим, что в случае Thumb конструкция займет 2*5 = 10 байт, на Thumb-2 объем будет 2*4 = 8 байт, на ARM целых 4*3 = 12 байт (хоть и имеет всего 3 инструкции).
Однако, компилятору Keil RealView MDK именно эта хваленая инструкция IT, видимо, неизвестна, так как при изучении генерируемых листингов найдена не была, да и визуально ассемблерный код на выходе из компилятора все-таки больше похож на обычный Thumb. Толи сами исходники специфичные, то ли компилятор на самом деле пока «не допилили» под новое ядро и систему команд. На счет других компиляторов информацией, к сожалению, не обладаю, хотя не плохо было бы посмотреть что генерирует GCC.
Вообще, рекламируется просто бешеная оптимизация кода, якобы итоговый размер будет на 30-50% меньше чем у того же самого исходника, скомпилированного под 8 и даже 16-битный микроконтроллер (к примеру, в документе представленном по первой ссылке в конце статьи). Скажу сразу: это несколько подтасованные результат, он верен только для 32-битного кода, т.е. кода на Си с обилием операций с переменными int, long, а так же большим количеством вычислений (под данные требования хорошо подходит, к примеру, знаменитый тест Dhrystone). Если же переносить код предварительно писавшийся и оптимизированный под 8 бит, то при переносе на 32-битный процессор будет наоборот увеличение размера бинарного кода, по моему опыту код увеличивается по объему чуть ли не в 1.5-2 раза.
Еще одним существенным нововведением в Cortex-M3 явилось добавление команды деления. ARM-ядра с древних времен имеют в своем составе операции умножения (с 64 битным результатом) и умножения с накоплением (так же 64 битный результат). Теперь же к ним добавилась инструкция деления. Конечно, тактов она скорее всего отжирает немало, однако, все-равно это намного быстрее чем отдельная подпрограмма. Как бы это не казалось парадоксальным высокоуровникам и людям далеким от микроконтроллеров: аппаратное деление до сих пор редкость в однокристальных системах (про различные наборы инструкций плавающей арифметики и прочие сопроцессоры и вовсе говорить не приходится, они доступны только в самых тяжелых монстрах, заточенных под мультимедиа).
В отличие от ARM7TDMI у Cortex Гарвардская архитектура памяти (раздельные шины команд и данных). В том же AVR это доставляет определенные неудобства и при программировании следует пользоваться некоторыми макросами компилятора и специфичными функциями, чтобы const-переменные не попадали в ОЗУ. Здесь же (так собственно было во всех ARM после ARMv4, таких как ARM9, ARM11) при программировании отдельные шины не ощущаются, внутри кристалла они все-равно объединяются в единое адресное пространство. Все чипы ARM имеют 32-битное линейное адресное пространство размером в 4Гб (для программистов x86, это соответствует модели памяти flat), в нем размешаются все адреса периферии, ПЗУ и ОЗУ.
Примечание (1): Несмотря на все преимущества, именно огромное адресное пространство является существенной бедой при оптимизации кода: мы имеет 32-битную адресацию, в инструкциях ARM/Thumb и даже Thumb-2 нельзя непосредственно закодировать полный адрес некоего объекта, поэтому адрес кладется в виде данных внутрь кода, а затем достается отдельной инструкцией. Это так же отрицательно сказывается на объеме кода. К примеру, в MSC-51 для чтения переменной из ОЗУ может хватить 2х байт, в ARM же придется хранить минимум 2 байта самой инструкции и 4 байта непосредственно задействовать под хранение адреса.
Примечание (2): всегда хотел попробовать разместить в периферийном регистре код (к примеру, инструкцию возврата) и передать ему управление, пронаблюдав за реакцией ядра. На ARM7TDMI этот трюк может прокатить из-за Фон-Неймановской организации памяти, а вот Cortex с его Гарвардом почти наверняка пошлет в далекие края, свалившись в один из абортов.
Следующее существенное отличие: один стек. Если в ARM7TDMI для разных режимов ядра (речь не о ARM/Thumb, а о режимах в которые процессор переключается при входе в прерывания и для обработки исключений) выделялись отдельные стеки, то здесь имеется только один стек. Не знаю как к этому относиться, в теории это менее гибко, но на практике чертовски удобно. Экономится ОЗУ так как не надо резервировать кучу стеков, упрощается логика вложенных прерываний и реализации системных вызовов (попробуйте на ARM7TDMI сделать системный вызов через программное прерывание SWI с числом параметров более 4х, такой огород потребуется, тут тоже огород, но проще). К тому же, за счет этого были уменьшены задержки входа и выхода из прерываний, а так же переключения между прерываниями.
Второе изменение, позволившее ускорить обработку прерываний — это отказ от VIC. Да, нет больше монстра под названием VIC (векторный контроллер прерываний). Да, это опять шаг от гибкости к простоте, но в микроконтроллерной системе случай, когда надо налету переназначать обработчики прерываний редкость, проще написать свой велосипед для этого, чем в каждом проекте заниматься настройкой VIC-а. Тем более есть возможность разместить таблицу прерываний в ОЗУ и уже в нем спокойно менять адреса обработчиков.
Вместо VIC теперь имеем NVIC и кучу векторов прерываний в начале FLASH. Если в ARM7TDMI вектора прерываний занимали 32 байта в начале, то здесь несколько сотен байт отведено на прерывания от различных устройств. Мало того, теперь это не инструкции прыжков, а реальные вектора с адресами. Т.е. ядро не передает управление по адресу в таблицу прерываний, а делает выборку адреса по нужному смещению и передает по нему управление, с позиции программиста это удобнее, красивее и прозрачнее.
Но основной сюрприз — это первые 2 вектора прерываний. Думаете Reset и еще что-то? НЕТ! По 0-му адресу лежит… значение стека, оно аппаратно заносится ядром в регистр стека при сбросе. А по смещению 4 — адрес точки входа. Что же это дает? А вот что: мы можем сразу начать исполнение программы с Си-кода без предварительных инициализаций. Конечно, в этом случае придется вручную скопировать в ОЗУ секцию RW и обнулить ZI (если совсем отказаться от помощи компилятора).
Такая явная Си-ориентированность заметна и по примерам проектов для Cortex. Все инициализации перенесены из ассемблера в Си. Из-за отказа от множества стеков стало ненужным инициализировать их в самом начале. Заодно и прочие инициализации перекочевали в Си-код.
Еще интересны отличия в системе команд: добавлены высокоуровневые инструкции WFI (wait for interrupt), WFE (wait for event) и прочие, упрощающие создание многопоточных приложений и операционных систем. В наборе представлены инструкции, предназначенные для многопроцессорных систем, это наводит на мысль, что скоро может произойти выход в свет многоядерных однокристальных решений.
Примечание: Хоть многоядерные микроконтроллеры и существуют в виде того же Parallax Propeller (он имеет аж 8 32-битных ядер), но полноценным и годным в коммерческом применении (а не для любительских поделок), его назвать нельзя.
Так же в описании ядра Cortex-M3 добавлен 1 таймер. Таймер простой, умеет генерировать прерывание с определенной периодичностью, однако, к примеру, для ядра операционной системы большего и не требуется.
Примечание: таймер в описании ядра — очень полезная и важная вещь. Так как он описан в документации на ядро и фактически является частью лицензируемого ядра, все производители будут вносить его в свои чипы, а главное у всех он будет иметь одинаковую реализацию. Это очень полезно для совместимости кода: не требуется писать модули поддержки для кучи реализаций таймеров у различных производителей (как это обстоит с ARM7TDMI). Однако, дополнительные таймеры, каждый производитель все-равно будет реализовывать на свой лад, но уже бы один стандартный — яляется хорошим шагом в сторону универсальности.
В заключение стоит сказать, что в документации на ядро так же описан модуль MPU (Memory Protection Unit). Очень полезная вещь в сложных устройствах, когда работает несколько потоков и очень не хочется нарушения работы всей микропрограммы из-за сбоя в каком-либо отдельном потоке. Однако, данный модуль является опциональным и производители чипов встраивать его не спешат. Даже в старшем семействе NXP LPC1700 он отсутствует. У прочих производителей так же замечен не был. Все-таки защита памяти, не говоря о виртуальной памяти, пока остается уделом дорогих и больших монстров.