Re: [MiNT] C99 stuff in public GEMlib headers?

[Arnaud BERCEGEAY <arnaud.bercegeay@free.fr>]

Hello,

2012/11/16 Eero Tamminen <oak@helsinkinet.fi>

>
> The file compiler.h is here for compatibilty issues of the compiler (it
> does the job for gcc, old version of gcc, pure C, sozobonx C, and maybe
> lattice C too...)

If you mean that compiler.h e.g. defines "inline" as empty for compilers
that don't support "inline" keyword (which is C99 feature), this would
mean that instead of static inline, you will have the static function
in *every* C-file that includes gem.h.

But but these are "static" functions to a C file, i mean it's private for each C file, and so, the compiler may ignore these 'unused piece of code' when compiling.

BTW, these are very short function, only a wrapper to the mt_aes corresponding function.

 

> For performance question, i don't think the extra function call
> (mt_aes -> non-mt_aes) is significant.
>
> BTW, when mt_aes has been integrated into gemlib (this was the begining
> of MGEMLIB, a fork of gemlib), some work has been done to optimize AES
> calls, and IIRC, the result was that MGEMLIB was faster than legacy
> gemlib. I think current version of gemlib is even faster thanks to ASM
> optimisation of AES trap done since then.

I'm not sure what you're referring with above.  Or are you agreeing
with me that having static inline for appl_init() that usually gets
called only once during program life-time, isn't necessary and it
can be a normal function?

Well, you're right, i think i didn't understand your point ;)

 

(Then few lines of code can be remove from a_glue.c too.)

in gemlib, for AES functions, there are:

- mt_aes (thread safe) functions - the main part of gemlib for AES

- non-mt_aes : definition of global data for an AES application + wrapper to pass this global data to mt_aes function

- a_glue.c : only there for retro-compatibilty. May not be linked in any modern application rebuilt againt gemlib 0.43.

a_glue is used only when an application is built againt 2 lib : gemlib 0.46 and an another GEM library (for example cflib...) that was built againt an old version of gemlib and requires old labels of gemlib (appl_init and not mt_appl_init for example) in order to be linked successfully.

For appl_init: both appl_init() and mt_appl_init() are required and my argumentation was that there is no gain to have both functions explicitly defined in gemlib... but maybe i still havn't got your point ?

Arnaud.