-129 / 8 / 0
Регистрация: 22.09.2015
Сообщений: 428
|
|
1 | |
ARM ассемблер01.02.2019, 17:17. Показов 2829. Ответов 13
Метки нет Все метки)
(
Приветствую уважаемые!
Есть тут те кто программирует на ARM ассемблере? Хочется пообщаться с такими специалистами. У которых можно узнать о том как устроена память, думаю архитектура отличается от x86. В каких адресах находятся векторы прерываний, видеобуфер и тд. Как можно на ассемблере вывести что-то на экран и тд. Литературы по ARM ассемблеру мало, в основном программирование микроконтроллеров. Интересна тема написания своей OS для этой платформы.
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
0
|
|
01.02.2019, 17:17 | |
Ответы с готовыми решениями:
13
Ассемблер ARM Отладка ARM new в С++ на GCC ARM C++ ARM S4LJ162X01 |
Почетный модератор
11293 / 4262 / 436
Регистрация: 12.06.2008
Сообщений: 12,279
|
||||||
02.02.2019, 01:53 | 2 | |||||
Зависит от архитектуры. Например, в CortexA9 есть таблица векторов, на которые процессор прыгает в случае исключений. Пример такой таблицы можно посмотреть, например, в исходниках U-Boot:
Например, пришли данные по UART. При этом блок UART вырабатывает прерывание, которое поступает на контроллер прерываний в процессор. Процессор прерывает свою текущую работу и прыгает в таблицу, а оттуда на глобальный обработчик прерываний (функция _irq), который узнаёт от контроллера прерываний, что источником прерывания был UART и прыгает в другую функцию - обработчик прерываний для UART. В общем, для CortexA9 (думаю, что для всех CortexA) прерывания обрабатываются в обычных функциях, которые могут быть в любых адресах. Да и таблицу векторов тоже можно перемещать. Обычно изначально эта таблица находится в самом начале памяти, откуда исполняется программа. Т.е. при начале работы процессор первым делом попадает в начало этой таблицы (на обработчик _reset). Но в других архитектурах могут быть отличия. Например, сейчас смотрю на CortexM3 - похоже, что там за такой таблицей сразу идёт таблица векторов внешних прерываний. Зависит от конкретного чипа. За работу с видео отвечает не процессор, а отдельный блок, который нужно проинициализировать. Обычно во время инициализации этому блоку указывают адрес и размер памяти, откуда надо читать кадр. В общем, для этого нужно читать документацию на конкретный SoC. Такие вещи обычно пишут на Си. Настроить блок, отвечающий за вывод видео на монитор и сформировать картинку в памяти. Но делать это на ассемблере - это извращение. Можете посмотреть, как сделано в Linux или других ОС. Но я бы не советовал заморачиваться с ассемблером. На ассемблере обычно пишут самое начало (где требуется настраивать стек, переносить код), обработчики исключений, настройку процессора, работу с кешем и т.п. Остальные функции обычно пишут на Си. Код на ассемблере тяжелее читать и там проще допустить ошибку.
0
|
1961 / 1275 / 130
Регистрация: 04.01.2010
Сообщений: 4,607
|
|
02.02.2019, 16:25 | 3 |
Да вы что?
![]() ![]() ну вы даете ![]() Что конкретно вас интересует? У ARM есть несколько разных платформ, и четко сформировать ответ не получится. В данном случае понимание ассемблера вам никак не ответит на остальные вопросы (потому что ассемблер ЦПУ один - а платформ сотни), а понимание "как вывести" никак не привязано к ассемблеру. По АСМу, для примера, вот. Как появятся вопросы, будем вместе разбираться ![]()
0
|
Почетный модератор
11293 / 4262 / 436
Регистрация: 12.06.2008
Сообщений: 12,279
|
|
03.02.2019, 17:25 | 4 |
Что бы обращаться к регистрам железа, ассемблер не нужен. Он только сильно усложнит код и поможет программисту допустить ошибку. Откройте любой драйвер устройства в Линуксе и вы там не найдёте ни одной ассемблерной строки. Ассемблер используется только в драйвере процессора и в функциях начальной инициализации.
В том сообщении я написал, что ассемблер используется для начальной инициализации и ещё для нескольких функций. Но весь остальной код пишут без ассемблера. Для работы с железом нужно только работать с регистрами этого железа и обрабатывать прерывания. В любой нормальной ОС драйверы устройств всегда кроссплатформенные. А использование ассемблера не позволит сделать код кроссплатформенным. Для вывода видео на монитор ассемблер не нужен.
0
|
-129 / 8 / 0
Регистрация: 22.09.2015
Сообщений: 428
|
|
03.02.2019, 18:53 [ТС] | 5 |
Возможно ли собрать из Linux ядро с графической оболочкой, а командную строку в виде интерпретатора написать свою, которая будет рисовать окна(через графическую библиотеку) и тд.? Никто не пробовал сделать что-то подобное?
0
|
1961 / 1275 / 130
Регистрация: 04.01.2010
Сообщений: 4,607
|
|
04.02.2019, 10:02 | 6 |
ну, я согласен что в большинстве случаев достаточно Си. Тут многое зависит от адаптации компилятора к процессору и архитектуре. Если проект позволяет иметь запас по производительности процентов 10-20%, то да - разницу вы не почувствуете. Но если вы хотите получить действительно 99% отдачу кода - придется писать на ассемблере. Да-да, тут не вопрос - что код перестанет быть масштабируемым, и чуть какие-то изменения - может привести к ошибке. Но на асме удается выжать то, чего не удастся выжать на текущем уровне компиляторов. Хотя, их возможности и правда - сильно поражают.
Я говорю не голословно - потому что допустим, я как-то столкнулся с реверсом проекта - нужно было дописать определенные изменения. В итоге, учитывая что места не было совсем - мне пришлось переписать часть кода на ассемблере, скомпиленный, очевидно, gcc. Получилось, что я таки сэкономил около 16байт и вставил нужный патч. В некоторой другой архитектуре поговаривали об 10%-тном избытке кода компилятора, по сравнению с тем, что хотелось бы видеть. Да щас ). ну а алгоритмы декодирования, потокового анализа, сжатия, сверток, фильтрации что - тоже на сях все пишут? ![]() PS: я не берусь ничего доказывать - просто строю свои рассуждения на собственных наблюдениях. Надеюсь, вы не в обиде ![]()
0
|
Почетный модератор
11293 / 4262 / 436
Регистрация: 12.06.2008
Сообщений: 12,279
|
|
04.02.2019, 21:28 | 7 |
gcc умеет оптимизировать код либо для быстродействия, либо для экономии размера. Можно скомпилировать с ключом -Os тогда код получится существенно меньше, но, возможно, в ущерб производительности. А если собрать с -O3, то компилятор наплюёт на размер, но код будет более производительный. Я когда-то задумывался, смогу ли я улучшить код компилятора... пришёл к выводу, что не смогу. Только в одном месте нашёл кусок кода, где компилятор свалял дурака. Но это встречается очень редко. Понимаю, что у нас просто разные убеждения, но я не верю, что от -O3 можно увеличить производительность на 10-20%, как вы написали.
Я говорю про ядро ОС. В виде драйверов такие алгоритмы редко встраивают. Хотя бы потому, что там большая морока с float'ами (на счёт всех архитектур не знаю, но на ARMе точно). Я сильно сомневаюсь, что вам удастся найти хотя бы один такой драйвер в Линуксе. С этим не спорю. Никаких обид... наоборот - приятно, когда можно цивилизованно обсуждать какие-то вопросы. Но, думаю, всё равно, каждый останется при своём мнении ![]() В Линуксе графическая оболочка не является частью ядра. Но, думаю, вам ничего не мешает написать её в виде драйвера. Не дело командной строки рисовать окна. Не знаю, как правильно, но, думаю, менеджер окон, который рисует окна... его функции вызываются каким-то терминалом, что бы нарисовать себе окно. А уже терминал запускает интерпретатор, который использует уже готовое текстовое окно, в котором уже нет понятия пикселей, а есть только символы. Но это просто моё мнение.
0
|
1961 / 1275 / 130
Регистрация: 04.01.2010
Сообщений: 4,607
|
|
05.02.2019, 10:08 | 8 |
...в силу потребностей я много почерпнул из доков и по проектам, для gcc, спасибо. Да, в общем-то сопротивляться с компилятором последних версий стало практически невозможно - тем более, что теперь почти всегда можно сказать что конкретную оптимизацию можно было бы осуществить и средствами Си. Но если вы углублялись в программирование мелких АРМов, или вообще не АРМов, а "всякой мелочи", вроди PIC И AVR (ну, для примера), то увидели бы что адаптация кода нужна в том или ином варианте. В одной платформе нужно упирать на бит-бандинг, в другой - на условное выполнение инструкций (это просто для примера). В итоге код, как минимум, в критических местах может выглядеть немного иначе.
Да, на уровне уже ядра, ОСи, или даже математики - портируемый код вполне реален, в особенности, если система команд контроллера близка. Вы же сами вспомнили про float-библиотеки - вот и получается, что на одной системе написать код с использованием FP вполне реально, когда же для другой системы просто неэффективно - код-то выполнится, но "придется подождать". А если углубиться в каждую взятую отдельно архитектуру в имбеддед - разные типы памяти, разное время доступа, DMA, NVIC и т.д. - то окажется, что код вообще не портируем, и писать его придется на асме, чтобы не мучать зад. вот-вот ). PS: я же не говорю что писать на асме всю программу это панацея оптимального кода. Речь идет о том, что можно писать отдельные куски кода, которые будут выполняться гораздо быстрее будучи написанными на асме, но не на сях. Вот вам наглядный пример: Иногда для расчета чексуммы используется сумма всех байт данных с учетом переноса. Давайте возьмем какой-нибудь из ассемблеров и его Си, и попробуем решить эту задачу? ) Забегая вперед, я вам точно скажу, что эта задача будет решаться любым асмо-писателем с использованием флага переноса, которым в Си, увы, не воспользуешься так эффективно в данном случае.
0
|
Модератор
![]() 8756 / 6546 / 887
Регистрация: 14.02.2011
Сообщений: 22,962
|
|
05.02.2019, 10:46 | 9 |
и не надо пользоваться
![]() хороший компилятор сам найдет оптимальный путь работая с 80х86 и дизассемблируя сгенерированые коды,для пентиумов и выше, я ужасался какой фигни туда только компилятор не напихивает но детально разбираясь выяснял, что код эффективнее, распараллеливание и прочие плюшки ![]() например деление заменяет умножением с последующим сдвигом моих знаний по предыдущим версиям камней для современных уже не хватало ![]() в АРМ я практически даже не лезу, потому что логика уже совершенно другая
0
|
1961 / 1275 / 130
Регистрация: 04.01.2010
Сообщений: 4,607
|
|
05.02.2019, 18:26 | 10 |
Ага. Ну как обычно ). А если компилятор не находит оптимальный путь - значит он нехороший - ищите другой )).
да, когда возможностей много - компилятор кажется шибко умным. Но в конкретных случаях ассемблерное написание нужных кусков ускоряет работу кода в несколько раз. Особенно если речь идет не о безразмерных ARM'ах, а о более-менее ограниченных в возможностях ядер 8051, и др. "мелочевке" с малым количеством регистров.
0
|
Модератор
![]() 8756 / 6546 / 887
Регистрация: 14.02.2011
Сообщений: 22,962
|
|
05.02.2019, 19:19 | 11 |
хотелось бы конкретных примеров, а не общих рассуждений
бывает что и замедляет вот например мой вопрос Конструкция, обнуляющая старшие биты никто не дал ответ, сам потом разобрался ![]() ![]()
0
|
1961 / 1275 / 130
Регистрация: 04.01.2010
Сообщений: 4,607
|
|
05.02.2019, 21:13 | 12 |
да о чем вы? В 8051 два нормальных регистра - все остальные это просто временное хранилище переменных, чтобы не использовать стек, с косвенной адресацией.
Не по теме: В AVR ситуация гораздо проще - 16 регистров из 32х можно юзать более-менее, некоторые залочены под косвенную адресацию (точнее - 3 пары) + первые два под доступ к памяти программ, и некоторым результатам (если правильно помню). Возьмем - Z80 - та же ерунда (A, B, DE, HL (по памяти) ). В x86/88 вы тоже не найдете их большое количество... Да, в ARM'ах по-проще (чем даже в AVR), но при этом при реверсе я не видел, чтобы компилятор что-то где-то хранил на постоянной основе. Разве что ноль в R0 для атомарного сравнения и инициализации других регистров в ноль простым копированием.
0
|
1961 / 1275 / 130
Регистрация: 04.01.2010
Сообщений: 4,607
|
|
06.02.2019, 00:31 | 14 |
ниняю, я в 8051 не разбираюсь ). А что с 4й банкой?
Инфу взял отсель https://www.elprocus.com/know-... ontroller/ За что купил - за то продаю ![]()
0
|
06.02.2019, 00:31 | |
Помогаю со студенческими работами здесь
14
телефон с arm ядра arm Скриптинг в ARM ARM с Linux Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |