if userland in asm, no need for libc?

[Polytropon]

On Tue, 15 Jan 2019 12:24:17 GMT, iam at sdf.org wrote:
> in continuum to my previous mail about libc;
> if the whole of userland and various other toolkits were written
> in assembly language, would there be no need for libc, that is
> if "c" were not needed to be supported at all?

Even a userland written in assembly _could_ interface with
the C library, i. e., call functions that are defined in there.
For this kind of interfacing, it doesn't really matter which
language has been used to create the library. Keep in mind
libc is "just a library", which is an archive of object code
(machine code "snippets"). Given a specific calling convention,
even assembly language can make use of it.

However, to come back to your initial question:

It would be possible to implement userland programs on the
basis of kernel interfaces and system calls, not using libc
at all. But that implies you'd have to implement a lot (!)
of functionality yourself. Remember strcmp(), or fopen(),
or signal()? All those facilities wouldn't be available.

Now you could say: Well, I create a library myself with all
those "subroutines" I permanently need to use. So what would
you end up with? With a libc equivalent. ;-)



> do assembly language programs have the capacity to make kernel
> calls directly? i.e., without going through any libraries?

Of course. There is a specific calling convetion that will
enable you to perform system calls, and this is a common way
to "relay" work to the kernel. The exact way to do this of
course depends on the OS, and it is different between FreeBSD
and Linux (e. g., "int 80h" vs. "syscall"), which makes this
kind of programming nonportable. Early stages of the boot process
as well as device drivers, being developed for _one_ OS in
particular, don't have to care for being that portable... :-)





-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...