Re: Why is GForth-ITC fast?

In article <481b107e$0$5017$426a74cc@xxxxxxxxxxxx>,
Thomas Pornin <pornin@xxxxxxxxx> wrote:
According to Robert Spykerman <robert.spykerman@xxxxxxxxx>:
<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 circumventing 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 documentation.


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. Porting colorforth is not pretty, but actually
it is easier than supporting 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 sported 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 Pornin

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@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

.

Relevant Pages

  • Re: Why is GForth-ITC fast?
    ... This cost is quite dwarfed by the actual jump to the kernel land. ... Unix syscalls have relatively few parameters and the Linux way, on ia32, ... In the Unix world, the libc API is standard, at least at the source ...
    (comp.lang.forth)
  • Re: Unix/VMS programming environment, was: Re: If OVMS is killed by HP....
    ... Like most system services are part of the kernel on VMS. ... Generally all UNIX system calls are fronted by a small ... The wrapper doesn't do much. ... calls are not in libc, ...
    (comp.os.vms)
  • (no subject)
    ... Implement it in libc? ... In Unix we already have files and directories, ... no more than doing it in the kernel. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • (no subject)
    ... Implement it in libc? ... In Unix we already have files and directories, ... no more than doing it in the kernel. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: simple read char app return wrong value?
    ... so bash can read input meant for us, but we could also read input meant for bash i suppose... ... linux kernel also wants posic compliance so it also implements the same methods. ... the posix functions in libc just immidiately call the linux syscalls. ... A C program that reads a file one character at a time with fgetcis much faster, because of this internal buffering. ...
    (alt.lang.asm)