-44 / 4 / 0
Регистрация: 22.09.2015
Сообщений: 217
1

ARM ассемблер

01.02.2019, 17:17. Показов 2179. Ответов 13
Метки нет (Все метки)

Приветствую уважаемые!
Есть тут те кто программирует на ARM ассемблере? Хочется пообщаться с такими специалистами. У которых можно узнать о том как устроена память, думаю архитектура отличается от x86. В каких адресах находятся векторы прерываний, видеобуфер и тд. Как можно на ассемблере вывести что-то на экран и тд. Литературы по ARM ассемблеру мало, в основном программирование микроконтроллеров. Интересна тема написания своей OS для этой платформы.
__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь
0
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
01.02.2019, 17:17
Ответы с готовыми решениями:

Ассемблер ARM
Только начал изучать ARM. Хотелось бы начать изучать с ассемблера, чтобы можно было "прощупать"...

Отладка ARM
Привет всем, надеюсь есть кто-нибудь кто с АРМмами работал. Хочу распробовать платформу, для начал...

new в С++ на GCC ARM C++
Доброго времени суток! Тут проблемка нарисовалась. Хочу завести С++ на своей платке - пока...

ARM S4LJ162X01
Есть нужда прошить по JTAG принтеры ML-2160, ARM S4LJ162X01 на ядре ARM926EJ-S. Так как мануалы и...

13
Почетный модератор
11253 / 4205 / 425
Регистрация: 12.06.2008
Сообщений: 12,135
02.02.2019, 01:53 2
Цитата Сообщение от pgb Посмотреть сообщение
В каких адресах находятся векторы прерываний
Зависит от архитектуры. Например, в CortexA9 есть таблица векторов, на которые процессор прыгает в случае исключений. Пример такой таблицы можно посмотреть, например, в исходниках U-Boot:
Assembler
1
2
3
4
5
6
7
8
ldr pc, _reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq
Процессор прерывает свою работу и прыгает на один из этих адресов в случае исключений. Одним из таких исключений является срабатывание прерывания (IRQ). Т.е. процессор переходит на позицию 6, а там инструкция перенаправляет его в функцию _irq, в которой обработчик прерывания обращается к контроллеру прерываний и узнаёт номер прерывания и в зависимости от номера переходит к обработке этого конкретного прерывания.
Например, пришли данные по UART. При этом блок UART вырабатывает прерывание, которое поступает на контроллер прерываний в процессор. Процессор прерывает свою текущую работу и прыгает в таблицу, а оттуда на глобальный обработчик прерываний (функция _irq), который узнаёт от контроллера прерываний, что источником прерывания был UART и прыгает в другую функцию - обработчик прерываний для UART.
В общем, для CortexA9 (думаю, что для всех CortexA) прерывания обрабатываются в обычных функциях, которые могут быть в любых адресах. Да и таблицу векторов тоже можно перемещать. Обычно изначально эта таблица находится в самом начале памяти, откуда исполняется программа. Т.е. при начале работы процессор первым делом попадает в начало этой таблицы (на обработчик _reset).
Но в других архитектурах могут быть отличия. Например, сейчас смотрю на CortexM3 - похоже, что там за такой таблицей сразу идёт таблица векторов внешних прерываний.

Цитата Сообщение от pgb Посмотреть сообщение
видеобуфер и тд
Зависит от конкретного чипа. За работу с видео отвечает не процессор, а отдельный блок, который нужно проинициализировать. Обычно во время инициализации этому блоку указывают адрес и размер памяти, откуда надо читать кадр. В общем, для этого нужно читать документацию на конкретный SoC. Такие вещи обычно пишут на Си.

Цитата Сообщение от pgb Посмотреть сообщение
Как можно на ассемблере вывести что-то на экран
Настроить блок, отвечающий за вывод видео на монитор и сформировать картинку в памяти. Но делать это на ассемблере - это извращение.

