Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8206

Re: How to bind HLLs to OS calls

Show key headers only | View raw

On Thu, 18 Jun 2015 13:24:52 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message  
> news:op.x0ewr50gyfako5@localhost...
>> On Wed, 17 Jun 2015 11:05:30 -0400, James Harris  
>> <james.harris.1@gmail.com> wrote:

>>> If such OS functions are in CLIB then is that the right place for them?
>>
>> It's probably the "OS library" integrated into the "CLIB".
>>
>> You need at least 18 to 20 OS functions to implement a C library,
>> including the half dozen low-level Unix file I/O functions.
>
> You may need just 18 to 20 to implement the C library but it seems that  
> libc has to include over 100 (possibly over 200) wrapper functions just  
> for Unix so that calls to a Unix OS are available to C programs. See the  
> list at
>
>   http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html
>

Yes.

Linux 2.6.17 kernal has 290 syscalls, whereas Linux v0.01 had 40.
Well, v0.01 had 67 actually.  13 were unused.  14 were minimally
implemented.  Only 40 were complete.  You can look at DrAcOnUx's
update of v0.01 here:

http://draconux.free.fr/os_dev/linux0.01.html

> ISTM now that just about all of those need to have a wrapper in libc.

I'm not as familiar with Linux as DJGPP.  With DJGPP, the C function
has assembly wrapped around the OS call, i.e., DPMI through to DOS.

> Essentially the C compiler has to recognise and provide subroutines for  
> every single OS call that a program might make, making that version of  
> libc OS-specific.

s/C compiler/either the CLIB or LIBC

> I had assumed that libc had code just for the C library functions so it  
> was a C library not a Linux C library or a Windows C library etc.

AFAIK, there is no reason they have to be merged together.
It's convenient to have the headers in the same directory.
The C code for routines are usually compiled into libraries.
Does it matter if you have one or two libraries?  I.e., merged
or separate?  IDK ...

> Windows has many more OS functions, doesn't it? Would a C compiler for  
> Windows have to provide handlers for every possible Windows OS call?

I don't have any information on Windows.

The Java virtual machine had 206 bytecodes at one point in time
and Single UNIX V3 specification has 1,742 functions.

>>> What if we want to call an OS function from another language, say  
>>> Pascal?
>>
>> There would need to be code to convert the Pascal call to the OS call.
>>
>>> Would there be a Pascal library which *also* has to match
>>> the target OS?
>>
>> I would assume so.
>
> And if there are Cobol or Fortran or Haskell or etc compilers which have  
> to provide OS access they all need to have subroutines for each OS call?
>
> That seems like a lot of work and a lot of duplication of effort. And it  
> seems to be a maintenance headache in that when a new version of the OS  
> is released with a new API all of the compilers need to adjust their  
> libraries to match.

Why did M$ once support the Pascal calling convention with C? ...

> And, of course, such compiler providers need to have bindings for each  
> OS that the compiler will run on.
>
> And if someone comes out with a new OS all the compilers (that will run  
> on that OS) need to be adjusted again to bind to the subroutines for  
> that new OS.
>
> And if a hobbyist comes out with a new OS he has to persuade compiler  
> writers to add functions to support his OS?
>
> Surely that cannot all be right. As you can probably gather I cannot see  
> the sense in doing things as described.

...

>>> If we make a new OS which has its own API would we have to get our  
>>> function callees also into CLIB and Pascal's library [...]
>>
>> Yes.  The C library is build on the OS API.  At minimum, eighteen
>> to twenty OS functions are needed.  I posted these to a.o.d. in 2008:
>>
>> K&R C, e.g., PDP-7 and/or PDP-11 UNIX C libraries:
>> open, close, read, write, creat, link, fork, exec, wait, exit, lseek,  
>> pipe
>>
>> PJ Plauger's "Standard C Library" book:
>> clock, close, environ, execl, exit, fork, getpid, kill, link, lseek,  
>> open,  read, sbrk, signal, time, unlink, wait, write
>>
>> Redhat's newlib:
>> close, environ, _exit, execve, fork, fstat, getpid, isatty, kill,  
>> link,  lseek, open, read, sbrk, stat, times, unlink, wait, write
>>
>> You might also want to add "unlink" for the K&R C set ...
>
> I am not sure if you are talking about calls which are needed in order  
> for C library functions to complete their work, or the little shims  
> (wrappers, if you like) that are also needed so that C source can call  
> OS functions. A C library can be written in terms of limited functions  
> that a certain OS provides but there's no control over which OS calls a  
> C programmer might want to make.

The way this works is the C library is written entirely in pure C code
without using any other C functions, except for the few listed above,
which are present as C functions to the C library.  These minimal
functions required to implement the library may have shims or wrappers
depending on how they're implemented.  I'd suspect that generally
they're in C but also using inline assembly to call the host OS function,
i.e, shim or wrap etc.

Of course, a C library like GLIBC is going to call from 40 to 290 or more
C functions which wrap/shim etc the OS API call(s).

