Re: Computer architects leaving Intel...

On 9/5/2024 8:27 AM, David Brown wrote:

On 05/09/2024 10:51, Niklas Holsti wrote:

On 2024-09-05 10:54, David Brown wrote:

On 05/09/2024 02:56, MitchAlsup1 wrote:

On Thu, 5 Sep 2024 0:41:36 +0000, BGB wrote:
>

On 9/4/2024 3:59 PM, Scott Lurndal wrote:
>
Say:
   long z;
   int x, y;
   ...
   z=x*y;
Would auto-promote to long before the multiply.

>
\I may have to use this as an example of C allowing the programmer
to shoot himself in the foot; promotion or no promotion.

>
You snipped rather unfortunately here - it makes it look like this was code that Scott wrote, and you've removed essential context by BGB.
>
>
While I agree it is an example of the kind of code that people sometimes write when they don't understand C arithmetic, I don't think it is C-specific.  I can't think of any language off-hand where expressions are evaluated differently depending on types used further out in the expression.  Can you give any examples of languages where the equivalent code would either do the multiplication as "long", or give an error so that the programmer would be informed of their error?

>
>
The Ada language can work in both ways. If you just have:
>
    z : Long_Integer;  -- Not a standard Ada type, but often provided.
    x, y : Integer;
    ...
    z := x * y;
>
the compiler will inform you that the types in the assignment do not match: using the standard (predefined) operator "*", the product of two Integers gives an Integer, not a Long_Integer.

 That seems like a safe choice.  C's implicit promotion of int to long int can be convenient, but convenience is sometimes at odds with safety.
 

A lot of time, implicit promotion will be the "safer" option than first doing an operation that overflows and then promoting.
Annoyingly, one can't really do the implicit promotion first and then promote afterwards, as there may be programs that actually rely on this particular bit of overflow behavior.
In effect, in my case, the promotion behavior ends up needing to depend on the language-mode (it is either this or maybe internally split the operators into widening or non-widening variants, which are selected when translating the AST into the IR stage).
Well, as opposed to dealing with the widening cases by emitting IR with an implicit casts added into the IR.

 

If you add this definition to the code:
>
    function "*" (Left, Right : Integer) return Long_Integer
    is (Long_Integer(Left) * Long_Integer(Right));
>
the compiler sees that there is now /also/ an Integer * Integer => Long_Integer multiplication operator, and uses that. Function overloading in Ada can depend on the type expected of the result.
>

 You can make types in C++ that have this effect, but you have to make them and use them consistently.  You can't overload operators on standard types like that.
 

Perhaps you asked for a language that worked like this "out of the box", without the programmer having to add things like the "*" function above, and then Ada would not qualify on the second alternative (automatic lengthening before multiplication, depending on the result type desired).
>

 I asked for either, and you gave me both :-)
 

>

(I don't count personal one-person languages here.

>
While Ada has low market penetration, I don't think it quite qualifies as a one-person language -- yet :-)
>

 

Ironically, my language isn't itself well specified or tested, but ironically, much of the core of the implementation is tested, in my case, for sake of the same code also being used for compiling C.
Well, and in some cases I went and added C23 proposed lambdas (which reused C++ syntax), mostly because BS2 already had lambdas (so, it was mostly a parser thing in this case). But, then, C23 didn't add lambdas.
But, ironically, I had ended up with two implementations of BS2:
   At first, I started prototyping it in BGBCC;
   But, then switched to a new VM for my 3D engine;
     I wanted to do "load from source" like Doom 3;
     Load from source would have been an issue with BGBCC;
     But, then still ended up mostly using static-compiled bytecode;
     Like, it adds overhead to compile stuff at startup time.
   Now, I am back mostly to BGBCC.
It is kinda sad in a way though, as the new VM did have a nicer AST system and a better designed bytecode format. I did since make the AST's in BGBCC "slightly less bad", but would be more work to redesign the bytecode (and efforts keep fizzling out as the existing bytecode "works good enough").
And, then one can argue, "if you are going to redesign the bytecode anyways, why not jump over to CIL / MSIL ?...", which could almost work except that the structure of the metadata is awkward/inflexible and does not map over well to BGBCC (which had used a more JVM-like structure), and was more designed for C# and is an awkward fit to C.
Well, also the way they are used is different, where BGBCC mostly uses RIL as a stand-in for object files and static libraries. And a "lazier but semi-good" option might be to stick to the existing RIL format, but have a separate RIL object per translation unit (rather than all of the TU's in the compiler invocation), with a "symbol manifest" (more like in ".a" libraries). Then maybe pulling in objects as needed when it walks the reachable graph.
With the closest equivalent in MSVC being MSIL inside of COFF objects (or, in GCC land, GIMPLE code inside of object files). But, generally, there is no real expectation of object-file compatibility between compilers.
Though, more tempting to use WAD2 or WAD4 because the "!<arch>" format kinda sucks... (Well, and this was also sort of my plan in my stalled "new compiler" effort, which had intended to use tweaked WAD2 variants as both the object files and library files).
Might make sense to add a second FOURCC for "intention":
   struct Wad2aHeader_s {
     FOURCC magic;    //00 'WAD2'
     DWORD numLumps;  //04 number of directory entries
     DWORD ofsLumps;  //08 offset of lump directory in image
     DWORD ofsTags;   //0C: *
     DWORD resv0;     //10: Reserved (WAD4: Allocation Bitmap Offset)
     DWORD resv1;     //14: Reserved (WAD4: Allocation Bitmap Size)
     FOURCC intent1;  //18: Intention for image use.
     FOURCC intent2;  //1C: Intention sub-type
   };
*: WAD2: N/A / Zero
    WAD2A: FCC Tags and/or file extensions for lump types.
    WAD4: Offset of directory lookup hash table.
Normally, WAD2 lumps omit the file extension from the name, and use a 1-byte type tag. The meanings of this tag bytes were hard-coded in Quake and Half-Life, but for my uses I added a table to map lump types to FOURCC's or 3-char file extensions.
In contrast, WAD4 has file extensions in the lump names (32 bytes, unlike the 16-byte names in WAD2). Also 64 byte directory entries rather than 32. So, had used this spot to give the location of a prebuilt hash table used to be able to lookup entries more quickly.
Where, say, intent is 0/ignored if the WAD is being used as a basic container, but may be other values if being used to construct a more specialized format, as opposed to changing the main FOURCC, similar to the secondary main type FOURCC in RIFF.
If I put it at 0x18, it could be at the same offset in both formats.
Would have been more "elegant" to put it at 0x0C, but alas.
...