Re: Suggested method for returning a string from a C program?

On 22/03/2025 13:50, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

On 22/03/2025 02:37, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

>
Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types. (And if this is for a multitude of
targets, then there should be a dedicated header per target).
>
GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
of the core language, it would be zero lines.

>
You need few (say 3) lines of compiler code to define a type.
AFAICS there are 24 types in intXX... and uintXX... family.

>
There's about 8, unless you include FAST/LEAST which are of interest to
a minority of the minority who are even aware of them.

 Well, FAST/LEAST types are mandatory for standard compliance.
 

So about 72 lines in compiler.  For compatiblity with older
code you probably should define types under internal names
and have 24 lines in stdint.h (+3 lines of include guard).

>
It's a lot more than 72 lines in a compiler to support numeric types.
>
But this is about exposing fixed-size type aliases to existing types,
which can be done fairly tidily in a compiler,

 Yes, there is complex machinery to support types and compiler
data structires in general.  But once machinery is in place
you need to create type node and insert it into symbol table.
In gcc creation of type node may look like:
    sizetype = make_node (INTEGER_TYPE);
   TYPE_NAME (sizetype) = get_identifier ("sizetype");
   TYPE_PRECISION (sizetype) = precision;
   TYPE_UNSIGNED (sizetype) = 1;
   scalar_int_mode mode = smallest_int_mode_for_size (precision);
   SET_TYPE_MODE (sizetype, mode);
   SET_TYPE_ALIGN (sizetype, GET_MODE_ALIGNMENT (TYPE_MODE (sizetype)));
   TYPE_SIZE (sizetype) = bitsize_int (precision);
   TYPE_SIZE_UNIT (sizetype) = size_int (GET_MODE_SIZE (mode));
   set_min_and_max_values_for_integral_type (sizetype, precision, UNSIGNED);
 But such things are repeated for several types, so one can have
function like 'create_integer_type_node' which is doing the above,
but for type name and precision which are arguments to the function.
 Of course, if you need to do soemthing special to a type, then
you may need a lot of code.  But integer types should be handled
anyway, so there is really no special code beyond what is already
there.
 

but not as tidily as when
all the built-in types can be expressed as one token; some need multiple
tokens.

 Unlike classic integer types, types in stdint.h have names which
are single token, so all you need to do is to insert entry in the
symbol table.

I've done an experiment to add such types to my C compiler. It's slightly tricky because "int" etc are not independent types; they are special tokens that work together to form a full type spec.
Anyway it involved these additional lines. First in the symbol table (what is used to initialise the main ST):
     ("int8",        kstdtypesym,    ti8),
     ("int16",       kstdtypesym,    ti16),
     ("int32",       kstdtypesym,    ti32),
     ("int64",       kstdtypesym,    ti64),
     ("uint8",       kstdtypesym,    tu8),
     ("uint16",      kstdtypesym,    tu16),
     ("uint32",      kstdtypesym,    tu32),
     ("uint64",      kstdtypesym,    tu64),
(I didn't add _t to avoid a clash; this is still a working compiler.)
In the set of tokens:
     (kstdtypesym,   $,  "k",    0),
In the parser, for the code that deals with a typespec:
     when kstdtypesym then
         d.typeno := lx.subcode
         lex()
Then a further 3 lines were modified to add 'kstdtypesym' to a list of type-starter tokens.
So in all, 12 new lines were added, and 3 lines modified. The extra 16 types of stdint.h would need 16 extra lines in the symbol table. The types there are hard-coded: the compiler knows its target!
(Some compilers may work with multiple targets, then it would be a little more elaborate.)
The size of the compiler increased by 38 code bytes, and 238 data bytes (or 254 if "_t" was used!).
The corresponding portion of stdint.h is 240 bytes, so actually there isn't much in it. It's just a more professional way of doing this stuff, and now the types really are part of the core language (support for suffixes and format codes is still needed).
However adding a feature such as MAXOF(T) definitely would be more efficient than those dozens of macros, and replaces much of limits.h too. Unfortunately you can't just add features like this.

I also tried to compile file contaning 100000 declarations

                                           ^^^^^^
Oops, should be 1000000.

Yeah, I got that!

like:
>
extern int a0(void);
....
extern int a999999(void);
>
Compilation of such file takes 1.737s, so about 575000 lines
per second.  So a lot of function declarations in header
files should not slow gcc too much.

>
I get these results (the test file has 'int main(){}' at the end):
>
   c:\c>tim gcc fred.c
   Time: 4.832
>
   c:\c>tim tcc fred.c
   Time: 4.620
>
   c:\c>tim bcc fred.c
   Compiling fred.c to fred.exe
   Time: 1.324
>
Bear in mind that both gcc/tcc are presumably optimised code; bcc isn't)

 On my machine tcc preprocesses probably about 20% faster than gcc.

Given that now tcc has a quite conformant preprocessor (unlike 0.9.26 which was very buggy), I had a theory that many compilers are just sharing the same one working implementation of it!
A difference of 20% is not significant when gcc is involved; the latter could be doing all sorts of extra things.

For timing compilation I used 'gcc -c' to generate linkable object
file, so no need to have 'main'.

I created EXEs since on bcc there was a tiny bug when generating OBJ without 'main', which meant I couldn't time it. (I'll deal with that later.)
However if I leave the main() in, then all can generate OBJ files instead, and the timings are pretty much the same.

When actually compilning on my
machine tcc is significantly faster, on the same file 'tcc -c'
takes 0.418s, so more than 4 times faster than 'gcc -c'.
 I do not know why 'tcc' is that much faster.

On mine it's roughly the same as gcc, even a locally built tcc. That was surprising. I thought it might be a poor hash function, as the 1M names are very similar. I tried a version with 1M random function names, but tcc was even slower (7.x seconds); gcc was the same, and bcc was 1.6 seconds.
If this was my product, I would investigate what was slowing it down.

 One possibility
is that 'gcc' contains various extra info in compiler data
structures that help when optimizing, but require extra effort
even when not optimiziong.

My test was with gcc 14.1. gcc 10.3 was about 4 seconds; faster than tcc! (Yeah, something 'off' there.)