>>> (I don't want to call my OS functions directly as that would limit  
>>> application source code to one specific means of getting to the kernel,
>>
>> Why is that an issue?
>
> Two reasons:
>
> 1. A given version of the kernel may be invoked by a software interrupt  
> or SYSENTER or SYSCALL or a far call or something else. They are all  
> hard or impossible to write in C or another HLL, and the best approach  
> may change.
>
> 2. Some OS calls may be satisfiable without taking the trip to privleged  
> mode. In that case it makes sense to have the subroutine which is  
> immediately called by the app just do the work necessary and return  
> without invoking the kernel.

By "call my OS functions directly," I thought you meant something like:

    call_my_OS(0xNN);

I.e., it was presented as a C function for C.

Each of those minimal 18 or 20 functions would be calling the OS directly
too, but from a C named function.

> 1. A given version of the kernel may be invoked by a software interrupt  
> or SYSENTER or SYSCALL or a far call or something else. They are all  
> hard or impossible to write in C or another HLL, and the best approach  
> may change.

So, they should be easily called from the host language without special
code or special language attributes or #pragma's etc, yes?  I.e.,
call_my_OS() for C, or jmp far call_my_OS for assembly, etc.

> 2. Some OS calls may be satisfiable without taking the trip to privleged  
> mode. In that case it makes sense to have the subroutine which is  
> immediately called by the app just do the work necessary and return  
> without invoking the kernel.

If you don't have to invoke the kernel, do these constitute an OS function?

>>> Implementing all OS services as functions allows some to be handled  
>>> in  user mode without forcing all to transition to privileged mode.)
>>
>> Yes, but I think you would need a library of each language, except
>> the primary language used for the OS API, e.g., except assembly.
>
> Sorry, I don't understand that sentence.

s/of/for

Essentially, I was saying you need to do what you responded to above as:
JH> "That seems like a lot of work and a lot of duplication of effort."
Every compiler would "need to have subroutines for each OS call" in order
"to provide OS access."

>>> [...]
>>
>> So, functions overloaded with multi-language support? ...
>
> Yes. One interface per calling convention rather than one per language.

How do you unify that across multiple languages which have different
methods for calling a function and different calling conventions?

To sufficiently abstract this in the way you're wanting it to be,
I'd think it'd have to be via a common feature of all OSes.  Perhaps,
such as file I/O for platforms where "everything is a file" philosphy
is implemented.  E.g., you write out a text file the parameters, or
a IPC message as text, a function is called without parameters for
the host language, the function being called reads the text file and
parses it.  IIRC, you were discussing something like this in the past,
e.g., text formatted data, such as XML, and binary endian conversions
between modules, or across the network, etc.

>> I guess that depends on the similarity of the implementation of the
>> underlying languages.  Similar would mean that it's possible. Different
>> would mean that it's not, or not easily.
>

Also, see above.  Text files might be a round-about solution.

>> I guess that depends on the similarity of the implementation of the
>> underlying languages.  Similar would mean that it's possible. Different
>> would mean that it's not, or not easily.
>
> The benefit would be to have the library of OS-interface functions  
> provided with the OS, regardless of how many languages call that OS,  
> rather than one library per language per OS.

IIUC, you can have a common "library of OS-interface functions," but each
language would need to have a wrap/shim etc to call the OS.  E.g., if the
OS API is in assembly, say like Int 0x80 for Linux, C functions must wrap
or shim Int 0x80 to call the OS, Pascal too, Fortran too.  If the OS API
is in C, then assembly, Pascal, Fortran would need to wrap or shim the C
function.  It's easier to wrap/shim etc than it is to support more than
one interface language for the OS, especially if you have a large number
of functions to support.  If the set of OS functions is small, then the
OS could support each set in a multitude of languages directly, but then
you've just shifted the shim/wrap issue from the C, Pascal, Fortran
library domain to the OS API domain.

> I am thinking that the library would be provided by the OS developer
> and all languages could use its subroutines.
>
> Is that feasible?

I'm not real sure what you're asking here ...

If you're specifying the OS API for your OS, then all languages implemented
on your platform have to use it.

> I know that there would need to be some interface info for each language  
> (for C that would be header files) but the interface info for all  
> languages could be generated from a single source so would only have to  
> be defined once, and the implementing code itself (that applications  
> call) would only have to be written once.

Ok.  That usually requires some sort of automatic tool to build such files.
E.g., M4, Gnu Make or Auto-conf, perhaps Grep or AWK or C preprocessor,  
etc.
The C preprocessor has been used to preprocess or create code for other
situations.  Personally, I'd probably avoid that.


Rod Pemberton

-- 
It's time to put an end to gun violence!
Use a hammer ...

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: How to bind HLLs to OS calls "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-18 02:10 -0400
  Re: How to bind HLLs to OS calls "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 06:19 -0400
    Re: How to bind HLLs to OS calls "James Harris" <james.harris.1@gmail.com> - 2015-06-22 21:22 +0100
      Re: How to bind HLLs to OS calls "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-23 19:24 -0400
        Re: How to bind HLLs to OS calls "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 22:15 -0400
    Re: How to bind HLLs to OS calls "James Harris" <james.harris.1@gmail.com> - 2015-06-24 07:55 +0100
      Re: How to bind HLLs to OS calls "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 21:00 -0400

csiph-web