There is a pragma to apply --opt-code-speed options to only part of code?

Other misc things
Post Reply
DarkSchneider
Member
Posts: 71
Joined: Sun Apr 01, 2018 4:02 pm

There is a pragma to apply --opt-code-speed options to only part of code?

Post by DarkSchneider »

I need a part of code to be self-contained, so want to apply the --opt-code-speed=inlineints to avoid the use of l_gint and others (for indexing and etc., already tested and generates the code I need). Is there some pragma or anything to apply it to only a part of the code instead as compile option?

A solution would be to compile that part with the option enabled, then on the compilation of the final program include the previously generated .o file instead the source .c file.
But in any case I think it would be a very interesting feature (not sure if already exists that's the reason I put it in Misc instead Request board) as it is more automated and also it serves as "documentation" in the own source file to warn about "hey this part should use the inline version of things".
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Re: There is a pragma to apply --opt-code-speed options to only part of code?

Post by stefano »

I'd avoid to rely on indexing basing on the actual compiled code.
We never rest and z88dk is continuously evolving, the output code might change in any case.
DarkSchneider
Member
Posts: 71
Joined: Sun Apr 01, 2018 4:02 pm

Re: There is a pragma to apply --opt-code-speed options to only part of code?

Post by DarkSchneider »

While it is a compiling option and does what it says should work. Is nothing a sophisticated code but requires to use the inline version of ints for indexing.

Is there a documentation of all available pragmas? I think the ones in the wiki could not be all of them.
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Re: There is a pragma to apply --opt-code-speed options to only part of code?

Post by dom »

inlineints is actually handled as part of the copt rules - the compiler has no role in it whatsoever.

The reason for this is that many of the existing rules will attempt to reduce a l_pint/l_gint to inline code should it be smaller. The extra rule file just runs over the top to clean up any which are left.

So unfortunately, you'll have to compile those files separately.

I do think most of the "shared" pragmas are on that wiki page (I've added a few more this morning), if I come across anymore I'll add them. There will be some which are target specific that are on the appropriate target page, for example CLIB_VG5K_CHAR10=1 to turn on 10 row fonts for the VG5k.
Post Reply