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

Groups > alt.os.development > #8247

Re: How to bind HLLs to OS calls

Show key headers only | View raw

On Wed, 24 Jun 2015 02:55:49 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> I think that rather than a library for each language it would be more  
> accurate to say that there would need to be a library (or at least a set  
> of entry points) for each calling convention. That is still quite a lot  
> but the idea is that the OS developer would provide such 'libraries' to  
> go with each new release of the OS.

Sure.

If you don't want a separate library for each, you could do a single
"library" with multiple supported calling conventions.  Wasn't that
what you indicated you wanted to do somewhere else?  I.e., overloaded
multi-language functions or somesuch.

> 2. Using the naming of components
>
>   app --> interface code --> kernel
>
> rather than link the interface code (i.e. the OS code that the app calls  
> directly) in with the app I would rather find a way of providing that  
> code at load time.

Ok.

> To explain why:
>
> If an app goes through the traditional process of being compiled and  
> linked to form a load module then the interface code (supplied by the OS  
> developer) would have to be available when linking happens and would end  
> up being part of the load module. That's fine in a sense but it is  
> inflexible for at least two reasons.

AIUI, the "way of providing that code at load time," is called a DLL
(dynamic-linked library) or shared library.  Yes?

> i) If it turns out there is a bug in the interface code then that bug  
> would end up being built in to the load module.

Are the load module and interface code separate, or merged but separatable?

If so, then the bug is only built in to the load module,
if the load module uses the code with the bug.

> ii) Most interface code functions would include an instruction to enter  
> into the kernel. There are multiple ways of getting to kernel mode and  
> some ways are faster than others. The way that is best will depend on  
> the CPU the OS is running on. For example, on a 486 the best way to  
> enter the kernel may be via a software interrupt or a far call whereas  
> on a Core 2 the best way may be via SYSENTER or SYSCALL. Application  
> programmers shouldn't have to concern themselves with which one to use.

FYI, too much user choice.

> IMO the OS should choose that for them.

Yeah, aren't you the one designing the OS?  So, shouldn't you be the
one deciding which one of them to use? ...

> For both those reasons it would be better for the interface code to be  
> made available by the running OS, rather than built into apps statically.

Ok.  This seems to be another answer to my question elsewhere in the thread
about the man-in-the-middle attack, i.e., "interface code" here.

> The upshot of the above, I think, is that app calls to the OS should be  
> resolved when the app is loaded. That suggests that there needs to be  
> some form of dynamic linking.

Yes.  Why engage in code bloat?  The app is only likely to execute
correctly on one OS anyway ...

> The specific interface code used should be made available and linked  
> when the app is loaded (or even lazy linked when it is running). Such  
> code can avoid the above two problems: it can have had any known bugs  
> corrected and can use the best method of getting to kernel mode, all  
> without the app having to be recompiled.

...

> Coming back to the point you made about interface code being available  
> at compile time, for the above reasons I would rather make it available  
> at load time.

Hm?  I'm replying to this post before the other.  At this point, I'm not
quite sure which comment I made on compile time versus load time.  I don't
recall making such a distinction.

> Although the compiler *would* need to know the interface to OS calls  
> (such as would be supplied in a C header) it would *not* need to have  
> the real interface code available. (However, the linker might need some  
> dummy code or stub code so that the link process could happen. That code  
> would get replaced at load time or run time.)

Ok.

> If this sounds like I am making life hard for myself that is probably  
> true. But it just seems the right thing to do for the reasons mentioned  
> above.

No pain.  No pain.  And, perhaps, no gain.  Sometimes things work out.
Sometimes they don't.  "Almond Joy's got nuts, Mounds don't ..."
It's not a matter of easy or hard.  Both can succeed.  Both can fail.

> I am currently playing with ideas on *how* to dynamically link the  
> interface code with the app but don't have a good answer yet.

At the rudimentary level, indirect pointers, just like the indirect
branch in your compiled sample.  I.e., the instruction specifies
the location of a memory address.  That address is filled in later.

>>>> 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?
>
> Wouldn't having a separate entry point or separate function for each  
> calling convention be enough?

Ok.  So, you're thinking about one function per calling convention,
which can call many OS or kernel functions.  Then, you only have a
few generic calling functions total.  This is like the DPMI or interrupt
calling method used in DOS, but you've got more of them.  And, as
long as each language correctly complies with the designated calling
convention for the language, then multiple languages could use the same
calling convention.  The methods for calling the function are handled
by the respective compiler.

> One problem is getting the calls from C and Pascal etc to the  
> appropriate entry points. If the called OS routine was named M then apps  
> should be able to just call M by name and leave the computer to convert  
> M into M_cdecl or M_stdcall or whatever, according to the convention the  
> compiler uses. I haven't yet worked out a way to do this.

a) Different namespaces?  E.g., compiler prepends some name
for C and a different name for Pascal.

b) Different access?  I.e., C compiler can only find M_cdecl
version of M, Pascal can only find M_stdcall, etc.

>> 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.
>
> That is flexible but unfortunately would probably be unnecessarily slow  
> for most OS calls.

True.

>>>> 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.
>
> By API I am not sure if you are thinking about how to get to kernel mode  
> (int 0x80 or far call etc), or are thinking of the defined set of OS  
> syscalls.

Frequently, those are equivalent.

> In either case I agree that the calls to interface code (i.e. before any  
> [transition] to kernel mode) could be wrapped/shimmed. The interface  
> code fragments - which are to be supplied by the OS - could invoke the  
> kernel so the app wouldn't have to worry about how that was done.)

It's possible different languages can use the same calling convention.
So, while I expressed that in terms of the language, i.e., where each
would use it's own unique calling convention, you're correct in that
it's really the calling convention that should be wrapped/shimmed, and
not the language.

>>> 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.
>
> In the sequence
>
>   app --> interface code --> kernel
>
> I was saying that the library of interface code would be provided by the  
> OS developer and asking if it was feasible for different languages to  
> use the functions within it. Same issue as above, and one I don't have  
> the answer to yet.

Is "the OS developer" you? ...  You keep referring to the OS developer
in the abstract or as an independent third person.

As long as each language can correctly call the "interface code" API,
then sure it's feasible.  I.e., I'm assuming a single entry-point here,
not multiple to support different calling conventions or languages, e.g.,
Int 0x80 for Linux, Int 0x21 for DOS.  Each of those is a single
entry-point with an interface method.  In those cases, they're intended
for assembly, and other languages like C need support code.

> The tool used to build such files may be easiest to write in Python  
> which is great for text processing.

EX via VI is good for line-oriented text processing, and I use it.
C is excellent for text processing, and I still use it.
AWK is good for text processing, but I don't use it much.
BASIC is excellent for text processing, but I don't use it anymore.
SNOBOL is good for text processing, but I only have a dusty
   book on it packed away somewhere ...

I.e., just because something is good for something doesn't
mean it will be used for it or even should be.

For a low use situation, your skill level with a language
is probably the most determinant factor for you.  For others,
I'd recommend going the C route.  C is going to be available
to those attempting to bootstrap an OS.  I'm not sure whether
someone in that situation will have access to Python.  I do
now because I now have Linux.


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