Re: cpplib: Charconsts and escape sequences

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Zack Weinberg wrote:-

> Which is what we do now (HOST_WIDE_INT == long long when the target is
> 64-bit) but it's unfortunate that we need to; it makes the entire
> compiler go slower, when very wide math is only needed in a few places
> (bitsizetype calculations, IIRC)

This HOST_WIDE_INT being long long; is that for the benefit of CPP or
the compiler?  I was under the impression it was for the compiler
proper.

I don't want to use long long by default; I'd like to stick with (two)
unsigned longs, which is enough for 99% of crosses.

As for speed, it's only CPP arithmetic, which I doubt is performance
critical, and two-integer calculations are only noticeably more
complex and slow for *, % and /, so I'm not really persuaded by the
speed argument.  Any generic library will be even slower I'm sure.

(Or are you talking about the compiler in general?)

(Can GNU MP handle non-round things like 36-bit or 48-bit numbers?
I imagine it can; I intend handling such things since I seem to recall
GCC targeting such beasts.)

> I don't think we need the entire of GNU MP, just the capability to use
> N-integer tuples under well-defined conditions.  Really, all I want at
> this stage is for all new interfaces to be general enough that going
> to N-integer tuples doesn't require editing code everywhere.  In
> other words,
> 
>   wide_integer_t add (wide_integer_t addend1, wide_integer_t addend2);
> 
> not
> 
>   void add (uintN *hi_sum, uintN *lo_sum, hi_1, lo_1, hi_2, lo_2);

I was going for a cpp_num typedef, with a cpp_num_part typedef for the
halves it's made up from, so that the interface would be closer to your
first line.  I'm not sure whether to pass them by value or by pointer;
by value gives cleaner code and I doubt it makes a huge difference
since the compiler probably passes such structs by pointer anyway.
Whatever we use, it needs an "unsignedp" boolean like now, and so to
not waste padding I also have added the "enum cpp_ttype" indicating the
operation, so that the op / value stack is purely an array of cpp_num
types, in place of the current "struct op".

If speed is really a concern, we could come up with a conditonal
compilation or macro hack to use a single host type when possible.

Anyway, why don't I come up with a patch, and you say what you do
or don't like about it then?

Neil.