-1 to this idea from OpenBSD that all syscalls have to be routed through libc, requiring e.g. Golang to link to and run syscalls via libc.

Follow

Languages which are not C should not depend on C. A language design is much more compelling when its own compiler, runtime, stdlib, etc are self-hosting (i.e. written in the language itself). Constraining ourselves to a language design which can route all of its syscalls through the libc abstraction layer (which is THICK) constrains our language designs in ways I dislike.

@sir can we just create kernels and userspaces that aren't based in emulating 70s machines please

@sir also, ABI definitions shouldn't depend on C.

@Wolf480pl the ABI isn't an abstraction as much as it's a language. System-V is the lingua franca of ABIs and the constraints it imposes are managable/desirable and necessary for dissonant modules to communicate. By constraining ourselves to the C ABI then we (1) discourage being too clever and (2) prevent the introduction of FFI layers with awkward idiomaticy transitions

@Wolf480pl or, in other words, constraining ourselves to the C ABI *simplifies* our systems, whereas routing all syscalls through libc adds complexity.

@sir @Wolf480pl For an example of systems where such simplification didn't take place, look at VMS or Windows NT. In general, so long as your system is (trying to) implement POSIX, it makes sense to stick with the SysV ABI just as a sanity check.

@sir I guess we meant different things by ABI.

I meant ABI as in "binary signature of this particular set of functions", while you meant sth like "a method to translate source-level signature of a function to binary calling protocol".

Like, when you describe a type of a function, one way to do it is to write its C signature, like:

void* malloc(size_t);

which uses C-specific types eg size_t, or int, whose size can differ across machines, and can be different from the size of those types in the language from which you're calling this function from.

Alternatively, you could describe the function like this:

u8* malloc(i64);

which is IMO less ambiguouss.

Of course you still need to know the calling convention - in which registers to pass arguments, etc.. In theory it'd be nice if we had a declarative syntax to describe that, too, but I agree that it's better if all functions use the same calling convention.

@Wolf480pl yeah, this is the wrong definition of an ABI. You mean the C type system

@Wolf480pl though note that you lose some semantics here: void* is deliberately an untyped pointer (cause malloc doesn't know what you're using it for - it might not be u8) and size_t is an architecture-specific size. u8 also isn't always necessarily the lowest common denominator - it's *probably* (but not definitely) the smallest possible addressable unit, but it's also likely to be too slow for some use-cases. Not to mention encoding concerns like pointer alignment and so on... there are reasons C is the way it is and they should be taken account if considering a different API design

@sir can't find your opinion on vlang. it is self hosted, but it also claims to have C as the backend github.com/vlang/v/wiki/On-the

t. clueless

@tho I can write this off straight away because you said it has a C backend

@tho I built you this house out of books instead of plywood. Why don't you like it? I thought you liked books!

@sir I think, Mr DeVault, that this would be an appropriate time for you to create such a language to demonstrate :-)

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!