Hi Ken, all,

Right, let's see the binary size of a prototype.

Regarding TBB instruction, It's applied at the stage of binary generation, after source parsing and references resolution so it is irrelevant to the problem of dead references, I have mentioned.

The best, Anton

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 22 November 2019 10:23 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] The svcall switch-case vs function table

Hi Anton,

Thanks for the reminder.

About code size, two points: - We saved code size for switch/case usage: switch(num) {case1:case2:} -> func_tbl[num].func(); - The compiler uses 'TBB' instruction, which is a function table already.

So I think it should be okay; we can verify the code size after the prototype is available.

BR

/Ken

-----Original Message----- From: Anton Komlev Anton.Komlev@arm.com Sent: Thursday, November 21, 2019 8:09 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com; Ken Liu (Arm Technology China) Ken.Liu@arm.com Subject: RE: The svcall switch-case vs function table

Hi Ken, All,

Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase.

This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment.

The best, Anton

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 14 November 2019 09:33 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] The svcall switch-case vs function table

Hi,

I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros?

This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros.

Welcome to comment or propose patches for this.

Thanks.

/Ken