Здравствуйте!
Подскажите, пожалуйста, где можно взять startup.s для LPC1788. Я думал он должен быть в комплекте с LPC177x_8x CMSIS, но там его не оказалось. На сайте ARM со спецификацией CMSIS-SP-00300-r3p1-00rel0 идет startup_ARMCM3.s, но как я понимаю не для конкретной реализации. Если я правильно понял, то код запуска надо писать самому?

вот
Нажмите для просмотра прикрепленного файла

и переименовать в startup_LPC177x_8x.s

Большое спасибо! Только меня больше интересует вопрос, распространяется ли этот файл где-то официально или его надо писать, либо выдергивать откуда-то (из Keil напирмер)?

то, что Keil поставляет это дело с демо-версией (точнее, с ограничением кода в 32КБ), уж наверное свободно
да и умного там нет ничего, когда разберешься, в концов конце пишется свой стартап под свои нужды.

toweroff
Спасибо!

У меня небольшой вопрос не совсем по этой теме.
Я нигде не могу прочесть зачем необходимо область STACK и HEAP выравнивать на границу 8-ми байтов:

Подскажите пожалуйста, зачем это делается?

вроде, нужно для плавучки

понять бы еще что такое плавучка)

Некоторые команды в некоторых режимах требуют выравнивания их данных, располагающихся в памяти, на границу 8 байтов. Подробностей я не помню (тем более, они отличаются в разных версиях архитектуры ARM -- а листать мануалы, понятное дело, лениво) и на практике на такую необходимость не натыкался, но на всякий случай лучше выравнивание соблюдать.

P.S. А плавучка -- это арифметика с плавающей запятой. Вычисления с двойной точностью оперируют 64-разрядными числами, которые естественно выравнивать на границу 8 байтов -- правда, таковые вычисления на микроконтроллерах реализуются лишь чисто программно, когда вполне достаточно 4-байтового выравнивания. Вот на микропроцессорах, где имеется FPU, нужда в 8-байтовом выравнивании может быть реальной -- но я с таковыми пока не сталкивался, поэтому утверждать не буду.

это как бы точка,- то плавает то фиксируется - ну вы поняли а по иноземному - float point

По сути у - блок обработки чисел с такой арифметикой (а в особенности если мы используем double) сделан так что быстрее он выбирает из памяти те числа, что расположены в памяти с нужным выравниванием. Предполагается что никто не хочет терять лишний такт на обработке каждого значения. Это теория и практика еще со времен первых сопроцессоров для вычислений с плавающей точкой.

Для микропроцессоров то же самое, и в особенности такое выравнивание рекомендуется (а иногда императивно требуется) для операций с SIMD командами. Можно конечно использовать команды и без выравнивания, но они и выполняются медленнее.

Вот где-то так.

Спасибо всем! Впервые слышу такое название для чисел формата/стандарта 754. Но у меня возникает тогда вопрос: зачем выравнивать стек, если в стеке хранятся 32-битные регистры, а в куче могут храниться данные разных типов? И потом этоже выравнивание всего сегмента целиком.
Или я все неправильно понимаю?

Если посмотрите описание языка ассемблера KEIL, то обнаружите там две директивы -- кажется, PRESERVE8 и REQUIRE8, точно не помню. Они соответственно указывают, что данный модуль на языке ассемблера гарантирует сохранность 8-байтового выравнивания стека или требует, чтобы стек был выровнен на 8-байтовую границу (без них считается, что стек выровнен только на 4-байтовую границу). Компиляторы языков высокого уровня вроде бы порождают код, гарантирующий такое выравнивание (специально я этим вопросом не интересовался; при желании можно порыться в документации). Компоновщик же, собирая программу из объектных файлов, проверяет атрибуты выравнивания для каждого файла. Если окажется, что некий файл требует 8-байтового выравнивания стека, а входящие в его состав подпрограммы вызываются из файла, не гарантирующего такое выравнивание, он выдаст ошибку и откажется собирать программу. Таким путём обеспечивается контроль правильности выравнивания стека -- ну а нужно ли оно реально, решать программисту и компилятору (например, если при трансляции программы последний не использует команды, требующие 8-байтового выравнивания, то протранслированному модулю таковое и не требуется).

Каждый выделяемый элемент кучи также должен быть выровнен на границу 8 байтов, поскольку заранее нельзя сказать, как он будет использоваться: а вдруг к нему будут обращаться команды, требующие такого выравнивания? Кроме того, возможна (и нередко вполне целесообразна) такая схема хранения списка свободных участков кучи, когда этот список хранится в самих свободных участках: есть некая переменная, в которой лежит адрес первого свободного участка; в начале каждого участка располагается заголовок из двух полей, содержащий адрес следующего свободного участка и длину текущего свободного участка. На 32-разрядной машине каждая из этих величин имеет размер 32 бита, что в сумме даёт длину заголовка 8 байт -- а это ограничивает минимальный размер каждого свободного участка кучи 8 байтами, а заодно намекает на естественность их выравнивания на границу 8 байтов и выделения кусками, кратными по длине 8 байтам независимо от того, какая длина реально запрошена. По этой причине, если выделять, скажем, память из кучи кусочками по 3 байта, реально будет каждый раз выделяться 8 байт -- и куча будет израсходована намного быстрей, чем можно ожидать лишь на основе её объёма и длины выделяемых блоков.