Цитата Сообщение от pgb Посмотреть сообщение
Интересна тема написания своей OS для этой платформы.
Можете посмотреть, как сделано в Linux или других ОС. Но я бы не советовал заморачиваться с ассемблером. На ассемблере обычно пишут самое начало (где требуется настраивать стек, переносить код), обработчики исключений, настройку процессора, работу с кешем и т.п. Остальные функции обычно пишут на Си. Код на ассемблере тяжелее читать и там проще допустить ошибку.
0
1944 / 1258 / 125
Регистрация: 04.01.2010
Сообщений: 4,545
02.02.2019, 16:25 3
Цитата Сообщение от Humanoid Посмотреть сообщение
Такие вещи обычно пишут на Си.
Да вы что? то есть людей которые таки пишут HAL и драйверы низкого уровня в природе не существует, да?

Цитата Сообщение от Humanoid Посмотреть сообщение
Настроить блок, отвечающий за вывод видео на монитор и сформировать картинку в памяти. Но делать это на ассемблере - это извращение.
ну вы даете . Это не извращение - в большинстве случаев использование хотя бы частичное, ассемблера просто неизбежно. На сегодняшний день компиляторы творят прямо чудеса, но по-прежнему, процентов 5-10 возможностей остается "за гранью возможностей". Может быть ИИ к этому подтянут - это будет круто тогда.

Цитата Сообщение от pgb Посмотреть сообщение
Хочется пообщаться с такими специалистами.
Что конкретно вас интересует? У ARM есть несколько разных платформ, и четко сформировать ответ не получится. В данном случае понимание ассемблера вам никак не ответит на остальные вопросы (потому что ассемблер ЦПУ один - а платформ сотни), а понимание "как вывести" никак не привязано к ассемблеру.

По АСМу, для примера, вот. Как появятся вопросы, будем вместе разбираться .
0
Почетный модератор
11253 / 4205 / 425
Регистрация: 12.06.2008
Сообщений: 12,135
03.02.2019, 17:25 4
Цитата Сообщение от Voland_ Посмотреть сообщение
Да вы что? то есть людей которые таки пишут HAL и драйверы низкого уровня в природе не существует, да?
Что бы обращаться к регистрам железа, ассемблер не нужен. Он только сильно усложнит код и поможет программисту допустить ошибку. Откройте любой драйвер устройства в Линуксе и вы там не найдёте ни одной ассемблерной строки. Ассемблер используется только в драйвере процессора и в функциях начальной инициализации.

Цитата Сообщение от Voland_ Посмотреть сообщение
ну вы даете . Это не извращение - в большинстве случаев использование хотя бы частичное, ассемблера просто неизбежно.
В том сообщении я написал, что ассемблер используется для начальной инициализации и ещё для нескольких функций. Но весь остальной код пишут без ассемблера. Для работы с железом нужно только работать с регистрами этого железа и обрабатывать прерывания. В любой нормальной ОС драйверы устройств всегда кроссплатформенные. А использование ассемблера не позволит сделать код кроссплатформенным. Для вывода видео на монитор ассемблер не нужен.
0
-44 / 4 / 0
Регистрация: 22.09.2015
Сообщений: 217
03.02.2019, 18:53  [ТС] 5
Цитата Сообщение от Voland_ Посмотреть сообщение
Как появятся вопросы, будем вместе разбираться
Возможно ли собрать из Linux ядро с графической оболочкой, а командную строку в виде интерпретатора написать свою, которая будет рисовать окна(через графическую библиотеку) и тд.? Никто не пробовал сделать что-то подобное?
0
1944 / 1258 / 125
Регистрация: 04.01.2010
Сообщений: 4,545
04.02.2019, 10:02 6
Цитата Сообщение от Humanoid Посмотреть сообщение
Что бы обращаться к регистрам железа, ассемблер не нужен. Он только сильно усложнит код и поможет программисту допустить ошибку. Откройте любой драйвер устройства в Линуксе и вы там не найдёте ни одной ассемблерной строки. Ассемблер используется только в драйвере процессора и в функциях начальной инициализации.
ну, я согласен что в большинстве случаев достаточно Си. Тут многое зависит от адаптации компилятора к процессору и архитектуре. Если проект позволяет иметь запас по производительности процентов 10-20%, то да - разницу вы не почувствуете. Но если вы хотите получить действительно 99% отдачу кода - придется писать на ассемблере. Да-да, тут не вопрос - что код перестанет быть масштабируемым, и чуть какие-то изменения - может привести к ошибке. Но на асме удается выжать то, чего не удастся выжать на текущем уровне компиляторов. Хотя, их возможности и правда - сильно поражают.

