Why __metal_clic0_default_vector_handler needs to be 64 bytes aligned?

[pkarashchenko]

The __metal_clic0_default_vector_handler has 64 bytes alignment attribute. https://github.com/sifive/freedom-metal/blob/26b85c959e279447e9c89f235e3793b358b1c981/src/drivers/sifive_clic0.c#L32-L33 it is assigned to clic->metal_mtvt_table[id] in __metal_driver_sifive_clic0_vector_register: https://github.com/sifive/freedom-metal/blob/e21891cad8365b21a961444adb3d40b2aab39e93/src/drivers/sifive_clic0.c#L559-L590 But the parameter metal_interrupt_vector_handler_t isr of __metal_driver_sifive_clic0_vector_register that is also assigned to clic->metal_mtvt_table[id] does not have 64 bytes alignment requirement.

So the question is why __metal_clic0_default_vector_handler needs to be 64 bytes aligned?

[ppmag]

Good point. __metal_clic0_default_vector_handler is real ISR handler. CLIC specs require this handler to be 64-byte aligned (as far as I know, since it should fit into some part of the mtvec CSR).

On the other hand, isr is an arbitrary function pointer argument. Should we add additional checks in the code to be sure isr is 64-byte aligned?

[petrokarashchenko]

Actually for vectored mode (that does not place ISR handler address into mtvec directly) I can find that vector table address placed into mtvt should be 64-byte aligned (minimum, but can increase depending on the total number of CLIC interrupts implemented). Sorry for maybe a dummy question, but could you please point me to a doc that requires all mtvt entries to be 64-byte aligned as well?

I mean that __metal_clic0_handler is a default handler for non-vectored mode and it is required to be 64-byte aligned. That is fine https://github.com/sifive/freedom-metal/blob/26b85c959e279447e9c89f235e3793b358b1c981/src/drivers/sifive_clic0.c#L499-L500

But why __metal_clic0_default_vector_handler should be aligned as well?