From: david.brown@hesbynett.no

On 01/12/2025 12:37, bart wrote:
> On 01/12/2025 07:36, David Brown wrote:
>> On 01/12/2025 02:32, Keith Thompson wrote:
>>> Michael S  writes:
>>> [...]
>>>> Now, if you ask me, I don't understand why Waldek Hebisch considers
>>>> difference between 8-bit and [byte-addressable] 16-bit targets
>>>> important. As far as size of relevant C types goes, they look the same:
>>>> char - 8 bits
>>>> int - 16 bit
>>>> long - 32 bits
>>>> There is possibly difference in the size of 'short', but I don't
>>>> understand why it matters.
>>>
>>> Given 16-bit int, short is almost certain to be 16 bits as well.
>>>
>>> char is requires to be at least 8 bits, short and int at least 16, and
>>> long at least 32 (and long long at least 64).
>>>
>>> Or is 8-bit short used in some non-conforming mode?
>>>
>>
>> Some C compilers for 8-bit devices have non-conforming modes with
>> 8-bit int.  (I've seen one that, by default, had 16-bit int but did
>> not promote 8-bit types to int for arithmetic.  That caused some
>> subtle problems for us.)  I don't know if SDCC has such a mode
>> (avr-gcc does).
>
> That sounds sensible to me. It's how my language for Z80 worked (and
> that carried on into x86 until I introduced promotions).

It is entirely sensible that a language designed for 8-bit devices
should have 8-bit types for key arithmetic use.  But we are not talking
about a language designed for 8-bit devices, or any other language, we
are talking about C.

C has its language rules for how arithmetical operators work.  You can
question the wisdom of the integer promotions rules in C - I know that
/I/ dislike some aspects of them.  But like them or not, that is how C
is defined.  And a compiler that calls itself a C compiler but does not
follow those rules is a broken tool that will cause unexpected problems
with perfectly good C code.  That is what I experienced with a
particular so-called C compiler for an 8051 - it was expensive and
pointlessly and dangerously non-conforming.

I'd be happy if C did not have integer promotions.  I'd be happy if it
did not have implicit conversions between signed and unsigned types (as
long as writing literals was still convenient) - or if conversions were
always value preserving.  But given the rules C has, I write my C code
to be correct according to those rules - and I expect C compilers to
implement according to those rules.

I'm also happy with extra flags to change the behaviour (though I would
often prefer pragmas, since those are tied tighter to the source code in
question).  If a compiler provides a "--ints-are-8-bit" or
"--no-integer-promotions" flag, that's fair enough.  But it should
follow the standard rules unless told otherwise.  (And yes, I /know/
that gcc does not follow all the rules of C by default and requires
explicit flags to be conforming - that's a mistake on gcc's part IMHO.)

>
> If performing arithmetic on two 8-bit variables, on a machine with poor
> 16-bit support, you don't want the inefficiency of promoting both to
> 16-bit (needing extra instructions), doing the operation at 16 bits
> (which may need extra instructions), and then probably discarding the
> high byte anyway.

I might not have been doing arithmetic on 8-bit systems /quite/ as long
as you have, but this is not news to me.

>
> There were some issues with that, that you had to be aware of:
>
>      byte a := 255
>      print a + 1
>
> This would show 0 not 256.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)