On 2/4/2022 6:01 AM, Paul Backus wrote:
>> Trying to hide the reality of how computer integer arithmetic works, and how integral promotions work, is a prescription for endless frustration and inevitable failure.
> 2s-complement is "the reality of how computer integer arithmetic works," but there is nothing fundamental or necessary about C's integer promotion rules, and plenty of system-level languages get by without them.

The integral promotion rules came about because of how the PDP-11 instruction set worked, as C was developed on an -11. But this has carried over into modern CPUs. Consider:

void tests(short* a, short* b, short* c) { *c = *a * *b; }
        0F B7 07                movzx   EAX,word ptr [RDI]
66      0F AF 06                imul    AX,[RSI]
66      89 02                   mov     [RDX],AX
        C3                      ret

void testi(int* a, int* b, int* c) { *c = *a * *b; }
        8B 07                   mov     EAX,[RDI]
        0F AF 06                imul    EAX,[RSI]
        89 02                   mov     [RDX],EAX
        C3                      ret

You're paying a 3 size byte penalty for using short arithmetic rather than int arithmetic. It's slower, too.

Generally speaking, int should be used for most calculations, short and byte for storage.

(Modern CPUs have long been deliberately optimized and tuned for C semantics.)

On 2/4/2022 12:31 PM, H. S. Teoh wrote:
> PDP-11 instructions no longer resemble how modern machines work, though.
> What made sense back then may not necessarily make sense anymore today.

The PDP-11, no, but the modern machines *definitely* hew to how C works, see my other post in this thread.

On Fri, Feb 04, 2022 at 08:50:35PM +0000, Mark via Digitalmars-d wrote:
> On Friday, 4 February 2022 at 04:28:37 UTC, Walter Bright wrote:
> > There's really no fix for that other than making the effort to understand 2s-complement. Some noble attempts:
> > 
> > Java: disallowed all unsigned types. Wound up having to add that back in as a hack.
> 
> How many people actually use (and need) unsigned integers?

I do. They are very useful in APIs where I expect only positive values. Marking the parameter type as uint makes it clear exactly what's expected, instead of using circumlocutions like taking int with an in-contract that x>=0.  Also, when you're dealing with bitmasks, you WANT unsigned types. Using signed types for that will cause values to get munged by unwanted sign extensions, and in general just cause grief and needless complexity where an unsigned type would be completely straightforward.

Also, for a systems programming language unsigned types are necessary, because they are a closer reflection of the reality at the hardware level.


> If 99% of users don't need them, that's a good case for relegating them to a library type.  This wasn't possible in Java because it doesn't support operator overloading, without which dealing with such types would have been quite annoying.

Needing a library type for manipulating bitmasks would make D an utter joke of a systems programming language.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.

On Friday, 4 February 2022 at 21:13:10 UTC, Walter Bright wrote:
> The integral promotion rules came about because of how the PDP-11 instruction set worked, as C was developed on an -11. But this has carried over into modern CPUs. Consider:
>
[...]
>
> You're paying a 3 size byte penalty for using short arithmetic rather than int arithmetic. It's slower, too.
>
> Generally speaking, int should be used for most calculations, short and byte for storage.

Sure. That's a reason why I, the programmer, might want to use int instead of short or byte in my code. But if, for whatever reason, I've chosen to use short or byte in spite of the performance penalties, I would rather not have the language second-guess me on that choice.

On Friday, 4 February 2022 at 21:13:10 UTC, Walter Bright wrote:
> It's slower, too.

Not anymore.  And div can be faster on smaller integers.


> You're paying a 3 size byte penalty for using short arithmetic rather than int arithmetic.

1. You are very careful to demonstrate short arithmetic, not byte arithmetic, which is the same size as int arithmetic on x86.

2. Cycle-counting (or byte-counting) is not a sensible approach to language design.  It is relevant to language implementation, maybe; and whole-program performance may be relevant to language design; but these sorts of changes are marginal and should not get in the way of correct semantics.

3. Your code example actually does exactly what you suggest--using short arithmetic for storage.  It just happens that in this case using short calculations rather than int calculations yields the same result and smaller code.

4. (continued from 3) in a larger, more interesting expression, regardless of language semantics, the compiler will generally be free to use ints for intermediates.

On 2/4/2022 6:12 AM, Adam D Ruppe wrote:
> I'd allow that. The input is a and b, they're both short, so let the output truncate back to short implicitly too. Just like with int, there's some understanding that yes, there is a high word produced by the multiply, but it might not fit and I don't need the compiler nagging me like I'm some kind of ignoramus.

As I observed before, there is no solution. Just different problems. It's best to stick with a scheme that has well-understood issues and works best with the common CPU architectures.