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

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On perjantai 16 marraskuu 2012, Arnaud BERCEGEAY wrote:
> 2012/11/15 Eero Tamminen <oak@helsinkinet.fi>
> > Could GEMlib public headers also be made ANSI-C compliant?
> > 
> > Currently headers have one inline for appl_init() which is
> > typically called only once in program life-time, so it's not
> > performance critical.
> > 
> > It's a bit annoying if a header forces all SW including it
> > to be compiled  with -c99/-std=c99.  And e.g. AHCC doesn't
> > even support "inline".
> 
> 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.


> 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?

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


	- Eero