rb@ccird1.UUCP (Rex Ballard) (05/06/86)
In article <2110@gondor.UUCP> steve@gondor.UUCP (Stephen J. Williams) writes: >In article <2107@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >> >>This brings up an interesting topic that I was just thinking about last >>night. Viz., how might one provide better architectural support for C? > >Why would one want to? Wasn't C sort of written for PDP-11s? > Starting backwards. Yes, C was written for PDP-11s, as sort of a GENERIC ASSEMBLER. When reduced to it's simplest constructs, that is exactly what C is. However, by allowing constructs to be combined in sometimes perverse ways, it looks like any other Algol type language. Of course, to broaden the appeal of C/Unix, additional "features" and variations were added to include machines with oddities like 9 bit chars, and 24 bit ints. Why would someone want to provide architectural support? Because it is a "generic" language. FORTH and Pascal, to a lesser extent are also "generic" in that "inner interpreters" can be used to run intermediate binaries, but C has traditionally been used to go directly to native form (although there may be intermediate stages). If you only want to support ONE processor, you could build a super LISP, Prolog, FORTH, Pascal, or Modula 2 engine. But if you want to support a LINE of machines, it makes sense to support a high level language that can support several machines. It also makes sense to choose a language where OEMs, VARs, and End Users won't have to re-invent the wheel to get simple functionality as they migrate up the line. How could one provide better support for C? CCI's 6/32 does just this, so do a few other machines. There are lots of things you can do, like building fast "frame" call archetectures, pointer arithmetic, and stacks, pushing only modified registers and restoring them, using FIFO's or separate CACHES for pointer registers and stacks. Even using separate stacks for parameters and return/register values. Most of these would improve any general purpose machine even if some other language replaced it. Could C, or the typical practices used in C be improved? Absolutely! If you have a machine where the overhead of a C subroutine is sufficiently low, you could make more effective use of complete, structured designs, reducing the number of conditionals in a module to 2 or three, rather than stringing several "units" together into one large subroutine. This creates a need for better naming conventions, better organization of subroutines (such as those used in SmallTalk), even data bases to manage code, documentation, and source. The "code,link,test,debug" cycle could be sped up with an interactive, incremental editor/compiler/debugger. Such things are available, especially on PC's, but still slightly "under developed" for general use. Perhaps either SmallTalk could be enhanced to give more direct control over the system, or C could be enhanced to include some of the features of SmallTalk. (All of this is happening, but the direction needs to be pointed out). Currently, C lacks a productive "environment" for the programmer, that can be run on all C capable machines. I know of none that will allow me to unit test a single module in an 8meg project without some sort of "cut and paste". As to the superiority of UNIX over other operating systems, there are few who think UNIX couldn't be improved. The big question is how? I'm sure we will be seeing a rapid evolution of UNIX and UNIX-like operating systems as multi-tasking micros and multi-processing minis become mandatory state of the art, rather than expensive luxuries. Hopefully, a few of them won't be "designed by commitee", Unix started out right (a small group trying good ideas), but evolved into a slow memory pig. It would be nice to see Unix modularized, so that the whole kernal doesn't have to be re-linked just to add two lines of code to a driver. It would be nice if the queuing and signalling as well as the context switches could be cleaned up. It would be nice to have generic "transaction" mechanisms similar to pipes, so that work could be shared between processes. It would be nice to have locks, so that processes that wish to recieve input from several processors could do so in real time. It would be nice if "system libraries" were "sharable" so that less copies of "printf" were taking up swap space. It would be nice if all but the bare bones drivers could be "tasks" rather than part of the kernal, so that only that which was needed at the moment would sit in core. The list goes on, but most has been hashed to death already. If we wish to come up with better products, we have to look at both the best and the worst in the best and worst of systems and languages, operating systems, and archetictures. I haven't seen a system yet that is so good that it can't be improved, or a system so bad that there wasn't at least one or two good features in it. Some of the most valuable treasures can be found in some of the most obsure places. Things like the 1802/CHIP-8, and other "long forgotten" systems, some of which are still used, contain a veritable diamond mine of ideas, many of which fell into obscurity simply because the creators didn't have the "clout" of their competitors.
blarson@usc-oberon.UUCP (Bob Larson) (05/07/86)
In article <399@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >As to the superiority of UNIX over other operating systems, there are >few who think UNIX couldn't be improved. The big question is how? >I'm sure we will be seeing a rapid evolution of UNIX and UNIX-like >operating systems as multi-tasking micros and multi-processing minis >become mandatory state of the art, rather than expensive luxuries. >Hopefully, a few of them won't be "designed by commitee", Unix >started out right (a small group trying good ideas), but evolved >into a slow memory pig. Which leads to the UNIX definition in the os9/68k users manual: "An operating system similar to os-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers." >It would be nice to see Unix modularized, so that the whole kernal >doesn't have to be re-linked just to add two lines of code to a >driver. As in os9. >It would be nice if the queuing and signalling as well as >the context switches could be cleaned up. >It would be nice to have >generic "transaction" mechanisms similar to pipes, so that work could >be shared between processes. Are os9/68k's named pipes what you are looking for? >It would be nice to have locks, so that >processes that wish to recieve input from several processors could do >so in real time. >It would be nice if "system libraries" were "sharable" >so that less copies of "printf" were taking up swap space. As in os9/68k, but I prefer how it is done in primos 19.4 and beond. (Primos uses some hardware support: fault bit on pointers.) >It would >be nice if all but the bare bones drivers could be "tasks" rather than >part of the kernal, so that only that which was needed at the moment >would sit in core. I think os9/68k has what you are asking for here. >The list goes on, but most has been hashed to death already. And much of it is unique to unix. Not all "Unix-like" operating systems are bug-for-bug compatable. >If we wish to come up with better products, we have to look at both the >best and the worst in the best and worst of systems and languages, >operating systems, and archetictures. I haven't seen a system yet >that is so good that it can't be improved, or a system so bad that >there wasn't at least one or two good features in it. I agree. -- Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Uucp: ihnp4!sdcrdcf!usc-oberon!blarson