In article <481b107e$0$5017$426a74cc@[EMAIL PROTECTED]
>,
Thomas ****in <****in@[EMAIL PROTECTED]
> wrote:
>According to Robert Spykerman <robert.spykerman@[EMAIL PROTECTED]
>:
<SNIP>
>
>> By the way, I've been warned by at least one person in the know at
>> Apple not to use int 0x80 syscalls on OS X, which apparently have been
>> left in for 'legacy code'. Nevertheless I got some pointers to where
>> in the source to look.
>>
>> Does this sort of taboo exist on other *nixes as well? (I ask because
>> I'm still very much a nix nub/scrub)
>
>In the Unix world, the libc API is standard, at least at the source
>level. If your code performs a call to the read() function, then ten
>years later it still compiles and still works. The kernel API, however,
>is not necessarily as stable as that. Details on system calls may change
>between system versions. The Linux kernel has a rather good record at
>backward binary compatibility, but this does not prevent some system
>calls from being deprecated over time, and new ones to be added.
>Application code which uses the libc API automatically adapts to the new
>kernel API, since only the libc is modified and the application code
>talks to the kernel only through the libc (with dynamic linking, this
>adaptation process operates without needing recompilation).
>
>Besides, distinct Unix systems have quite different sets of system
>calls, whereas they tend to stick to similar libc API (because of the
>POSIX / Single Unix standard).
>
>This is why cir***venting the libc and performing direct system calls is
>generally considered as a bad idea in the Unix world. In quite the same
>way than in the Windows world, you are supposed to use the Win32 API and
>not call the NT kernel which lies beneath. This does not prevent you
>from performing direct system calls, but it somewhat explains the lack
>of do***entation.
>
>
>Of course, using the libc has a cost, namely the very unforthish dynamic
>linking with a mastodonth libc. But all those systems have lived with
that
>concept for quite some time now, and it is usually considered that they
>are quite happy with it.
I'm pretty well aware of all this. Being in Rome, do as the Romans do.
The system implementation language of Unix is c.
But with c comes the c compiler, the c libraries etc. If you have to
call the c-compiler anyway, there is not much charm left in Forth.
The small incompatibilities between kernels is in practice a less
impediment than changes in the c stuff. See below.
It is a little like the decisions Chuck Moore takes, bypassing the
BIOS for screen I/O. ****ting colorforth is not pretty, but actually
it is easier than sup****ting a new graphics card with X-systems.
(This claim cannot be easily checked, because the battle for the
information is fought by the Penguinistas, Chuck happily uses
information from Linux drivers.)
It took me less than 14 days to get ciforth up and running on
two 64 bit systems each, Dec Alpha and AMD. Lately on the AMD64
I tried to statically link a c-program that did nothing more than a
write syscall with "hello world" , no printf,
in order to find out about syscalls in a 64 bit system.
Guess what? The assembler output of the c-compiler ran a whopping
0 kbyte. 1] The linker output s****ted about the same.
This is two orders of magnitude above my Forth system, interpreter,
scripter and compiler.
It may be frowned upon, but adapting lina to new versions of
OS's is probably less effort than gforth keeping up with new
version of gcc.
> --Thomas ****in
Groetjes Albert.
1] At the moment of writing it struck me as totally unbelievable.
So I logged in to my AMD 64 bit system. Indeed 568 Kbyte and
change.
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@[EMAIL PROTECTED]
&=n http://home.hccnet.nl/a.w.m.van.der.horst
|
