zltigo 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Чем NVIC хуже? На нем можно с легкостью симулировать.... Как и любое улучшение и тем более любая эмуляция, эта "легкость" чего-то стоит. В данном случае тактов. Fast IRQ работающий в своем стеке вещь отличная. А, например, те-же вложенности перрываний, при нормальном построении системы, вещь совсем не нужная. А если и нужная, то организуемая руками. Так-что "кортексовский" контроллер прерываний это вещь более, чем компромиссная в угоду простоте и бездумности использования. ну как я понимаю в Тхумб2 фичи остались, усложнился парсер команд, который раньше брал слово и все, а теперь ему надо крутить 16 или 32 бита. Но зато 128 бит шины флеш хватает на выбор не 4, а уже 8 команд, как следствие для 20 МГц флеши проц в 100-120 МГц может работать без пауз. И это гораздо важнее по мне, чем то что в память больше команд влезает. Дык, мил человек, команда команде рознь. Из того, что порезали формат команды и команд стало требоваться БОЛЬШЕ. В свое время подробно копался сравнивая - быстродействе в ARM режиме при работе по крайней мере с НЕ 8bit параметрами, было отчетливо больше. Так-что Thumb-бы это шаг прежде всего, на встречу восьмибитовикам. Да, сейчас недостатки Thumb нивелируют, подтягивают путем опять-же усложнения ядра. Но чистый 32bit ARM красив и сам по себе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 33 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Это, увы, слова пико-аврщика который просто жутко боится даже ознакомится с чем-то другим. Для разработчика мелкие армы МНОГО проще. Проще и ядро без разных вульгарных ограничений, проще в ИСПОЛЬЗОВАНИИ и переферия, по причине меньших ограничений и большей аппаратной функциональности. Проще-то оно может и проще, если на кубах всяких клепаете, а попробуйте в чистую, на голых сях, уж не говорю про асмы, сам ужаснулся :rolleyes: И сравните то, что нужно для инициализации аврки или пика, и 32ф4хх например, Разница заметна? Чем NVIC не угодил?? Работал и с ним на 407стм и с irq\fiq на А9 первый куда лучше, т.к. гораздо меньше программной обработки... Но чистый 32bit ARM красив и сам по себе. Чем он был красив? Тем, что под 8 или 16 бит выделял всегда 32бита?? И куда подевалась моя память?? Это как аля виндовое программирование, когда результат команды, хоть 1битный(да нет) представлялся как инт32 бита Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Проще-то оно может и проще, если на кубах всяких клепаете, а попробуйте в чистую, на голых сях, уж не говорю про асмы.... Именно на "голых" С и "голых" компиляторах я и работаю. Никакие "библиотеки" и даже IDE от производителя я не использую. Ну а ASM-ы вообще можете забыть. Уже лет 20 на ASM не более нескольких десятков строк пишу, да и то все меньше и меньше. Уже давно обильное использование ASM есть верный способ сделать программу горомоздкой, медленной и глюкавой. Проверено путем _переделки_ работ упертых пико-авр-асм писателей НЕОДНОКРАТНО :(. Ну а на кортексе даже startup на C пишется естественно. Чем NVIC не угодил?? Работал и с ним на 407стм и с irq\fiq на А9 первый куда лучше, т.к. гораздо меньше программной обработки... Читать умеете? Тогда ВСЕ написано в моем предыдущем посте: Как и любое улучшение и тем более любая эмуляция, эта "легкость" чего-то стоит. В данном случае тактов. Fast IRQ работающий в своем стеке вещь отличная. А, например, те-же вложенности перрываний, при нормальном построении системы, вещь совсем не нужная. А если и нужная, то организуемая руками. Так-что "кортексовский" контроллер прерываний это вещь более, чем компромиссная в угоду простоте и бездумности использования. Чем он был красив? Тем, что под 8 или 16 бит выделял всегда 32бита?? Тем, что позволял БЕЗ коственной адресации БЫСТРО делать сложные вещи. И куда подевалась моя память?? Если Вы расскажете мне, что Вам на каком-то ARM не хвтило Flash, то я Вам НЕ поверю. Да и по расходу ROM памяти в ARM режиме на МОИХ реальных задачах требующих математики, а не просто ветвления по одному биту, размер кода оказывался зачастую даже МЕНЬШЕ. Вот такой сюрприз! Это как аля виндовое программирование, когда результат команды, хоть 1битный(да нет) представлялся как инт32 бита Вот тут Вы ОБЛАЖАЛИСЬ по полной. 1) командой Вы обозвали функцию, ибо только о них можно говорить в контексте windows API, а не о командах ядра на которые ни win, ни Lin ни кто-либо еще ну никак не влияют. 2) функции ДОЛЖНЫ по максимуму и получать и возвращать НАТИВНОЕ для данного ядра значение, даже если нужено меньше. Ибо разрядность стека и регистров тут принципиальна. Когда я вижу, что какая-либо "библиотека" под, например, ARM радостно возвращает байт, я сразу понимаю, что мозгов у писателей сего не густо :(. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 33 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Если Вы расскажете мне, что Вам на каком-то ARM не хвтило Flash, то я Вам НЕ поверю. Да пожалуйста - sam7s64 16кило памяти и 64 флеш, но он не в счет - дело в оперативке. Не все пишут на чипах с памятью в сотни килобайт. Ибо разрядность стека и регистров тут принципиальна. Вот после таких программеров программы и "пухнут" от размера оперы и своего объема... функции ДОЛЖНЫ по максимуму и получать и возвращать НАТИВНОЕ для данного ядра значение Для кортексов нативно и 8 и 16 и 32бита. командой Вы обозвали функцию, Я сейчас не буду цеплятся к терминологии - на результат это не влияет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Да пожалуйста - sam7s64 16кило памяти и 64 флеш, но он не в счет - дело в оперативке. Не все пишут на чипах с памятью в сотни килобайт. Не поминайте оперативку всуе. К памяти КОМАНД она отношения НЕ имеет. Вот после таких программеров программы и "пухнут" от размера оперы и своего объема... Не смогли понять о чем речь, но продолжаете нести пургу :(. Для кортексов нативно и 8 и 16 и 32бита. Абсолютная глупость. Не обсуждаемо даже. Я сейчас не буду цеплятся к терминологии - на результат это не влияет. Это, увы, очень влияет на понимание уровня квалификации оппонента :(. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 33 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Это, увы, очень влияет на понимание уровня квалификации оппонента Ну да, если уж если я в чем-то не прав, а вы такой гуру, дак объясните, что и как, для этого и форум. ЗЫ. А еще, мнеб было очень любопытно, еслиб вы рассказали о паре-тройке своих мегапроектов, для расширения кругозора, так сказать, хотябы в 2х словах, а пока это просто понты и не больше. А если нет - то не вижу смысла дальше дискутировать с такими любителями терминологии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Ну я пишу без библиотек типа куба, ничего нормально. Я бы сказал что лок-фуз биты АВР - был тот еще кошмар. Хорошо потом появился визард для них. Сам арм то быстро настраивается, периферия у него сложнее, и потому она сложнее настраивается. Но зато она может много того что АВР и не снилось. Так что тут я поддерживаю не надо за АВР держаться. Ровно также поддерживаю, что хвататься за ассемблер сейчас не имеет смысла. Еще вставки возможно, да и то большие функции оптимизатор лучше делает. Про вложенность прерываний не согласен, в реализации NVIC оно очень хорошо. В старой системе требуемая вложенность замедляла процесс... Я раздаю приоритеты, и всегда уверен что что-бы не случилось у меня синхронный по таймеру процесс все сделает, с высшим приоритетом и никакие обработки езернета его не перебьют. Я знаю что в программе не будет запрета прерываний на критические секции, которые могут отодвинуть синхронный процесс. NVIC - 100% добро, с автосохранением части стека и переходом в 12 тактов. Сколько переход в старом арме был? А если вложенность нужна, сколько сохраняли? Ровно как Thumb2 мне кажется более правильным, что стал сложнее расчет, ассемблер, и проц мне не важно. Ведь сами правильно сказали АСМить уже не надо. А компилятор и косвенной адресацией неплохо справляется. Thumb - режим уступал АРМ это факт, но Thumb2 отличается в нем же не только 16 бит, но и 32 битные команды. И большего числа команд уже практически не надо. Остальное растущей частотой процов и ускорителями флеши нивилируется... Вы же согласны что при той же ширине шины доступа к флеши, команды по 32 бита проигрывают по количеству 16 битным, как следствие макс частота их выполнения без ожидания тоже проигрывает. А в кортексе М7 еще конвейеры похитрее и прочее.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Ну да, если уж если я в чем-то не прав, а вы такой гуру, дак объясните, что и как, для этого и форум. Уговорили. Я Вас поддолкну, но дальше САМИ думать будете. Начало простое - откомпилируйте в thumb две функции char d08( char x ) { return( ++x ); } int d32( int x ) { return( ++x ); } Посмотрите на результат и как вызывается одна и другая функция и подумайте о нативности char, если по любому функции передается и функцией возвращается значение в 32 битном регистре, а код функции для char содержит дополнительную команду что-то типа UXTB. А если нет - то не вижу смысла дальше дискутировать с такими любителями терминологии. А с чего Вы это взяли, что это дискуссия :). Это не дискуссия. Это просто постановка на место, дабы количество глупостей в интеренете не увеличивалось :(. Про вложенность прерываний не согласен, в реализации NVIC оно очень хорошо. Для каких условий "хорошо" я уже писал. Ну а как нехорошо, я тоже знаю, даже на своей шкуре, когда последние годы портирую со старенького ARM7 на M3 :(. Дополнительные мегагерцы, конечно, все нивелируют, но тем неменее :(. В старой системе требуемая вложенность замедляла процесс... В общем случае вложенность есть зло, ибо приводит к недерминированности. Только для достаточно примитивнно строимых вещей нужна. Может просто следует забыть о вечном цикле :) на столь приличных контроллерах, как ARM? Ровно как Thumb2 мне кажется более правильным, что стал сложнее расчет, ассемблер, и проц мне не важно. Ведь сами правильно сказали АСМить уже не надо. А компилятор и косвенной адресацией неплохо справляется. Справляется, и опитимизация офигительная местами идет. Но все-же 32 бита команда это зачастую очень эффективно. Вы же согласны что при той же ширине шины доступа к флеши, команды по 32 бита проигрывают по количеству 16 битным, как следствие макс частота их выполнения без ожидания тоже проигрывает. Не факт. Совсем не факт. Во первых, 32bit команда по количеству сделанного может первосходить 16 bit, так-что в "командах" считать не надо. Второе, к чему мне куча команд зараз считанных из Flash, если у меня первая из команд это переход :). Сравнивать надо на чем-нибудь хоть сколько приближенном к реальности. Ну хотя-бы на dhrystone тестах. Thumb2, несомненно, развитее, но в свое время Thumb ARM проигрывал изрядно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба ... Ну а на кортексе даже startup на C пишется естественно. ... Как вы умудряетесь в startup на C делать очистку секции "bss" (инициализированые нулями данные)? У меня это единственная часть, которая делается инлайн-ассемблером. Если делать на Си, то код обнуления области памяти не всегда корректно работает (зависит от компилятора). Видимо, компилятор рассчитывает на изначально нулевое значение переменной счётчика, что не так на стадии стартапа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Как вы умудряетесь в startup на C делать очистку секции "bss" (инициализированые нулями данные)? /* copy-init variables */ memcpy(&__data_start__, &__etext, &__data_end__ - &__data_start__); /* zero-init variables */ memset(&__bss_start__, 0, &__bss_end__ - &__bss_start__); Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба /* copy-init variables */ memcpy(&__data_start__, &__etext, &__data_end__ - &__data_start__); /* zero-init variables */ memset(&__bss_start__, 0, &__bss_end__ - &__bss_start__); Та же проблема, но теперь вынесена в libc. 1) Какие гарантии, что memset не рассчитывает на заранее инициализированную/очищенную область памяти? 2) При оптимизации LTO будет ли вообще этот memset как вызов libc или цикл очистки будет "заинлайнен"? Всё это меня очень сильно смущает. Есть ли какие-нибудь гарантированные способы обойти эти неоднозначности? (без АСМа) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Всё это меня очень сильно смущает. Есть ли какие-нибудь гарантированные способы обойти эти неоднозначности? (без АСМа) А меня не смущает. 1) Да, теоретически memset() может использовать статическую переменную, но это было бы довольно глупо. 2) Если в новой среде зануление переменных не сработает, это будет довольно очевидно, и исправить будет несложно. Можно даже добавить assert() по этому поводу. 3) А чем инлайн-ассемблер лучше? Такая же потенциально непереносимая штука. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба 1) Какие гарантии, что memset не рассчитывает на заранее инициализированную/очищенную область памяти? - C какого-бы бодуна??? - посмотреть в исходик библиотеки - да написать примитивнейший цикл самому-же на 'C'. У меня для ARM вызывается своя функция писанная на ASM, но не из-за паранои, а из-за скорости. Для Thumb пока поленился на ASM подчистить. 2) При оптимизации LTO будет ли вообще этот memset как вызов libc или цикл очистки будет "заинлайнен"? А какая проблема хоть в вызове, хоть в заинлайнивании? Даже если предположить, что линкер начнет курочить библиотеки. P.S. Ради интереса одну функцию без заметной арифметики, компильнул 7 IAR-ом в Thumb, Thumb2 и ARM. Результат 234, 230 и 352 байта соответственно. Почему ее вытажил на свет божий? Потому, что во времена IAR 4.x, LPC2148 давал на этой функции процетов 25 прироста производительности в ARM mode. Но скорости, увы, уже впрямую сейчас не сравнить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Видимо, компилятор рассчитывает на изначально нулевое значение переменной счётчика, что не так на стадии стартапа. это какой-то плохой и злой компилятор. В кодах от кейла если стоит int a = 0; то там в ассемблере явно есть регистр в который пихается 0, а потом используется на месте а. (без оптимизации) Вроде бы нам как-то с первого курса долдонили что в не инициализированной памяти может быть что угодно, неужели это не долдонили тем кто пишет компиляторы? неверю.... Не факт. Совсем не факт. Во первых, 32bit команда по количеству сделанного может первосходить 16 bit, так-что в "командах" считать не надо. Не чтобы поспорить, а чтобы самому стать лучше. Как я понял thumb2 добавил 16 битных команд, заменив ими 32 не уменьшая общего функционала. То есть порезали длину переходов, длину адресов и так далее, но что команда делала, то она и делает. Для тех команд что в 16 битах все таки не дотягиваются они добавили 32 битные команды. Возможно какие-то совсем редкие 32 битные заменили комбинацией 16 битных (бегло по табличке я таких не нашел, но может не прав). Что thumb проигрывал ARM это известный факт, а вот про thumb2 они написали типа сохранили компактность thumb и производительность ARM, и я не думаю что они сильно лукавят.... Но все-же 32 бита команда это зачастую очень эффективно. и они частично остались, именно те что были очень эффективны... Второе, к чему мне куча команд зараз считанных из Flash, если у меня первая из команд это переход ну это понятный факт, но все же большие куски линейного кода идут друг за другом, даже кейс с переходами пока идут проверки куда лететь - это цепочка команд с пропусками 2-3, в 32 битном варианте это каждая проверка с тормозом, а в 16 битном до следующей порции флеши по 2-3 проверки... осмотрите на результат и как вызывается одна и другая функция и подумайте о нативности char, кстати один раз видел как 32 битная система стала тормозить когда ее переписали на 8 битные данные, ответ оказался очень простой, она так и считала в 32 битах, только добавила команду по отрезанию результата маской%).... Если все шины 32, регистры 32, и память 32. То конечно возвращать из функции 8 или 32 разницы по памяти нет. Все равно это либо в регистр либо в стек положат, также записанный за 1 такт, и имеющий все равно размер 32.... Ну а как нехорошо, я тоже знаю, даже на своей шкуре, когда последние годы портирую со старенького ARM7 на M3 А поделитесь примером, самым простым, надеюсь не коммерческая тайна. Мне правда интересно... у меня недавно был проект где проц должен был ровно раз в 10 мкСек что-то делать, причем максимально повторяемо, при этом он крутил ТСР стек, говорил по езернету и так далее. Я вынес эту работу в прерывание таймера, таймер запустил на 10 мкСек, и назначил наивысший приоритет. В результате где бы программа не находилась и чтобы она не делала, она прерывалась и четко работала. Без вложенности я даже не знаю как такое решить с гарантиями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба кстати один раз видел как 32 битная система стала тормозить когда ее переписали на 8 битные данные, ответ оказался очень простой, она так и считала в 32 битах, только добавила команду по отрезанию результата маской%)... Да, это один из эффектов. Для борьбы с такими эффектами есть стандартные типы int_least8_t, int_fast8_t и иже с ними. Но их использование у "библиотекописателей" я вижу КРАЙНЕ редко :(. А безумные char, напротив, постоянно. Вот буквально сейчас вожусь с Jennic контролером у у которого ВООБЩЕ нет описания и только API, причем все байтами усыпано и чувствую себя очень, очень! стремно. Для себя такой "восьмибитовый" тип дефинирую для краткости, как bint (то-ли базовый, то-ли байтовый int - за давностью лет не помню :) ) и спокойно таскаю исходники по 8-16-32 битникам. А поделитесь примером, самым простым, надеюсь не коммерческая тайна. Мне правда интересно... Как-бы не особая тайна, но там, например, все дело в сбаланстрованности Fast IRQ, быстрой обработки от очень специфичного высокоскоростного железа и реалтаймовой операционной системы. В общем не "контроллер светодиода" и "простым" и понятным там не пахнет. Была важна быстрая реакция на прерывание, а не через сколько-то там тактов и короткий обработчик этого FIQ на фоне не менее жесткого и несколько синхронизированного 2ms прерывания. у меня недавно был проект где проц должен был ровно раз в 10 мкСек что-то делать, причем максимально повторяемо, при этом он крутил ТСР стек, говорил по езернету и так далее. Я вынес эту работу в прерывание таймера, таймер запустил на 10 мкСек, и назначил наивысший приоритет. В результате где бы программа не находилась и чтобы она не делала, она прерывалась и четко работала. Без вложенности я даже не знаю как такое решить с гарантиями. Ну на старом контроллере такая вещь на FIQ может быть повешена. Ну на 10 МИКРО секунд перрывание вешать то, что Вы перечислили, это какой-то безумный прдход к делу :( То-же TCP стек ни сном ни духом МИКРОСЕКУНД не требует и работает по собственным прерываниям и таймаутам. Это если его правильно писать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
