@pgb

Приветствую уважаемые!
Есть тут те кто программирует на ARM ассемблере? Хочется пообщаться с такими специалистами. У которых можно узнать о том как устроена память, думаю архитектура отличается от x86. В каких адресах находятся векторы прерываний, видеобуфер и тд. Как можно на ассемблере вывести что-то на экран и тд. Литературы по ARM ассемблеру мало, в основном программирование микроконтроллеров. Интересна тема написания своей OS для этой платформы.

__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь

0

Humanoid

Зависит от архитектуры. Например, в CortexA9 есть таблица векторов, на которые процессор прыгает в случае исключений. Пример такой таблицы можно посмотреть, например, в исходниках U-Boot:
Процессор прерывает свою работу и прыгает на один из этих адресов в случае исключений. Одним из таких исключений является срабатывание прерывания (IRQ). Т.е. процессор переходит на позицию 6, а там инструкция перенаправляет его в функцию _irq, в которой обработчик прерывания обращается к контроллеру прерываний и узнаёт номер прерывания и в зависимости от номера переходит к обработке этого конкретного прерывания.
Например, пришли данные по UART. При этом блок UART вырабатывает прерывание, которое поступает на контроллер прерываний в процессор. Процессор прерывает свою текущую работу и прыгает в таблицу, а оттуда на глобальный обработчик прерываний (функция _irq), который узнаёт от контроллера прерываний, что источником прерывания был UART и прыгает в другую функцию - обработчик прерываний для UART.
В общем, для CortexA9 (думаю, что для всех CortexA) прерывания обрабатываются в обычных функциях, которые могут быть в любых адресах. Да и таблицу векторов тоже можно перемещать. Обычно изначально эта таблица находится в самом начале памяти, откуда исполняется программа. Т.е. при начале работы процессор первым делом попадает в начало этой таблицы (на обработчик _reset).
Но в других архитектурах могут быть отличия. Например, сейчас смотрю на CortexM3 - похоже, что там за такой таблицей сразу идёт таблица векторов внешних прерываний.

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

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

Можете посмотреть, как сделано в Linux или других ОС. Но я бы не советовал заморачиваться с ассемблером. На ассемблере обычно пишут самое начало (где требуется настраивать стек, переносить код), обработчики исключений, настройку процессора, работу с кешем и т.п. Остальные функции обычно пишут на Си. Код на ассемблере тяжелее читать и там проще допустить ошибку.

0

@Voland_

Да вы что? то есть людей которые таки пишут HAL и драйверы низкого уровня в природе не существует, да?

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

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

По АСМу, для примера, вот. Как появятся вопросы, будем вместе разбираться .

0

Humanoid

Что бы обращаться к регистрам железа, ассемблер не нужен. Он только сильно усложнит код и поможет программисту допустить ошибку. Откройте любой драйвер устройства в Линуксе и вы там не найдёте ни одной ассемблерной строки. Ассемблер используется только в драйвере процессора и в функциях начальной инициализации.

В том сообщении я написал, что ассемблер используется для начальной инициализации и ещё для нескольких функций. Но весь остальной код пишут без ассемблера. Для работы с железом нужно только работать с регистрами этого железа и обрабатывать прерывания. В любой нормальной ОС драйверы устройств всегда кроссплатформенные. А использование ассемблера не позволит сделать код кроссплатформенным. Для вывода видео на монитор ассемблер не нужен.

0

@pgb

Возможно ли собрать из Linux ядро с графической оболочкой, а командную строку в виде интерпретатора написать свою, которая будет рисовать окна(через графическую библиотеку) и тд.? Никто не пробовал сделать что-то подобное?

0

@Voland_

ну, я согласен что в большинстве случаев достаточно Си. Тут многое зависит от адаптации компилятора к процессору и архитектуре. Если проект позволяет иметь запас по производительности процентов 10-20%, то да - разницу вы не почувствуете. Но если вы хотите получить действительно 99% отдачу кода - придется писать на ассемблере. Да-да, тут не вопрос - что код перестанет быть масштабируемым, и чуть какие-то изменения - может привести к ошибке. Но на асме удается выжать то, чего не удастся выжать на текущем уровне компиляторов. Хотя, их возможности и правда - сильно поражают.

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

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

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

