Date: Tue, 15 Jan 2019 13:46:23 +0100 From: Polytropon <freebsd@edvax.de> To: iam@sdf.org Cc: freebsd-questions@freebsd.org Subject: Re: if userland in asm, no need for libc? Message-ID: <20190115134623.4a49687e.freebsd@edvax.de> In-Reply-To: <201901151224.x0FCOHbM016508@sdf.org> References: <201901151224.x0FCOHbM016508@sdf.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Jan 2019 12:24:17 GMT, iam@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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190115134623.4a49687e.freebsd>