4 ms·

Unix can run other languages. But for answering your question deeper, we have to find an understanding what boundary we're talking about. The kernel syscall in

Unix can run other languages. But for answering your question deeper, we have to find an understanding what boundary we're talking about. The kernel syscall interface? Things like Linux's vdso? POSIX library (libc)? The more we go on in that sequence the more C we get into the interfaces and many of those APIs are essential for writing well-behaving non-trivial programs. The closer we stay to the kernel's syscall interface the less C you get, but still the syscall interface and C are related. Strings are often NULL-terminated. Arguemtns are passed (via registers) from left to right, not like in Pascal convention right to left. (First arg always in EBX, second in EXC etc.) A different language will need some interoperability with C conventions for being a good citizen on Unix. A Pascal operating system for instance would use Pascal strings (historically what tis now called ShortString) where length is encoded in the first byte.

Joker_vD 5y ago
> A Pascal operating system for instance would use Pascal strings Only if the designers would make that decision, and they are not in any way obliged to make such decision! Nobody stops them from using e.g. a moral equivalent of "RECORD size: CARDINAL; str_ptr: ^CHAR END" for passing strings in their system calls (which would probably coincide with using "size_t size, char *str_ptr" in the C prototype at the binary level), or something else entirely. Is the idea of an OS not exposing its implementation language in its public API that foreign so I have to express it three times in this thread and every time be replied with "No, what are you talking about, of course the OS would use reuse the structures of the runtime of the language that it is written in in its public syscall API"? Gee, I wonder how the syscall calling convention would look if I wrote an OS entirely in assembly.
- johannes1234321 5y ago
  It's not what the implementation uses, but "which conventions does the call interface assume" you can use Pascal to create an operating system with a system interface that benefits Fortran. (I know too little about Fortran to describe what that would look like) With C and Unix the issue of course is that both were developed around the same time by the same people for working together.
GoblinSlayer 5y ago
Or it could be designed for interoperability like ODBC which was designed to be compatible with languages that have ISO standards: Ada, Fortran, C, COBOL, Pascal without tightly locking to either.
- johannes1234321 5y ago
  What is cause, what is effect? "All" languages (which survived) can call into C.
  - GoblinSlayer 5y ago
    C can call into Pascal too. Does it mean libraries should use pascal strings in their interface?
    - johannes1234321 5y ago
      i'm not seeing where i can configure gcc to use pascal calling conventions. looking at https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.h... And yes, with common Pascal compilers i can write specific functions in a way to provide a C calling interface (called STDCALL) so those functions can be called from C. But for reaching arbitrary Pascal functions I need my own assembly code which passes parameters in the right order and manages the stack "correctly" (in C the caller clears the stack, in Pascal the calleé)
      - Joker_vD 5y ago
        ...the calling conventions are not the properties of the language itself, or the OS, only of the langauge implementations — the Gnu Pascal Compiler uses the same calling convention as the Gnu C Complier [0], so I think GCC simply decided not to support any other Pascal implementation explicitly and left those to figure out themselves how to link with object files produced by GCC. And yes, generally different implementations of the same language tended to use the same calling conventions to be compatible/interoperable with each other in the first place, although it's not a universal rule, so that's how why x86 calling conventions were labeled with PL names; but that's slight misnomering. On x64 Linux, everyone managed to agree to use the same calling convention which is of course very convenient. The language of it's written specification is heavily C-biased, but if you squint you can see that it talks mostly about eightbytes and and compound objects and where to shove those so it more or less trivially translates to most other Algol- or C-descendant imperative languages; I believe it can even be reformulated strictly in language-neutral/assembly terms. On vanilla x86, of course, everyone invented their own calling convention, even different implementations of the same languages: IIRC, Borland C++, MSVC, Watcom, and GCC on Windows all by default produced object files that you could not simply link together without manual tinkering. And (32-bit) Windows, despite being written in C, uses a variation of "Pascal" calling convention in its system API which they called "stdcall". I believe there were some C compilers that actually used "stdcall" by default instead of "cdecl". Hell, even on x64, Cygwin GCC (on Windows) uses SysV ABI for everything except interfacing with Windows itself where it obviously has to use Windows x64 calling convention. [0] http://www.gnu-pascal.de/gpc/Importing-Libraries-from-Other-Languages.html http://www.gnu-pascal.de/gpc/Importing-Libraries-from-Other-...

