According to Robert Spykerman <robert.spykerman@[EMAIL PROTECTED]
>:
> I don't really know how expensive PUSH immediates or PUSH addresses
> actually are I admit, offhand but I expect given the convenience they
> apparently offer, they must be expensive.
This cost is quite dwarfed by the actual jump to the kernel land. On
i386, a push is only two clock cycles, whereas a software interrupt
which changes privilege levels (i.e. exactly what happens for a syscall)
costs 99 clock cycles, and 59 cycles for the back trip... on more recent
x86 processors, timings are different but you may expect the same kind
of ratio. The choice between ways to do syscalls is more a convenience
and historic matter. The Linux kernel performs system calls that way
because when Linus Torvalds first coded it, it was easier to do on his
side (the kernel), and the convention stuck because there is such a
thing as backward compatibility.
As a side note, Linux kernel developers regularly boast about how their
way to perform syscalls is faster than what is done in BSD. But one may
also find BSD kernel developers who claim that the BSD way is faster,
hence there is probably little difference between the two.
Unix syscalls have relatively few parameters and the Linux way, on ia32,
allows for six 32-bit parameters, which is enough. Note that there is a
"catch-all" system call, namely ioctl(), for everything which does not
fit in that model: when performing an ioctl() call, the application code
stores parameters in a userland structure, which address is passed to
the kernel as a system call parameter.
> As you probably realize Thomas, my interest in syscalls is all in the
> setting of trying to ****t Albert's ciforth/lina.
I am personaly not fully convinced by the idea of performing system
calls directly. A Linux _system_ (as opposed to a Linux _kernel_) offers
services through the libc API. Some of this services are just trivial
wrapper around system calls (e.g. when calling write()) whereas some
others are quite complex.
For instance, consider host name resolution. From a C programmer's point
of view, this is a simple call to the gethostbyname() function.
Internally, that function enters a convoluted process which entails
reading some files (/etc/nsswitch.conf, /etc/hosts,
/etc/resolv.conf...), sending network requests, and possibly loading
shared library which may extend the process in arbitrary ways
(including, but not limited to, contacting a LDAP server through a SSL
connection). All of this can theoretically be implemented in Forth, but
this is a considerable amount of work, and there is the major problem of
configuration: canonical host names, DNS server addresses, NSS
parameters... are informations which were obtained through a
configuration process, part of which possibly automatically (DHCP),
which means that you cannot count on the user to reenter them manually
in a different format since he doesn't know them himself. And things may
differ between distinct Linux distributions, or even successive versions
of the same distribution.
If you decide to talk directly to the kernel, then you basically shun
those services which are not directly implemented by the kernel.
Depending on what you want to do, this may or may not be a problem. But
as a generic approach, I find it relatively unconvincing. A Forth way of
thinking would be to state that those services are not needed anyway,
and I have a hard time swallowing that when it comes to DNS name
resolution.
> 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.
--Thomas ****in
|
