Path: ...!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: Re: transpiling to low level C
Date: Wed, 25 Dec 2024 15:43:29 -0600
Organization: A noiseless patient Spider
Lines: 359
Message-ID: <vkhuaa$2ijo6$1@dont-email.me>
References: <vjlh19$8j4k$1@dont-email.me>
 <vjn9g5$n0vl$1@raubtier-asyl.eternal-september.org>
 <vjnhsq$oh1f$1@dont-email.me> <vjnq5s$pubt$1@dont-email.me>
 <vjpn29$17jub$1@dont-email.me> <86ikrdg6yq.fsf@linuxsc.com>
 <vk78it$77aa$1@dont-email.me> <vk8a0e$l8sq$1@paganini.bofh.team>
 <vk9q1p$oucu$1@dont-email.me> <vkb81n$14frj$1@dont-email.me>
 <20241223134008.000058cf@yahoo.com> <86frmedrof.fsf@linuxsc.com>
 <vkgk0u$2bh1n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Dec 2024 22:43:39 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d0b6fc13f6ed5769626df891f2167fc1";
	logging-data="2707206"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18zitLlwiJFOWfhe8dI8gkjyO7mwgrE4/g="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qF5B4JW1mWAAZZAGM1lz9easYO4=
Content-Language: en-US
In-Reply-To: <vkgk0u$2bh1n$1@dont-email.me>
Bytes: 15784

On 12/25/2024 3:41 AM, BGB wrote:
> On 12/23/2024 3:18 PM, Tim Rentsch wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 23 Dec 2024 09:46:46 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>
>>>> And Tim did not rule out using the standard library,
>>>
>>> Are you sure?
>>
>> I explicitly called out setjmp and longjmp as being excluded.
>> Based on that, it's reasonable to infer the rest of the
>> standard library is allowed.
>>
>> Furthermore I don't think it matters.  Except for a very small
>> set of functions -- eg, fopen, fgetc, fputc, malloc, free --
>> everything else in the standard library either isn't important
>> for Turing Completeness or can be synthesized from the base
>> set.  The functionality of fprintf(), for example, can be
>> implemented on top of fputc and non-library language features.
> 
> 
> If I were to choose a set of primitive functions, probably:
>    malloc/free and/or realloc
>      could define, say:
>        malloc(sz) => realloc(NULL, sz)
>        free(ptr) => realloc(ptr, 0)
>      Maybe _msize and _mtag/..., but this is non-standard.
>        With _msize, can implement realloc on top of malloc/free.
> 
> For basic IO:
>    fopen, fclose, fseek, fread, fwrite
> 
> printf could be implemented on top of vsnprintf and fputs
>    fputs can be implemented on top of fwrite (via strlen).
>    With a temporary buffer buffer being used for the printed string.
> 
> ...
> 
> 
> Though, one may still end up with various other stuff over the interface 
> as well. Though, the interface can be made open-ended if one has a 
> GetInterface call or similar, which can request other interfaces given 
> an ID, such as, FOURCC/EIGHTCC pair, a SIXTEENCC, or GUID (*1). IMHO, 
> generally preferable over a "GetProcAddress" mechanism due to lower 
> overheads; tough, with an annoyance that interface vtables generally 
> have a fixed layout (generally can't really add or change anything 
> without creating binary compatibility issues; so a lot of tables/ 
> structures need to be kept semi-frozen).
> 
> Though, APIs like DirectX had dealt with the issue of having version 
> numbers for vtables and then one requests a specific version of the 
> vtable (within the range of versions supported by the major version of 
> DirectX). But, this is crufty.
> 
> *1: Say: QWORD qwMajor, QWORD qwMinor.
>    qwMajor:
>      Major ID (FOURCC, EIGHTCC)
>      Or: First 8 bytes of SIXTEENCC or GUID
>    qwMinor:
>      SubID/Version (FOURCC or EIGHTCC)
>      Second 8 bytes of SIXTEENCC or GUID.
>    Where:
>      High 32 bits are 0, assume FOURCC.
>      Else, look at bits to determine EIGHTCC vs GUID.
>      Assume if both are EIGHTCC, value represents a SIXTEENCC.
>      Bit patterns for valid SIXTEENCCs vs GUIDs are mutually exclusive.
>      Names make more sense for public interfaces.
>        Leaving GUIDs mostly for private/internal interfaces.
> 
> Well, unlike Windows, where they use GUIDs for pretty much everything 
> here (and also, I didn't bother with an IDL compiler; generally doing 
> all this directly in C).
> 

Clarification:
Though, despite taking influence from COM, it is not COM.

I am not using the COM API, and generally practices regarding vtable 
structure, etc, are a bit more loose.



There is also not currently any plan to actually implement the OLE or 
COM APIs. Only that some similar ideas are in use.

Pretty much everything else is different...

COM uses a 16-byte struct to convey a GUID;
I was using pairs of 64-bit integer values.

....

Some ideas from OLE, such as storing object instances from one library 
in a "document" held by an unrelated program instance, and then 
saving/reloading them later, are not a thing in my case.

It is possible I could consider doing something similar to OLE, but I 
don't have an immediate use-case (and, more often, I was using the 
object interfaces internally for things like OS level APIs).


Note that many core OS APIs are still a bit more mundane, like:
   memory is still managed using pointers;
   files IO is still managed using integer handles;
   ...


Though, within the kernel, open VFS files are implemented via objects 
with vtable pointers. This detail is not exposed to program instances, 
where the system calls identify them via integer handles.


Well, and also I am using a Unix style directory tree structure, rather 
than drive letters.

But, does differ some in things like locating DLLs for a program:
   ELF:
     Either "/lib/", "/usr/lib/",
     or a hard-coded path in the binary.
   Win:
     Check current directory;
     Then search PATH;
   TK:
     Check first in the directory the EXE is found;
     Then search LIBPATH;
     Then search PATH.

Hard coding paths in the binary does mean though that the installation 
path for any binaries that depends on custom SO's is fixed, which is not 
ideal. Checking relative to the binary allows more flexible installation 
paths.


> 
> Well, and some wonk, like the exact contents of structures like 
> BITMAPINFOHEADER being interpreted based on using biSize as a magic 
> number (well, sometimes with other stuff glued onto the end, as 
> understood based the use of the biCompression field), ...
> 
> But, it has held up well, this structure being almost as old as I am...
> 

Clarification:
I am towards the older end of the Millennial / Gen Y age range...

Started existence in the IBM Clones and MS-DOS era, but by the time I 
was using computers, was mostly in the era of Windows, CD-ROM based FMV 
games, and early/slow internet.


> 
> 
> In a few cases, one might also take the option of using a "DriverProc()" 
> style interface, where one provides a pair of context-dependent pointers 
> and uses magic numbers to identify the desired operation, or, intermediate:
>    (*ifvt)->QueryProc(ifvt, iHdl, lParm, pParm1, pParm2);
>    (*ifvt)->ModifyProc(ifvt, iHdl, lParm, pParm1, pParm2);
> 
> Where, QueryProc is intended for non-destructive operations, and 
> ModifyProc for destructive operations.
>    iHdl: Context-dependent integer handle;
>    lParm: Magic command number.
>    pParm1/pParm2: Magic pointers, often:
>      pParm1: Input data address;
>      pParm2: Output data address.
> 
> Where, vtable is usually provided in "VT **" form, hence the need to 
> deref the table before a method can be invoked.
> 

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