Мой компилятор MIPS сумасшедший, или я сумасшедший для выбора MIPS?

Я думаю, что ваш компилятор ведет себя неправильно... Проверьте, например, это утверждение:

228:                             if (porte & 0x0004)
    andi        t2,v0,0x4  (1)
    andi        s8,ra,0x4  (2)
    andi        s8,ra,0x4  (3)
    andi        ra,t2,0x4  (4)
    andi        a1,v1,0x4  (5)
    andi        a2,v1,0x4  (6)
    andi        a2,t2,0x4  (7)

очевидно, что есть инструкции, которые в основном ничего не делают. Инструкция (3) не делает ничего нового, как хранит в s8 тот же результат, вычисленный инструкцией (2). Инструкция (6) также не имеет эффекта, так как она переопределяется следующей инструкцией (7), Я считаю, что любой компилятор, который выполняет некоторую фазу статического анализа, по крайней мере удалит инструкции (3) и (6).

похожие анализ будет применяться к другим частям кода. Например, в первом операторе вы можете увидеть, что некоторые регистры (v0 и v0) загружаются с одним и тем же значением дважды.

Я думаю, что ваш компилятор не делает хорошую работу по оптимизации компилируемого кода.

MIPS-это в основном воплощение всего, что было глупо в дизайне RISC. В наши дни x86 (и x86_64) поглотили почти все стоящие идеи из RISC, и ARM эволюционировал, чтобы быть намного более эффективным, чем традиционный RISC, оставаясь при этом верным концепции RISC о сохранении небольшого, систематического набора инструкций.

чтобы ответить на вопрос, я бы сказал, что вы сумасшедшие для выбора MIPS или, что более важно, для выбора его без первого изучения немного о MIPS ISA и почему это так плохо и сколько неэффективности вам нужно мириться, если вы хотите использовать его. Я бы выбрал ARM для маломощных/встроенных систем в большинстве ситуаций, или еще лучше Intel Atom, если вы можете позволить себе немного больше энергопотребления.

Edit: На самом деле, вторая причина, по которой вы можете быть сумасшедшим... Из комментариев кажется, что вы используете 16-битные целые числа. Вы никогда не должны использовать меньше, чемint типы В C, за исключением массивов или структуры, которая будет выделяться большими числами (либо в массиве, либо каким-либо другим способом, например, связанным списком/деревом/и т. д.). Использование небольших типов никогда не даст никаких преимуществ, кроме экономии места (что не имеет значения, пока у вас нет большого количества значений такого типа) и почти наверняка менее эффективно, чем использование "нормальных" типов. В случае MIPS разница является экстремальной. Перейти int и посмотреть, если ваша проблема исчезнет.

единственное, о чем я могу думать, это, возможно,возможно компилятор может вводить дополнительные бессмысленные инструкции для сопряжения скорости процессора с гораздо более медленной скоростью шины данных. Даже этого объяснения недостаточно, поскольку инструкции store / load аналогично имеют избыточность.

поскольку компилятор подозревается, не забывайте, что фокусировка усилий в компиляторе может ослепить вас к типу туннельного зрения. Возможно, ошибки скрыты в других частях и цепи инструментов тоже.

где вы взяли компилятор? Я нахожу, что некоторые из "простых" источников часто отправляют некоторые довольно ужасные инструменты. Встроенные друзья по разработке обычно компилируют свою собственную цепочку инструментов с иногда много лучшие результаты.

Я попытался скомпилировать следующий код с CodeSourcery MIPS GCC 4.4-303 с -O4. Я попробовал это с uint32_t и uint16_t:

#include <stdint.h>
void foo(uint32_t PORTE, uint32_t pst_bytes_somi[], uint32_t sliding_bit) {
    uint32_t LATDSET = 0x0040;
    {
        uint32_t porte = PORTE;
        if (porte & 0x0004)
            pst_bytes_somi[0] |= sliding_bit;
        if (porte & LATDSET)
            pst_bytes_somi[1] |= sliding_bit;
    }
}

вот разборка с целыми числами uint32_t:

        uint32_t porte = PORTE;
        if (porte & 0x0004)
   0:   30820004    andi    v0,a0,0x4
   4:   10400004    beqz    v0,18 <foo+0x18>
   8:   00000000    nop
./foo32.c:7
            pst_bytes_somi[0] |= sliding_bit;
   c:   8ca20000    lw  v0,0(a1)
  10:   00461025    or  v0,v0,a2
  14:   aca20000    sw  v0,0(a1)
./foo32.c:8
        if (porte & LATDSET)
  18:   30840040    andi    a0,a0,0x40
  1c:   10800004    beqz    a0,30 <foo+0x30>
  20:   00000000    nop
./foo32.c:9
            pst_bytes_somi[1] |= sliding_bit;
  24:   8ca20004    lw  v0,4(a1)
  28:   00463025    or  a2,v0,a2
  2c:   aca60004    sw  a2,4(a1)
  30:   03e00008    jr  ra
  34:   00000000    nop

вот разборка с целыми числами uint16_t:

        if (porte & 0x0004)
   4:   30820004    andi    v0,a0,0x4
   8:   10400004    beqz    v0,1c <foo+0x1c>
   c:   30c6ffff    andi    a2,a2,0xffff
./foo16.c:7
            pst_bytes_somi[0] |= sliding_bit;
  10:   94a20000    lhu v0,0(a1)
  14:   00c21025    or  v0,a2,v0
  18:   a4a20000    sh  v0,0(a1)
./foo16.c:8
        if (porte & LATDSET)
  1c:   30840040    andi    a0,a0,0x40
  20:   10800004    beqz    a0,34 <foo+0x34>
  24:   00000000    nop
./foo16.c:9
            pst_bytes_somi[1] |= sliding_bit;
  28:   94a20002    lhu v0,2(a1)
  2c:   00c23025    or  a2,a2,v0
  30:   a4a60002    sh  a2,2(a1)
  34:   03e00008    jr  ra
  38:   00000000    nop

как вы можете видеть, каждый с карты на две-три инструкции. Использование 16-битных целых чисел делает функцию только одной инструкцией длиннее.

вы включили оптимизацию компилятора? Код Unoptimzied имеет много дублирования в нем.