IBQ stalls на С55x, или как их избежать Опции

[Warlord]

О том как работает fetch конвейер в мануалах TI написано скупо и поверхностно. Буфер IB наполняется со скоростью 4 байта, а опустошается 1-6 байт. Смотрю в Pipeline Stall Analyzer по ходу программы IB начинает опустошаться и возникает IBQ stall причем никакими страшными 5 и 6 байтными командами и вызовами и циклами не пахнет. Отсюда возникают вопросы: При каких условиях перестает наполняться очередь и при каких вознобновляется. Вот для примера кусочек кода:

Код

_func
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP
    NOP_16 || NOP
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16
    NOP_16 || NOP
    NOP_16
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP_16
    NOP_16 || NOP_16
    RET

В процессе выполнения последние 2 инструкции перед RET оказываются отсеченными IBQ stall. Почему? Никаких видимых препятствий для наполнения буфера нет.

[SM]

Просимулил... Не прояснилось. Вот код полностью:

Код

        .cpl_off
        .c54cm_off
        .arms_off
        
        .global start

        .sect   ".vectors"
                
vecs:    .ivec    begin,USE_RETA
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
        .ivec    iret1
                
        .text                            
                
start:    
        bset    intm
        mov    #vecs>>8,mmap(@IVPD)
        mov    #vecs>>8,mmap(@IVPH)

        rpt        #5
        nop
        
        reset          
        
halt:        b    halt


begin:;        nop    ; !!!!!!!!!!!
        call    test
        b        begin

test:
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP
    NOP_16 || NOP
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16
    NOP_16 || NOP
    NOP_16
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP_16
    NOP_16 || NOP_16
    RET



iret1:        reti

Вся непонятка в том, что сталл зависит от NOP'а перед CALL. Если его нет - stall. Если он есть - сталла не стало. Из идей, почему так - есть предположение, что IBQ имеет какое-то кривое состояние, зависящее от состояния внутренних указателей, или еще х.з. чего-то там в нем, которое показывается как 64/64, и требует немедленной очистки IBQ, приводящей к этому stall'у. При этом четко видно, что в состоянии 64/64 там уже напрефетчено все вплоть до reti, т.е. на самом деле далеко не 64, а значительно меньше. Но вот что это за состояние, и как в него не попадать, я думаю может сказать только аффтар этого чудо-префетчера, а до меня суть не доходит (несмотря на то, что сам не так давно сделал очень похожий блок префетчера для своего микропроцессора)