You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IF* instructions have a reliability/security downside. Malicious code may contain long sequences of IF* instructions and thus sabotage interrupt servicing. Non-malicious code can introduce jitter into interrupt handling. Texas Instruments' TMS320C54 series had the same issue with its repeated multiply-accumulate instructions (they are used to implement FIR filters and can be repeated up to some 512-1024 times). I'd rather avoid this. If you could at least impose a limit onto how many IF* instructions can appear one after the other or if you could allow interrupts after some number of IF* instructions, it would alleviate the problem. Still, it's not nice, IMO.
By Alexey (SmallerC author)
I think that imposing a limit onto how many IF* instructions could be chained would be ok. We could set a number like 5 or 6 chained IF*
The text was updated successfully, but these errors were encountered:
The if-state could be suspended when an interrupt arrives. Not sure if that would be practical on the physical level in a real implementation - I'm not sure if if-chaining would be practical either actually - but it would solve the problem nicely. It would mean that if-chains wouldn't suspend interrupts at all. That's even better.
I think that imposing a limit onto how many IF* instructions could be chained would be ok. We could set a number like 5 or 6 chained IF*
The text was updated successfully, but these errors were encountered: