Discussion about generated C code

[stefanos82]

I run the examples/helloworld.nelua and I have noticed in generated C code the following header files:

I have looked for the use of bool anywhere in the generated code and could not find it in there and wondered why it was even added there 🤔

Also, if we open <inttypes.h> header file, we will see that it calls <stdint.h> as well; so, we don't need to add it during generating code.

The same goes with <stddef.h> which <stdio.h> includes at the very first lines of it.

I know ifdef guards they take place and ignore the extra calls, but would it hurt if we clean the generated code?

...unless it's something that is only part of GCC, the compiler of my personal choice.

Now that's interesting; let me check by using Clang instead of GCC.

[stefanos82]

Yeah, my original suspicion was correct.

It's a GCC "behavior", so to speak; clang does not do such thing with its header files.

[stefanos82]

I have tested both GCC and Clang with the following #if condition and work as expected.

Yeah, I deleted <stdbool.h> to check whether some magic with boolean was taking place but... 🤷 nothing!

clang -o helloworld helloworld.c -Wall -fwrapv -g -lm -s
gcc -o helloworld helloworld.c -Wall -fwrapv -g -lm -s

[edubart]

The same goes with <stddef.h> which <stdio.h> includes at the very first lines of it.

The C generate code follow rules from the C standard. For example, the standard say if you need to use NULL you must include stddef.h, it says nothing that this can be omitted in case some other file is already included, if GCC does this it's an implementation detail of GCC, but Nelua has to work with other C compilers like Clang, GCC, TCC, so it cannot generate C code dependent on implementation details.

I have looked for the use of bool anywhere in the generated code and could not find it in there and wondered why it was even added there.

Because the following headers are exceptions, and are always included in any generated C code, as they are required for Nelua primitives types:

• stddef.h
• stdint.h
• stdbool.h

But yea, the Nelua compiler could include them only when really used as a small enhancement, but in general, in usual applications, they will be always included anyway.

[edubart]

I've improved the C code generation to include those headers only when required in c0fdc42 and 33d36d9

In summary now:

• stddef.h is included when using NULL , size_t or ptrdiff_t, as described in https://www.cplusplus.com/reference/cstddef/ .
• stdint.h is included when using fixed sized integers (intX_t or uintX_t), as described in https://www.cplusplus.com/reference/cstdint/.
• stdbool.h is included when using the bool type, as described in https://www.cplusplus.com/reference/cstdbool/.
• inttypes.h is included when using the PRIx macros, as described in https://www.cplusplus.com/reference/cinttypes/.

[stefanos82]

I have just tested it; it's more than awesome, kudos!

So...when you are going to write "The Design and Implementation of Nelua"?

I must have it in my collection! 😆

[stefanos82]

About the use of NULL; the standard says "...expands to an implementation-defined null pointer constant".

We do know though that some compilers use a plain 0 instead of (void *)0.

In my humble opinion, I would not want to include an entire header file for using a single thing, such as NULL which could be easily defined inside my generated code.

Personally, what I would do would be to undefined NULL and redefine it as #define NULL ((void *)0) to meet standard's credential and be supported on all platforms out there.

Thoughts?

[stefanos82]

A goal of Nelua is to generate readable and clear C code, and a C developers expects NULL to be defined by stddef.h. I don't see the point of avoiding including these headers, it will be included anyway to have the size_t type which is usually used.

Ah yes, I forgot about the use of size_t; my bad.

Also I want to keep the generated C file simple and small as possible, so I try to not add new defines. For example the section disabling warnings and defining nelua_static_assert is already bothers me a little, but they are required for a good user experience.

Interesting.

So, what if I did not want to have a readable C code, but wanted to have a highly performant binary output, what direction should I take, the hand-tweaking or the flag-usage?

That is, assuming there's a flag available that fully optimizes the C code to push its limits towards the best performance possible.

My personal preference would be: write everything you want in Nelua and tweak the generated C code when you must; and that should be only the exception of 1% to 5% of my whole time.

If Nelua comes with a set of flags and methodologies to do the dirty work for me behind the scenes, even better!

[edubart]

So, what if I did not want to have a readable C code, but wanted to have a highly performant binary output, what direction should I take, the hand-tweaking or the flag-usage?

First note that these includes does not impact the application performance, and Nelua already prioritizes performance in the C generated code over readability.

For maximum performance you should:

• Compile in release mode, that is --release flag, this will pass -O2 -fno-plt to the C compiler.
• Disable runtime checks, that is--pragma nochecks flag, this will not emit bounds checking code, null pointer dereferencing checks, or checks for numeric overflow when casting, plus other checks. It's better to have them enabled when developing though to catch mistakes.
• Disable the GC only if you are doing manual memory management, that is --pragma nogc flag, but note this is very dependent on your application and coding style.
• Optionally pass -O3 to the C compiler, that is --cflags="-O3" flag, but note this is application dependent, some applications are faster using just -O2.
• There are other interesting C flags like -ffast-math -flto and -march=native, but I will not speak about them here.

In summary you could get maximum performance doing something like this with many remarks:

nelua --release --pragma nochecks --pragma nogc --cflags="-O3 -ffast-math -flto -march=native" helloworld.nelua

My personal preference would be: write everything you want in Nelua and tweak the generated C code when you must; and that should be only the exception of 1% to 5% of my whole time.

In Nelua you can emit raw C code anytime in case you need a tweak, but usually you don't need that because Nelua have most C features without adding overhead.

[stefanos82]

Good to know all these things.

I went through the entire docs and couldn't find any thorough explanation of Nelua's flags.

Are there any plans to add them in the documentation?

I guess for now I could go with the traditional "trial and error" way, by using the -h, --help flag and experiment accordingly.

Is this the best approach for now or is there any other way you would suggest to go otherwise?

[edubart]

Note that the language is still under development, thus you will find some stuff incomplete like the documentation, the flags are not documented and at the moment you have to read the --help output, the standard libraries are not documented much too and you have to read their source files in lib folder. If you have daily questions due to missing documentation me and others can answer in discord's in the #help channel.

[stefanos82]

Do I need an account to join the channel? I don't use Discord myself, but I do use IRC.