(clip)
> the following model:
>
> we have "basic system calls":
>
> file system calls: - open, create, read, write, writev, close, (many more)
> process state system calls: - getpid, getpgrp, (and many more)
> memory system calls: - mmap, mmunmap, mprotect, mlock, munlock, mremap
> syncronisation calls: - sys_ipc, select, wait4, (and many more)
> (and many more, 163 currently)
>
> There are pairings which are often executed after each other:
>
> open + read
> fork + wait4
> select + read
> sys_ipc + read
> read + send + listen
> recv + write
>
> This was the point where i thought that maybe it makes sense to make these
> pairings "effective". No real information flow happens between kernel and
> user space between these two calls.
>
> One implementation could be a "system call list" :
>
> sys_execute_stack( list );
(clip)
(off-subject)
This is like the VLIW CPU writ large.
VLIW is the 'Very Large Instruction Word' whereby (unless it fails
miserably) the newest Intel CPU's are supposed to use a 128-bit or so
instruction.
VLIW should prove almost impossible to do exact literal assembly for by
hand--the instructions have a number of small components that are all packed
together into one instruction word--each executing in parallel. Instead of
trying to pipe-line any further, the idea is to create code that is
non-linear and runs in parallel implicitly ... in other words, rather than
fight the fact that lots of stuff is happening at once, accept it and design
the assembler to write code that does '7 things' in every instruction... I
think the 'assembler' will take the 'sub-instructions' and try to optimally
pack them together and do alot more of the thinking, than say a 486
assembler which I believe just stuffs bytes down a pipe :)
Supposedly they were looking at ~ 1 bips. (well we'll see...)
__kmb203@psu.edu_________________________Debian__1.1___Linux__1.99.3___
"You are in a maze of twisty little passages, all alike."