Я говорю не голословно - потому что допустим, я как-то столкнулся с реверсом проекта - нужно было дописать определенные изменения. В итоге, учитывая что места не было совсем - мне пришлось переписать часть кода на ассемблере, скомпиленный, очевидно, gcc. Получилось, что я таки сэкономил около 16байт и вставил нужный патч. В некоторой другой архитектуре поговаривали об 10%-тном избытке кода компилятора, по сравнению с тем, что хотелось бы видеть.

Цитата Сообщение от Humanoid Посмотреть сообщение
Для работы с железом нужно только работать с регистрами этого железа и обрабатывать прерывания.
Да щас ). ну а алгоритмы декодирования, потокового анализа, сжатия, сверток, фильтрации что - тоже на сях все пишут? . В одну из контор (не буду называть - имя известное) с меня хотели знание ассемблера кортексов, и я вам скажу - на должном уровне. И этому были вполне реальные задачи, на уровне как-раз низкоуровневом, там где если вы и хотите написать на сях - должны на 50% хотя бы быть уверенными, что именно сделает компилятор.

PS: я не берусь ничего доказывать - просто строю свои рассуждения на собственных наблюдениях. Надеюсь, вы не в обиде .
0
Почетный модератор
11253 / 4205 / 425
Регистрация: 12.06.2008
Сообщений: 12,135
04.02.2019, 21:28 7
Цитата Сообщение от Voland_ Посмотреть сообщение
В итоге, учитывая что места не было совсем - мне пришлось переписать часть кода на ассемблере, скомпиленный, очевидно, gcc. Получилось, что я таки сэкономил около 16байт и вставил нужный патч. В некоторой другой архитектуре поговаривали об 10%-тном избытке кода компилятора, по сравнению с тем, что хотелось бы видеть.
gcc умеет оптимизировать код либо для быстродействия, либо для экономии размера. Можно скомпилировать с ключом -Os тогда код получится существенно меньше, но, возможно, в ущерб производительности. А если собрать с -O3, то компилятор наплюёт на размер, но код будет более производительный. Я когда-то задумывался, смогу ли я улучшить код компилятора... пришёл к выводу, что не смогу. Только в одном месте нашёл кусок кода, где компилятор свалял дурака. Но это встречается очень редко. Понимаю, что у нас просто разные убеждения, но я не верю, что от -O3 можно увеличить производительность на 10-20%, как вы написали.

Цитата Сообщение от Voland_ Посмотреть сообщение
ну а алгоритмы декодирования, потокового анализа, сжатия, сверток, фильтрации что - тоже на сях все пишут?
Я говорю про ядро ОС. В виде драйверов такие алгоритмы редко встраивают. Хотя бы потому, что там большая морока с float'ами (на счёт всех архитектур не знаю, но на ARMе точно). Я сильно сомневаюсь, что вам удастся найти хотя бы один такой драйвер в Линуксе.

Цитата Сообщение от Voland_ Посмотреть сообщение
там где если вы и хотите написать на сях - должны на 50% хотя бы быть уверенными, что именно сделает компилятор.
С этим не спорю.

Цитата Сообщение от Voland_ Посмотреть сообщение
PS: я не берусь ничего доказывать - просто строю свои рассуждения на собственных наблюдениях. Надеюсь, вы не в обиде .
Никаких обид... наоборот - приятно, когда можно цивилизованно обсуждать какие-то вопросы. Но, думаю, всё равно, каждый останется при своём мнении

