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

Groups > alt.os.development > #8201

Re: How to bind HLLs to OS calls

Show all headers | View raw

On Wed, 17 Jun 2015 11:05:30 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> OK. Potentially big issue. Anyone up for it...?
>
> I'll start slow! ;-)
>
> I am not sure this is right so confirmation or correction would be  
> welcome but I recently discovered that C calls to OS functions don't  
> work as I expected. If a C program calls such as fopen as follows
>
>   FILE *f = fopen(....);
>
> I expected the fopen function code (which I'll refer to as the immediate  
> callee) to be in the C library. I still think that's right. But what  
> about OS functions such as plain open? For example, if C code has
>
>   int f = open(....);
>
> Where is the immediate callee code for that open function?

It's not part of the C compiler proper, so it's in a library somewhere.

There are usually only a handful of functions which are part of the
C library that are used within a C compiler  *without*  including the
C library.  They usually call these internal versions of the function.

> It is not a C function but an OS one. (I don't mean the OS code which  
> finally gets called but the immediate target of the "CALL open"  
> instruction.) I now think it is probably *also* in CLIB. Am I right?  
> That seems weird.

Are the include files for open() with or near the include files for  
fopen()?
I would expect them to be.  The actual C code to implement open() may
be located elsewhere from the code to implement fopen().

> 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.

> Should CLIB contain functions that are specific to a given OS?

I believe GCC's CLIB does so.

> Or should OS functions be defined in something which is OS-specific
> rather than language-specific?

As far as I'm concerned, the compiler just needs to find them.
The headers should be all in one place.

> 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.

> 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 ...

> or where should the new OS's function immediate callee's reside?
...

> What if we want to call an OS from assembly language code?

OMG!  Heaven forbid!  You shouldn't do that just because that would
... excite wolfgang!  I'm just joking.  :-)

> What if we want to call an OS from assembly language code?

You make the OS interface work for assembly, e.g., stack and interrupt  
call.
Then, you wrap C, and possibly some assembly, around the OS assembly call.

Didn't you do this already with the code I was calling a "wrapper"
which you said isn't a "wrapper" ...

> Should we have yet another set of functions or, perhaps, invoke  
> subroutines
> in CLIB?

?

> (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?

> and force apps to know which OS calls needed kernel involvement.

I'm not sure what you mean by this.

> 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.

IIRC, this is were some of those advanced C preprocessor macro's come
in to play.  I.e., they have a set of files which construct the code to
call the OS for every interrupt number from the macro's and code snippets.

> Would it be desirable and would it even be possible to have a single  
> library of functions that can be called from any language, perhaps with  
> different calling conventions?

So, functions overloaded with multi-language support? ...

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.

> By the way, I know that such OS-call subroutines (the immediate callees)  
> will mostly be small shims which vector into the kernel or they might be  
> a single routine which, when called, patches in the real routine and  
> thus provides dynamic linking. But even then they will be OS-specific  
> functions in a language-specific library. Is there a better way to go?

... a better way to go, e.g., like:

comp.lang.misc
comp.arch


The code must all interconnect or be linked together either statically
or dynamically at some point, yes?  I guess I'm saying that you can
only abstract things so far ...  Of course, someone may know a solution.


Rod Pemberton

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

Back to alt.os.development | Previous | Next — 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