Портирование программного обеспечения / прошивки с одной архитектуры на другую путаницу - PullRequest
0 голосов
/ 13 декабря 2018

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

Если программное обеспечение было перенесено, например, на архитектуру ARM, еслиэто код на C / C ++, насколько я понимаю, исходный код не нужно менять, и мы просто используем специальный компилятор ARM для компиляции кода в инструкции, понятные микросхеме ARM?

Если исходный код необходимо изменить в зависимости от архитектуры (будь то ARM, PowerPC, X86 и т. Д.), Не могли бы вы привести пример почему?

Я читал о U- Загрузка и утверждение, что она начиналась как загрузчик для встроенных чипов PowerPC и с тех пор была портирована на ARM и другие архитектуры.Опять же, перенос будет означать, что он просто скомпилирован с другим компилятором?Я почти уверен, что это не так просто, поэтому, пожалуйста, объясните, что нужно изменить в исходном коде и т. Д. Для соответствия конкретной архитектуре.

1 Ответ

0 голосов
/ 13 декабря 2018

Поскольку вы запросили несколько примеров, вот два относительно простых непереносимых примера в C, просто для начала.

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

  1. sizeof(uint32_t)
    Легко ожидать, что это оценивается как 4, но на архитектурах, подобных TI C2000 , это оценивается как 2.Алгоритм, предполагающий 4 (который, конечно, глючит в первую очередь) будет хорошо компилироваться для C2000 и может также работать, но весьма сомнителен, если даст ожидаемые результаты

  2. Typecasts

    typedef struct _M {
      uint32_t a;
      uint32_t b;
    } M;
    
    uint8_t *p = (uint8_t *)malloc(100);
    
    M *m = (M *)p;
    
    printf("%d", m->b); //may cause hard fault at m->b on Cortex-M0
    

    Последняя строка всегда будет работать на Cortex-M4, но может вызвать серьезную ошибку на Cortex-M0в зависимости от выравнивания p по 32-битной границе.См это

...