Цитата Сообщение от pgb Посмотреть сообщение
Возможно ли собрать из Linux ядро с графической оболочкой,
В Линуксе графическая оболочка не является частью ядра. Но, думаю, вам ничего не мешает написать её в виде драйвера.

Цитата Сообщение от pgb Посмотреть сообщение
а командную строку в виде интерпретатора написать свою, которая будет рисовать окна(через графическую библиотеку) и тд.?
Не дело командной строки рисовать окна. Не знаю, как правильно, но, думаю, менеджер окон, который рисует окна... его функции вызываются каким-то терминалом, что бы нарисовать себе окно. А уже терминал запускает интерпретатор, который использует уже готовое текстовое окно, в котором уже нет понятия пикселей, а есть только символы. Но это просто моё мнение.
0
1944 / 1258 / 125
Регистрация: 04.01.2010
Сообщений: 4,545
05.02.2019, 10:08 8
Цитата Сообщение от Humanoid Посмотреть сообщение
gcc умеет оптимизировать код
...в силу потребностей я много почерпнул из доков и по проектам, для gcc, спасибо. Да, в общем-то сопротивляться с компилятором последних версий стало практически невозможно - тем более, что теперь почти всегда можно сказать что конкретную оптимизацию можно было бы осуществить и средствами Си. Но если вы углублялись в программирование мелких АРМов, или вообще не АРМов, а "всякой мелочи", вроди PIC И AVR (ну, для примера), то увидели бы что адаптация кода нужна в том или ином варианте. В одной платформе нужно упирать на бит-бандинг, в другой - на условное выполнение инструкций (это просто для примера). В итоге код, как минимум, в критических местах может выглядеть немного иначе.

Да, на уровне уже ядра, ОСи, или даже математики - портируемый код вполне реален, в особенности, если система команд контроллера близка. Вы же сами вспомнили про float-библиотеки - вот и получается, что на одной системе написать код с использованием FP вполне реально, когда же для другой системы просто неэффективно - код-то выполнится, но "придется подождать". А если углубиться в каждую взятую отдельно архитектуру в имбеддед - разные типы памяти, разное время доступа, DMA, NVIC и т.д. - то окажется, что код вообще не портируем, и писать его придется на асме, чтобы не мучать зад.
Цитата Сообщение от Humanoid Посмотреть сообщение
Но, думаю, всё равно, каждый останется при своём мнении
вот-вот ).

PS: я же не говорю что писать на асме всю программу это панацея оптимального кода. Речь идет о том, что можно писать отдельные куски кода, которые будут выполняться гораздо быстрее будучи написанными на асме, но не на сях.

Вот вам наглядный пример:

Иногда для расчета чексуммы используется сумма всех байт данных с учетом переноса. Давайте возьмем какой-нибудь из ассемблеров и его Си, и попробуем решить эту задачу? ) Забегая вперед, я вам точно скажу, что эта задача будет решаться любым асмо-писателем с использованием флага переноса, которым в Си, увы, не воспользуешься так эффективно в данном случае.
0
Модератор
Эксперт по электронике
8569 / 6385 / 859
Регистрация: 14.02.2011
Сообщений: 22,214
05.02.2019, 10:46 9
Цитата Сообщение от Voland_ Посмотреть сообщение
которым в Си, увы, не воспользуешься так эффективно в данном случае.
и не надо пользоваться
хороший компилятор сам найдет оптимальный путь
работая с 80х86 и дизассемблируя сгенерированые коды,для пентиумов и выше, я ужасался какой фигни туда только компилятор не напихивает
но детально разбираясь выяснял, что код эффективнее, распараллеливание и прочие плюшки
например деление заменяет умножением с последующим сдвигом
моих знаний по предыдущим версиям камней для современных уже не хватало
в АРМ я практически даже не лезу, потому что логика уже совершенно другая
0
1944 / 1258 / 125
Регистрация: 04.01.2010
Сообщений: 4,545
05.02.2019, 18:26 10
Цитата Сообщение от ValeryS Посмотреть сообщение
хороший компилятор сам найдет оптимальный путь
Ага. Ну как обычно ). А если компилятор не находит оптимальный путь - значит он нехороший - ищите другой )).
Цитата Сообщение от ValeryS Посмотреть сообщение
но детально разбираясь выяснял
да, когда возможностей много - компилятор кажется шибко умным. Но в конкретных случаях ассемблерное написание нужных кусков ускоряет работу кода в несколько раз. Особенно если речь идет не о безразмерных ARM'ах, а о более-менее ограниченных в возможностях ядер 8051, и др. "мелочевке" с малым количеством регистров.
0
Модератор
Эксперт по электронике
8569 / 6385 / 859
Регистрация: 14.02.2011
Сообщений: 22,214
05.02.2019, 19:19 11
Цитата Сообщение от Voland_ Посмотреть сообщение
Но в конкретных случаях ассемблерное написание нужных кусков ускоряет работу кода в несколько раз.
хотелось бы конкретных примеров, а не общих рассуждений
бывает что и замедляет
вот например мой вопрос Конструкция, обнуляющая старшие биты
никто не дал ответ, сам потом разобрался
Цитата Сообщение от Voland_ Посмотреть сообщение
ядер 8051, и др. "мелочевке" с малым количеством регистров.
это 34 регистра то мало
0
1944 / 1258 / 125
Регистрация: 04.01.2010
Сообщений: 4,545
05.02.2019, 21:13 12
Цитата Сообщение от ValeryS Посмотреть сообщение
это 34 регистра то мало
да о чем вы? В 8051 два нормальных регистра - все остальные это просто временное хранилище переменных, чтобы не использовать стек, с косвенной адресацией.

Не по теме:

В AVR ситуация гораздо проще - 16 регистров из 32х можно юзать более-менее, некоторые залочены под косвенную адресацию (точнее - 3 пары) + первые два под доступ к памяти программ, и некоторым результатам (если правильно помню). Возьмем - Z80 - та же ерунда (A, B, DE, HL (по памяти) ). В x86/88 вы тоже не найдете их большое количество... Да, в ARM'ах по-проще (чем даже в AVR), но при этом при реверсе я не видел, чтобы компилятор что-то где-то хранил на постоянной основе. Разве что ноль в R0 для атомарного сравнения и инициализации других регистров в ноль простым копированием.

0
Модератор
Эксперт по электронике
8569 / 6385 / 859
Регистрация: 14.02.2011
Сообщений: 22,214
05.02.2019, 21:50 13
Цитата Сообщение от Voland_ Посмотреть сообщение
В 8051 два нормальных регистра
это A и B ??? тогда у 8086 вообще один- аккумулятор
как же 4 банка с R0-R7?
0
1944 / 1258 / 125
Регистрация: 04.01.2010
Сообщений: 4,545
06.02.2019, 00:31 14
Цитата Сообщение от ValeryS Посмотреть сообщение
как же 4 банка с R0-R7?
ниняю, я в 8051 не разбираюсь ). А что с 4й банкой?
Инфу взял отсель https://www.elprocus.com/know-... ontroller/

За что купил - за то продаю .
0
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
06.02.2019, 00:31

телефон с arm
Хотел бы спросить у знающих, есть ли какой нибудь телефон с ARM которым можно было бы легко...

ядра arm
поделитесь успехом использрвания тех или ных мк под разными ядрами... вы как выбираете мк?...

Скриптинг в ARM
Здатуте, вообще неохотно стал интересоваться ARM-ами, после AVR. С другой стороны ресурсы весьма...

ARM с Linux
День добрый Поковырялся с AVR на Pinboard. Помучался с STM32Dyscovery. И так как я больше...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
14
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2022, CyberForum.ru