Mohammad Khan wrote: > Well, C on UNIX is really assembler - just one step removed from the > bits and > bytes of the underlying CPU.
No, assembler is assembler on Unix. C is a high level language used as a system programming and implementation language on Unix just as PL/I was the implementation language of Multics and ESPOL (an extension of ALGOL) was the implementation language of Burroughs' MCP. Both of these predated C and Unix, > Its designers realized that there is not much > benefit in writing CPU specific code to copy x bytes of memory to > another > location over the generic "a = b" kind of code. Same for other basic > operation > common to most CPUs - arithmetic, compare, branch etc. Going CPU > specific > and lot of tedius work one could get a few percent CPU savings but it > wasn't > considered to be worth it. And I tend to agree. The developers working on Unix, most of whom had been working on Multics, wanted to work in a high-level language. The major languages of the time, Fortran, PL/I, and ALGOL were too large for the resources available. A large part of the primitive character of C is due to its ancestors, BCPL and B, and the original environment where B was developed - a PDP-7 with 8K words of memory. > > On the other hand OS specific facilities ( macros, SVC ) were wrapped > for > easy use in "standard library". Then again their "standard library" is > NOT z/OS > standard library, though you can try to map it. This also made their > application > and system programming domains a continuum rather than two isolated > domains. > A similar approach for MVS would have been great in my humble opinion > but it > developed on very different lines. On one side we have COBOL > programmers > who hardly know anything about the capabilities and strength of the > underlying OS. Their domain is merely the generic computing functions > ( > arithmetic, compare etc. ) and middleware API ( CICS command level, > DB2 > SQL, IMS calls etc.). Just ask any COBOLer about coding a program with > > parallel tasks. This step is a lot easier for a UNIX programmer. On > the other > hand the "real" programmers talk in bits and bytes which does create a > "guru" > aura but isn't easy for the newcomers. There is little if anything that can be done in C that can't be done in PL/I including implementing an operating system[1]. The C language itself has no support whatever for parallel tasks and is no more well suited to such an environment than COBOL. pthreads, which is a Posix standard, is an add-on library with limited support for parallel tasks. > > Just my 2 cents > Mohammad > [1] C seems to be particularly well suited to writing code susceptible to buffer overrun bugs which have often made Unix systems easy prey for attackers. Regards, Henry Willard ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