0

Humanoid

gcc умеет оптимизировать код либо для быстродействия, либо для экономии размера. Можно скомпилировать с ключом -Os тогда код получится существенно меньше, но, возможно, в ущерб производительности. А если собрать с -O3, то компилятор наплюёт на размер, но код будет более производительный. Я когда-то задумывался, смогу ли я улучшить код компилятора... пришёл к выводу, что не смогу. Только в одном месте нашёл кусок кода, где компилятор свалял дурака. Но это встречается очень редко. Понимаю, что у нас просто разные убеждения, но я не верю, что от -O3 можно увеличить производительность на 10-20%, как вы написали.

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

С этим не спорю.

Никаких обид... наоборот - приятно, когда можно цивилизованно обсуждать какие-то вопросы. Но, думаю, всё равно, каждый останется при своём мнении

В Линуксе графическая оболочка не является частью ядра. Но, думаю, вам ничего не мешает написать её в виде драйвера.

Не дело командной строки рисовать окна. Не знаю, как правильно, но, думаю, менеджер окон, который рисует окна... его функции вызываются каким-то терминалом, что бы нарисовать себе окно. А уже терминал запускает интерпретатор, который использует уже готовое текстовое окно, в котором уже нет понятия пикселей, а есть только символы. Но это просто моё мнение.

0

@Voland_

...в силу потребностей я много почерпнул из доков и по проектам, для gcc, спасибо. Да, в общем-то сопротивляться с компилятором последних версий стало практически невозможно - тем более, что теперь почти всегда можно сказать что конкретную оптимизацию можно было бы осуществить и средствами Си. Но если вы углублялись в программирование мелких АРМов, или вообще не АРМов, а "всякой мелочи", вроди PIC И AVR (ну, для примера), то увидели бы что адаптация кода нужна в том или ином варианте. В одной платформе нужно упирать на бит-бандинг, в другой - на условное выполнение инструкций (это просто для примера). В итоге код, как минимум, в критических местах может выглядеть немного иначе.

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

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

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

Иногда для расчета чексуммы используется сумма всех байт данных с учетом переноса. Давайте возьмем какой-нибудь из ассемблеров и его Си, и попробуем решить эту задачу? ) Забегая вперед, я вам точно скажу, что эта задача будет решаться любым асмо-писателем с использованием флага переноса, которым в Си, увы, не воспользуешься так эффективно в данном случае.

0

ValeryS

и не надо пользоваться
хороший компилятор сам найдет оптимальный путь
работая с 80х86 и дизассемблируя сгенерированые коды,для пентиумов и выше, я ужасался какой фигни туда только компилятор не напихивает
но детально разбираясь выяснял, что код эффективнее, распараллеливание и прочие плюшки
например деление заменяет умножением с последующим сдвигом
моих знаний по предыдущим версиям камней для современных уже не хватало
в АРМ я практически даже не лезу, потому что логика уже совершенно другая

0

@Voland_

Ага. Ну как обычно ). А если компилятор не находит оптимальный путь - значит он нехороший - ищите другой )).
да, когда возможностей много - компилятор кажется шибко умным. Но в конкретных случаях ассемблерное написание нужных кусков ускоряет работу кода в несколько раз. Особенно если речь идет не о безразмерных ARM'ах, а о более-менее ограниченных в возможностях ядер 8051, и др. "мелочевке" с малым количеством регистров.

0

ValeryS

хотелось бы конкретных примеров, а не общих рассуждений
бывает что и замедляет
вот например мой вопрос Конструкция, обнуляющая старшие биты
никто не дал ответ, сам потом разобрался это 34 регистра то мало

0

@Voland_

да о чем вы? В 8051 два нормальных регистра - все остальные это просто временное хранилище переменных, чтобы не использовать стек, с косвенной адресацией.

0

ValeryS

это A и B ??? тогда у 8086 вообще один- аккумулятор
как же 4 банка с R0-R7?

0

@Voland_

ниняю, я в 8051 не разбираюсь ). А что с 4й банкой?
Инфу взял отсель https://www.elprocus.com/know-... ontroller/

За что купил - за то продаю .

0