Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 5 Sep 2024 14:38:48 -0500
Organization: A noiseless patient Spider
Lines: 179
Message-ID: <vbd1ce$faja$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <jwv8qw8o7zg.fsf-monnier+comp.arch@gnu.org> <vb85a3$3gq7e$2@dont-email.me>
 <vbaf4s$3vcq1$1@dont-email.me>
 <e869564c7aec3d40d2ac8b5aa003cef4@www.novabbs.org>
 <vbalv9$g96$1@dont-email.me>
 <041684754468dde00ae3f1cacf51cd1c@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 05 Sep 2024 21:38:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1f25f004199ea0f4099eed49c6b1bb6d";
	logging-data="502378"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+WzCfKK6+CDNK9FNmgkQ67UIFuUy2FPrQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:p0CrsQUbE0YF6QPR6hrVTgFR9A4=
In-Reply-To: <041684754468dde00ae3f1cacf51cd1c@www.novabbs.org>
Content-Language: en-US
Bytes: 8648

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
>>
========== REMAINDER OF ARTICLE TRUNCATED ==========