[update] Modified syscalls mechanism

[arnauldm]

• Therefore, each syscall is requested by a distinct SVC interrupt

Rationale:

• Code simplification

[PThierry]

Hello Arnauld !

Thanks for this PR ! It's clearly simplify the 'oldy' syscall handling.

3 questions here:

1. is it possible to avoid the 'when others' before calling exec_syncrhonous_syscall, as the t_svc type is strictly typed and the userspace may generate any SVC input value that may be invalid and generate an Ada exception
2. Are the end_of_task and end_of_isr dedicated SVC are stored in SVC value smaller than SVC syscall area ? (i.e. specific, non-syscalls SVC could be 1 and 2, and syscalls start at 10, to keep possible 8 free slots for any possible future specific SVC, and if syscalls number increase, the specific SVC are not impacted
3. is the replacement of the userspace do_syscall with a switch case impacting in term of performances ? As the syscall list is flat, the execution cost may increase for some constrained syscalls (e.g. get_systick)

What is your point of view on this ?

[PThierry]

Re,

Is it possible to define a t_syscall_svc as a subset of t_svc for syscall execution functions (i.e. push_syscall and do_syncrhonous_syscall) ?

[PThierry]

INFO: patch in association with libstd PR 1

[arnauldm]

• is it possible to avoid the 'when others' before calling exec_syncrhonous_syscall, as the t_svc type is strictly typed and the userspace may generate any SVC input value that may be invalid and generate an Ada exception

Good comment ! I slightly modified the ewok.syscall.handler package and I removed the 'exec_synchronous' function whose presence was no more justified.

• Are the end_of_task and end_of_isr dedicated SVC are stored in SVC value smaller than SVC syscall area ? (i.e. specific, non-syscalls SVC could be 1 and 2, and syscalls start at 10, to keep possible 8 free slots for any possible future specific SVC, and if syscalls number increase, the specific SVC are not impacted

I'm not sure that end_of_task() and end_of_isr() syscalls should be considered as special services.

• is the replacement of the userspace do_syscall with a switch case impacting in term of performances ? As the syscall list is flat, the execution cost may increase for some constrained syscalls (e.g. get_systick)

It should not because switch statements are optimized by gcc using jump tables and ARM architectures have special instructions to deal with that kind of construct (TBB and TBH instructions).

[PThierry]

Hello !

I'm asking myself... Should end_of_task and end_of_isr be replaced with a trap on effective return address on the isr root function or main function ? This would not be a svc no more, but a real trap. Svc would then be only syscalls, not events.

What do you think about it ?

[PThierry]

Ack for sys_exit() 👍 Using task current state instead of defining 2 independent system calls is cleaner to handle ISR & thread exit