rick (04/05/83)
Has anyone thought about the possibility (pros & cons) of making "printf(3)" a SYSTEM CALL? Think about it for a second (especially you PDP 11/70 and lower primates). Think about the resources you would save, viz.: Disk space (~4-5Kbytes) Primary memory (non-shared data and text <= ~4-5Kbytes) Compile time (AH! Not to have to load "printf.o" and "doprnt.o") Well, now, Wilbur ... Think what it would cost: Kernel memory space (~4-5Kbytes again) More time spent user/kernel switching (for sure - groady to the max) Buffering problems ??? What can I say? It was just a thought. Flames to: ariel!/dev/null Constructive thoughts and criticisms to: Richard L. Maus, Jr. (Rick) ABI(@BTL) HO 1K313 201-834-4532 ...!ho???!ariel!rick
tim (04/06/83)
Note that the ~4-5Kbytes saved on disk space by puting printf in system space is *per program using printf* (most C programs), but the same space lost in system space on the VAX is a one-time thing. I don't understand why UNIX on the VAX doesn't make more things system calls. Look at how much VMS has sitting down there. Tim Maroney
sch (04/07/83)
Making printf a system call is the worst idea I have heard yet. The Unix system was designed along the principle of having the kernel, provide only those services which are necessary. Why not make the shell a system call, and how about all the other library routines! Actually, there is something that can be done about this. Why not make the library routines available as common shareable text pages. This would reduce the disk/memory load of the routines without inviting the do everything in the kernal method so popular with DEC operating systems. Not afraid to Defend Unix, Stephen Hemminger
leichter (04/07/83)
Stephen Hemminger proposes to make library routines "available as common shareable text pages ... [not] inviting the do everything in the kernal [sic] method so popular with DEC operating systems." Hate to disabuse you of your prejudices, but most DEC operating systems do exactly this. In RSTS, the shared text goes under the names of RunTime System or Shared Library; on RSX it is one of several kinds of shared library; and in VMS, where this was built in from the start, essentially all the library routines get used this way through "global sections". In this area, at least, it's Unix that ought to get on the ball and catch up with what everyone else has known is "the right approach" for years... -- Jerry decvax!yale-comix!leichter leichter@yale PS If you are thinking about designing such a system, one nice thing to design in is the use of a transfer vector to get to the library routines. If you do this, you can actually run programs that were linked against an old library using a new library with no changes at all. VMS does this - they've actually gotten more sophisticated about it over the years; it used to be that you would have to re-link when the library grew enough to force some vectors to move. This is no longer a problem, because the program start- up code does some last-minute "relocation" of vector addresses. The older PDP-11 OS's didn't, in general, have this, requiring you to re-link with each new version of a library. P/OS, on the other hand, is going to such a scheme... -- J
guy (04/09/83)
printf should probably not be a system call, because things should
only be system calls if: 1) it requires kernel privileges, 2) you
get a significant performance improvement, or 3) the code *really*
wants access to kernel data structures and becomes massively kludgy
if it has to run in user mode. The better way to handle "printf" is
to implement shared libraries in UNIX, but shared libraries are a pain
in the neck (the code would either have to have its references to external
data resolved by the "exec" system call or would have to reference all
such data through an indirect pointer). The 16032 has a "module table"
and a "module pointer" register like the stack and frame pointers, which
points to a given object module's static/global data, which solves 90%
of the problem (the other 10% is references by a routine in a library
to a user-supplied routine or global area).
A *lot* of operating systems seem to have the idea that anything that
could be considered a service routine for user code belongs as a system
call; things like printf, ctime, etc. The "real" solution, of course, is
to have a domain-oriented protection system (or *no* protection system,
like Xerox's Pilot OS), and make all system calls library routines!
Of course, this works only with the right hardware...
Guy Harris
RLG Corporation
{seismo,mcnc,we13}!rlgvax!guynrh (04/09/83)
#R:unc:-491000:inmet:10300002:000:449 inmet!nrh Apr 7 14:08:00 1983 Printf as a system call???? If people wonder why unix is sliding towards TSO, TENEX or the others, look no further! A lot of the point of unix was that it gave you most of the power at a fraction of the complexity of other systems. Sure, we can make unix be more like older, more baroque systems. Does that mean we should? Even if there's a performance gain? Think how much faster things would be if they were written in assembler! WOW!
ka (04/12/83)
When Stehpen Hemminger talked about DEC putting everything into the kernel he was probably talking about TOP-10 and TOPS-20. The issue here seems to be one of performance rather than functionality anyway, and the compar- isons of UNIX vs. VMS performance that I have seen didn't consider the issue important enough to discuss. With shared libraries, you have tran- fer vectors which make calling the routines slower, and the operating system has to set up page table entries for routines which your program doesn't ever call. These problems may be enough to offset the performance advantages of shared libraries. Kenneth Almquist
jmc@root44.UUCP (05/19/83)
The problem with printf %X and %x was exacerbated in the UNIX System III version of ADB, which (as distributed) had a rather half-baked conversion to %lo %lx in the format to print O and X output. Since it had its own version of printf, it did strange things if you wanted to use O and X. Whilst fixing that I noticed that the op-code print routines still handled version 6 system calls (16 bit offset to seek etc). All very strange. I suppose the support people had half-forgotten about adb. John Collins. !vax135!ukc!root44!jmc