Non-constant constant strings

[Keith Thompson]

in <[email protected]>:
#> If a, b, and c are of some built-in type, then `a = b + c;` cannot
#> involve any function calls in either C or C++.
#
# Sure it can. It could involve a call to a function called __addquad().

Seebs of course makes a good point. My point was that even in C++,
you can't overload an operator for a built-in type that already
has that operator. You can't write your own

double operator+(double, double);

that will be invoked when you add two double values.

And even if addition for some type is implemented as a function
call, its semantics are still defined by the standard's rules for
operators, not by the rules for function calls.

I remember Dan Pop once told me about a C implementation for a Z80 (an
8-bit CPU). On this CPU, 16bit addition uses two of three register pairs
("ADC HL,BC") and I'm confident it would call a function saving and
restoring the registers clobbered.

I would be unsurprised if the saving and restoring of the registers
were done with inline code rather than function calls. But I'm
not familiar with the Z80, and perhaps a function call saves enough
code size to make it worthwhile.

 

[David Brown]

Seebs of course makes a good point. My point was that even in C++,
you can't overload an operator for a built-in type that already
has that operator. You can't write your own

double operator+(double, double);

that will be invoked when you add two double values.

And even if addition for some type is implemented as a function
call, its semantics are still defined by the standard's rules for
operators, not by the rules for function calls.


I would be unsurprised if the saving and restoring of the registers
were done with inline code rather than function calls. But I'm
not familiar with the Z80, and perhaps a function call saves enough
code size to make it worthwhile.

I haven't used a Z80 C compiler for 30 years, but in general (for small
cpus) it is hard to make "save volatile registers" into a function call
because the registers are usually saved on the same stack as the return
address. The extra stack manipulation needed to make it work means it
is seldom worth the effort. "restore volatile registers" is easier,
because the epilogue of normal functions will often be a sequence of
register "pops" to restore the volatile registers, followed by a
"return". You can then have a single common copy of this, and replace
the epilogues of normal functions with a "jump" into the appropriate
point of this sequence.

Some compiler/cpu combinations have separate data and return stacks,
which let you make the save/restore sequences be function calls. The
Imagecraft AVR compiler is one example that used this to save space (the
AVR has 32 registers, but no multi-register save or restore, so big
functions require saving and restoring a lot of registers individually).