Re: Computer architects leaving Intel...

On 9/4/2024 5:50 PM, MitchAlsup1 wrote:

On Wed, 4 Sep 2024 22:11:47 +0000, BGB wrote:
 

On 9/4/2024 3:18 PM, MitchAlsup1 wrote:

On Wed, 4 Sep 2024 20:15:24 +0000, Brett wrote:
>

David Brown <david.brown@hesbynett.no> wrote:

On 03/09/2024 21:28, Stefan Monnier wrote:

My impression - based on hearsay for Rust as I have no experience - is
that
the key point of Rust is memory "safety".  I use scare-quotes here,
since it
is simply about correct use of dynamic memory and buffers.
>
It is entirely possible to have correct use of memory in C,

>
If you look at the evolution of programming languages, "higher-level"
doesn't mean "you can do more stuff".  On the contrary, making
a language "higher-level" means deciding what it is we want to make
harder or even impossible.
>

>
Agreed.
>
I've heard it said that the power of a programming language comes not
from what you can do with the language, but from what you cannot do.

>
Wrong, the last version of Swift added all the garbage programming
concepts
that one should avoid.
>
You have to give people the tools to do anything.

>
It is impossible to create a computer programming language where
the programmer cannot shoot himself in the foot.

>
A language could alternatively try to go in a direction like HolyC:
   Take C:
     Remove most advanced features;
     Add some weird syntax tweaks;
     Make all the types explicit sized.
>
>
Some of it is almost half tempting, except that I would probably make
the type-names lower-case to match with my existing usage (and save
needing to hit SHIFT as often).
>
Say:
   u0: void
   u1: _Bool
   u8: unsigned char
   u16: unsigned short
   ...
   i16/s16: signed short
   i32/s32: signed int
   i64/s64: signed long long

 I suspect that My 66000 is the only current ISA that efficiently
supports::
     u7:
     u11:
     u15:
     u21:
     s47:
     s19:
..
 

AFAIK, HolyC only went as far as power of 2 types.
Ironically, other than this, it is mostly a minimalist C variant (similar to ideas I had mentioned in the past).
But, added some weirdness:
You can leave off the parenthesis and still call a function in some cases;
Say: "%d\n", i;
   Would function as an implicit "printf()";
...
Though, would be kinda funny to see some of the TempleOS stuff incorporated into other more mainline OS's...
Not found any "good" / semi-formal descriptions of either HolyC or TempleOS or how any of its stuff worked. There is apparently a still live fork now known as ZealOS, which ironically sorta makes more sense.
I guess contrast to BGBCC's take on C:
   Mostly a direct superset;
   Follows the convention of any non-standard keywords using "__";
     Unless one includes the relevant headers.
   Has SIMD extensions mostly inspired by GLSL;
     GLSL was a better fit to how I typically use vector types;
     Works well if one assumes primarily 2/3/4 element vectors;
     Though, also supports GCC's vector syntax;
       Does not support the MSVC/Intel "xmmintrin.h" system:
         Would not be a 1:1 match with BJX2, even if supported;
         Ugly and awkward to use;
         In theory, could be added as an emulation wrapper.
   Has some support for dynamic typing.
     But, this is rarely used in C land;
     Trying to write JS like code in C is "kinda cursed".
   Technically also has access to the BS2 object system.
     Mostly single inheritance class/instance with interfaces:
     Like Java and C#, with Java-like syntax;
     Supports dynamic classes, like ActionScript.
Most of the relevant keywords are #define'd in <tkvardef.h>, so technically one can include this header and "have at it" like they were doing Java or ActionScript in C (then looks at it, and realizes that it was still missing a few keywords).
I generally avoid this, as any code which does so can't be built in other compilers (building the TestKern runtime in GCC for RISC-V mode effectively requires omitting parts of it which use features which don't map over to GCC or RISC-V; but generally this was nothing "critical" for normal applications or "bare metal" programs, but can't currently rebuild a fully functional kernel for RISC-V mode; along with some ISA issues where a RISC-V kernel could not currently host non RISC-V programs due to register-space mismatch issues, namely that RV Mode can't save/restore all of the registers).
Though, part of this is because C and BS2 actually share the same parser and compiler front-end in this case, and the language selection more enables/disables logic paths in the parser.
It is actually similar for the C++ mode, but this is still too limited to realistically claim C++ support (*1). And, even if I did so, people in C++ land have a habit of trying to "upgrade" the code to chase the newest standard and features (so, say, even if I got C++98 support fully implemented, it wouldn't gain much, and almost isn't worth the bother).
*1: As-is, it is like EC++, but re-added namespaces, has (not well tested) support for templates, and (IIRC) operator overloading. IIRC, it could handle multiple-inheritance by mapping parent classes to "delegate" member variables within the single-inheritance model (effectively, the MI child class is a new root class with all of the parent classes as member variables).
Where, in the BS2 object model, marking a member variable as "delegate" causes the compiler to also search the object referenced in this member for any members not found in the inheritance tree of the containing class (not to be confused with C#, which uses this keyword to declare function or method pointers; but ironically these two uses are not incompatible).
There were differences, like in C++, "class" is a value type by default, and in BS and BS2, they were reference types (in BS, there was a separate "value_class" type for C++ like classes, this wasn't originally included in BS2, but the idea is still present in the object system, and used for C++ style classes).
Some extra wonk is needed for things like "obj->Foo::x", ...
And, most of this is not really tested.

   f32: float
   f64: double
   m32: opaque 32-bit type
   m64: opaque 64-bit type
   m128: opaque 128-bit type
>
....
>
Then, say:
u0 foo(args...)
{
    ...
}
>
Where, args is exposed as an array of u32 or u64 depending on the target
architecture.
>
....