Что же до разрядности, то 32-разрядные регистры общего назначения никак не отменяют возможности доступа к 64-разрядным данным. Во-первых, есть команды загрузки/сохранения пары регистров общего назначения (LDRD/STRD), которые могут требовать 8-байтового выравнивания (а могут и не требовать -- зависит от состояния какого-там бита в каком-то из управляющих регистров, насколько помню). Во-вторых, у сопроцессора с плавающей запятой (FPU) регистры в общем случае 64-разрядные, поскольку он должен уметь работать не только с 32-разрядными, но и с 64-разрядными числами с плавающей запятой (правда, такой сопроцессор мало где имеется: с ядрами Cortex-M4 интегрирован сопроцессор, поддерживающий лишь 32-разрядную вещественную арифметику, другие ядра серии Cortex-M, как и очень многие процессоры и микроконтроллеры предыдущих версий архитектуры, FPU часто вообще не имеют, и лишь у Cortex-A вроде бы у всех есть FPU с арифметикой двойной точности). Наконец, даже при принципиальной работоспособности без выравнивания на 8-байтовую границу (и вообще без выравнивания) правильное выравнивание обычно способствует повышению производительности. Например, та же команда LDRD, загружающая из памяти пару регистров общего назначения, т.е. два 32-разрядных слова, может выполняться заметно медленнее, если эта пара слов не выровнена на 8-байтовую границу: в такой ситуации одно слово может оказаться в одной строке кэша, а второе -- в другой строке или же вообще в кэше отсутствовать, что потребует считывания его из ОЗУ, и всё это время процессор будет стоять. Понятно, что подобные тормоза из-за нарушения выравнивания характерны в первую очередь для высокопроизводительных процессоров (ядра Cortex-A, а не сравнительно медленные Cortex-M, не имеющие широких внутренних шин, многоуровневой кэш-памяти и т.д. и т.п.), но требования-то пишутся для общего случая, а не для частного.

SII большое спасибо за подробнейший ответ!
Теперь все понятно. Просто я разбираюсь в startup коде для LPC1788, который Cortex-M3 и поэтому сложно было понять зачем нужно такое выравнивание для такого ядра. Наверное я забежал слишком вперед, ведь я начинаю изучать с нуля.
Еще раз большое спасибо! Ваш пост очень интересный!

Конкретно для LPC1788 это выравнивание больше "на всякий случай" и "чтобы не ругался компилятор" -- реальной нужды в нём с точки зрения собственно процессора в данном конкретном случае нет. Вот выравнивание кучи, по всей вероятности, нужно -- но это уже связано с требованиями программ управления кучей (я не смотрел, как это реализовано в Кейле, поскольку на Си не пишу -- только ассемблер для "низкоуровневого" кода или Ада для "высокоуровневого", а посему весь код управления памятью мой собственный -- и у меня такое выравнивание для кучи необходимо, а вот для стека не требуется).

SII
Спасибо большое! Я тоже хочу в будущем освоить asm, но решил начать с Си, так как нет даже базовых знаний о МК.

SII, а в чем преимущество ADA над C? не стеб, действительно хочу узнать преимущества
пока C вполне устраивает

Первейшая -- невозможность наделать кучу глупых ошибок вроде & вместо &&. Намного более высокая (для меня, во всяком случае) читабельность текстов, несмотря на то, что сами исходники становятся более громоздкими (в Си, как известно, используется куча спецсимволов, ну а в паскалеподобных языках -- а прототипом Ады был Паскаль -- их мало, в основном пишут словами; правда, бесконечных begin-end, раздражающих в Паскале, здесь нет). Возможность определить размеры и положение полей записи с точностью до бита, причём штатными средствами языка, а не какими-то расширениями. Встроенную многозадачность Ады я пока не использую -- нужды нет, да и писать свой код для поддержки этого надо (это на ПК всё готовое сразу имеется, а для ARM нет полноценной библиотеки времени выполнения, а значит, многое не работает, пока сам эту библиотеку не напишешь -- что я и делаю по мере надобности).

Вообще, у любителей "свободы самовыражения" паскалеподобные языки ничего, кроме ненависти, вызывать не могут: то нельзя, это нельзя, изволь строго следовать таким-то и таким-то правилам. Ну а в Си, как известно, можно творить что угодно -- компилятору на всё пофиг, в лучшем случае предупреждение выдаст. У меня же подход прямо противоположный, поэтому без крайней нужды я Си/Си++ не использую: мне не нужны лишние ошибки, а жёсткие требования Паскаля или Ады меня совершенно не напрягают (собственно, я даже на Си, если и пишу, то в "паскалеподобном" стиле -- с многочисленными объявлениями типов, не сваливая в одно выражение кучу операций и т.д.).

В АДском программировании есть поддержка многопоточности в самом языке!!! -- это круто. Однако Вам советую начать с Си так как много примеров и он ближе к Асму. Асм изучать для Арма самое наверное простое ибо архитектура простая. А потом решите вам Ада нужна или Асм или С++.

Мне знаом синтаксис C/C++ поэтому конечно буду начинать с Си, параллельно попробую заняться асмом