Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Fri, 5 Jul 2024 10:48:32 -0500
Organization: A noiseless patient Spider
Lines: 308
Message-ID: <v694mr$3bhbs$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me>
 <v687h2$36i6p$1@dont-email.me> <v68sjv$3a7lb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 05 Jul 2024 17:49:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="39c124d3e74403081112702eedb03ac8";
	logging-data="3523964"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18EXCEwkos9cVL3BwNs2IKfoFeZym4MbeM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cXZ01xC0ZBbu6fYxUV/pT2SGffE=
Content-Language: en-US
In-Reply-To: <v68sjv$3a7lb$1@dont-email.me>
Bytes: 13177

On 7/5/2024 8:31 AM, bart wrote:
> On 05/07/2024 08:30, BGB wrote:
>> On 7/4/2024 8:05 PM, Lawrence D'Oliveiro wrote:
>>> It’s called “Rust”.
>>
>>
>> If anything, I suspect may make sense to go a different direction:
>>    Not to a bigger language, but to a more narrowly defined language.
>>
>> Basically, to try to distill what C does well, keeping its core 
>> essence intact.
> 
> That would just be rearranging the deck chairs I think.
> 
> Whatever the failings of C, it is so entrenched everywhere that it is 
> almost impossible to dislodge. Especially if you take out all the the 
> features that people apparently find indispensible.
> 
> There are anyway plenty of big-name contenders which change a LOT more, 
> and are full of modern, higher-level features that people seem to want.
> 

For what I want, at this point, is not a whole lot of high-level features.


> C also is the only language that is supposed to work on any kind of 
> processor; most of the others require a machine which has 8/16/32/64-bit 
> types and have little interest in unusual targets.
> 

Yeah.

In this case, I would assume limiting it to 32 and 64 bit machines.

My hobby ISA on FPGAs is 64-bit, albeit can use 32 or 64 bit pointers.
I mostly settled on using 64-bit pointers with 48-bit address space and 
16-bits for tag metadata (implicitly, the high 16 bits is ignored by 
normal Load/Store operations).

Though, the use of pointer-tagging is not entirely invisible to C, 
though, unless bounds-checking is enabled, the high 16 bits are 
typically zeroed for C data pointers (they are used for function 
pointers and link-register values though, to encode the intended 
operating mode for the CPU and similar).


> (Actually, the nearest language to C that I have seen, is mine. It stays 
> at about that level, but it has modern conveniences such as a module 
> scheme and proper name-spaces. However, it is a private language, and 
> also 1-based, case-insensitive and with non-brace syntax! It is not a 
> contender.)
> 

I would assume something that wouldn't be a massive pain for copy/paste 
translation.

> 
>> *1: While not exactly that rare, and can be useful, it is debatable if 
>> they add enough to really justify their complexity and relative 
>> semantic fragility.
> 
> C only has 1D arrays, but array elements can themselves be array types.
> 
> The only complication, a big one, is that modern C allows a variable 
> length for those array elements (so not known at a compile-time). This 
> is tied in with VLAs and 'variable modified types' or whatever the 
> feature is called.
> 
> This applies when the multi-array data is a single block of memory.
> 

At least one major C compiler has rejected VLAs entirely last I heard.


I added them experimentally, but it doesn't fully work.

I also made my compiler fall back to using them for arrays which are too 
big (over 16K, for sake of a 128K default stack size).

In this case, they are turned into heap allocations with automatic 
freeing on function return, but seemingly it is buggy and is currently 
prone to data corruption and memory leaks.


My attempt to port Quake3 ran into issues here as it regularly tried to 
use arrays over the size limit (though, some comments in the code 
implied that OSX did something similar, albeit with a 32K size limit; 
some functions though tried to use 64K or 128K local arrays, which isn't 
really going to fly short of boosting the stack size to 512K or 1MB).

Choice of stack size being:
   32K: Generally only small programs will fit;
   64K: Many programs fit, but some don't.
     Say, Doom can fit onto a 64K stack, Quake not so much.
   128K: Stuff generally fits (*1).


*1: Though, GLQuake and Quake3 required moving a lot of former stack 
arrays onto the heap.

Using larger stacks is undesirable though if one wants to support NOMMU 
operation, since if a program allocates 1MB and only uses 90K or so, 
then the remaining 934K are entirely wasted.



Generally, recursion and register save/restore by itself isn't enough to 
threaten a 128K stack, but large structs and arrays will do so readily.

Luckily, an ABI based around pass-by-reference has little issue with 
internally turning large structs into heap allocations.


Though, having a compiler which turns large arrays or large structs into 
a compiler error (vs giving a warning and turning them into heap 
allocs), probably wouldn't fly to well.



Though, in the attempted Quake3 port, did end up turning some large 
global structs into heap allocations as well, mostly as they caused the 
".bss" section to become so large that the PE loading was failing (at 
the moment stuff appears to break if the total size of the PE image goes 
over 8MB).

Then again, there is a limit at present (in my compiler) that the 
handling of relocs (in the PE export code) can't express sections larger 
than 8MB (the remaining bits of a 32-bit value are used to encode the 
reloc type and section number). It is possible I was hitting this limit 
(it was a TODO feature to expand this part of the code to use a 64-bit 
format for intermediate reloc handling).




>> If using pointers, one almost invariably needs to fall back to doing 
>> "arr[y*N+x]"
> 
> I've never had to do that, even if N was a variable. If using Iliffe 
> vectors then C allows you do regular indexing even with runtime bounds.
> 
>> Note that multidimensional indexing via multiple levels of pointer 
>> indirection would not be effected by this.
> 
> These are Iliffe vectors.
> 

Pros/cons.
For many uses, one still wants a contiguous buffer.

For some uses (typically limited to square power-of-2 arrays), I have 
used Morton order, but I also ended up adding special CPU instructions 
to deal with Morton order arrays.


> 
>> Similarly, structs may not be declared at the point of use, but only 
>> as types.
> 
> This is how it works on my language; they must be a named user-type. 
> It's crazy how C allows them just anywhere, even in useless declarations 
> like this:
> 
>    struct {int x,y;};
> 

Yeah.

As-is the parser needs to lift them out and put them in their own 
special part of the AST.

Ideally, one doesn't want this.

Ideally also one doesn't want to need to parse a crapton of prototypes 
and structs/typedefs/etc for every translation unit either.


========== REMAINDER OF ARTICLE TRUNCATED ==========