Joker_vD 5y ago

> A Pascal operating system for instance would use Pascal strings Only if the designers would make that decision, and they are not in any way obliged to make such decision! Nobody stops them from using e.g. a moral equivalent of "RECORD size: CARDINAL; str_ptr: ^CHAR END" for passing strings in their system calls (which would probably coincide with using "size_t size, char *str_ptr" in the C prototype at the binary level), or something else entirely. Is the idea of an OS not exposing its implementation language in its public API that foreign so I have to express it three times in this thread and every time be replied with "No, what are you talking about, of course the OS would use reuse the structures of the runtime of the language that it is written in in its public syscall API"? Gee, I wonder how the syscall calling convention would look if I wrote an OS entirely in assembly.

johannes1234321 5y ago
It's not what the implementation uses, but "which conventions does the call interface assume" you can use Pascal to create an operating system with a system interface that benefits Fortran. (I know too little about Fortran to describe what that would look like) With C and Unix the issue of course is that both were developed around the same time by the same people for working together.

GoblinSlayer 5y ago

Or it could be designed for interoperability like ODBC which was designed to be compatible with languages that have ISO standards: Ada, Fortran, C, COBOL, Pascal without tightly locking to either.

johannes1234321 5y ago
What is cause, what is effect? "All" languages (which survived) can call into C.
- GoblinSlayer 5y ago
  C can call into Pascal too. Does it mean libraries should use pascal strings in their interface?
  - johannes1234321 5y ago
    i'm not seeing where i can configure gcc to use pascal calling conventions. looking at https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.h... And yes, with common Pascal compilers i can write specific functions in a way to provide a C calling interface (called STDCALL) so those functions can be called from C. But for reaching arbitrary Pascal functions I need my own assembly code which passes parameters in the right order and manages the stack "correctly" (in C the caller clears the stack, in Pascal the calleé)
    - Joker_vD 5y ago
      ...the calling conventions are not the properties of the language itself, or the OS, only of the langauge implementations — the Gnu Pascal Compiler uses the same calling convention as the Gnu C Complier [0], so I think GCC simply decided not to support any other Pascal implementation explicitly and left those to figure out themselves how to link with object files produced by GCC. And yes, generally different implementations of the same language tended to use the same calling conventions to be compatible/interoperable with each other in the first place, although it's not a universal rule, so that's how why x86 calling conventions were labeled with PL names; but that's slight misnomering. On x64 Linux, everyone managed to agree to use the same calling convention which is of course very convenient. The language of it's written specification is heavily C-biased, but if you squint you can see that it talks mostly about eightbytes and and compound objects and where to shove those so it more or less trivially translates to most other Algol- or C-descendant imperative languages; I believe it can even be reformulated strictly in language-neutral/assembly terms. On vanilla x86, of course, everyone invented their own calling convention, even different implementations of the same languages: IIRC, Borland C++, MSVC, Watcom, and GCC on Windows all by default produced object files that you could not simply link together without manual tinkering. And (32-bit) Windows, despite being written in C, uses a variation of "Pascal" calling convention in its system API which they called "stdcall". I believe there were some C compilers that actually used "stdcall" by default instead of "cdecl". Hell, even on x64, Cygwin GCC (on Windows) uses SysV ABI for everything except interfacing with Windows itself where it obviously has to use Windows x64 calling convention. [0] http://www.gnu-pascal.de/gpc/Importing-Libraries-from-Other-Languages.html http://www.gnu-pascal.de/gpc/Importing-Libraries-from-Other-...