cdshaw@alberta.UUCP (Chris Shaw) (08/02/88)
Code written in assembly can be fast. Conventions and self-discipline are needed to make it manageable. Assembly is by definition not portable to other architectures. It's a trade-off. Can we shut up about this topic now? -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !
case@xenon.UUCP (Bill Case) (08/13/88)
In article <1500@pembina.UUCP>, cdshaw@alberta.UUCP (Chris Shaw) writes: > Code written in assembly can be fast. > Conventions and self-discipline are needed to make it manageable. > Assembly is by definition not portable to other architectures. > > It's a trade-off. > But does it have to be? It may be a lot harder to develop in assembler, but well-documented assembler code has always been much easier for me to understand than any so called self-documenting lanquage. Since assembler code deals with atomic operations, it frees up a lot of space for comments that parallel what the programmer is doing, and usually tells WHY the programmer is doing it. It makes for a running dialog, which I don't see in programs written in a HLL. VMS is easy to read and hardly a toy. But, alas, we all know that assembly lanquage is machine dependent, and can't be portable or track the current technology. Hmm, seems like these were the same arguments against MVS, VMS, etc. The solution was an agreed upon standard called Unix. Sure, it has a Reduced Interface Set (RIS?) and a few limitations and problems, but it's now considered a fair tradeoff for a standard. But still no shrink-wrapped executables! I find it interesting that RISC allows an IEEE group to define the standard user-level instruction set for all machines, thus providing true object portability across the industry. Sun/ATT seemed to be trying to produce such a standard with the ABI/SPARC standard, except it was aimed at producing billions of bucks for Sun/ATT. Most semi-houses and a bunch of computer vendors extol Unix because it "provides portability" and "promotes a level playing field". This is because the SVID defines a standard set of interfaces for all source code to use. I wonder how everyone would feel if the IEEE RISC Instruction Standard promoted a level playing field in the hardware, providing a standard set of instructions for compilers to generate? Would proprietary instruction sets look as diabolical as the proprietary operating system? Isn't the concept the same? Do we really need instruction variations in the age of RISC? "But", you say, "what about all the software written for existing machines?" "But", I say, "what about all the software written for MVS and VMS?" The argument is basically the same. If you don't need the VMS GET_DEVICE/VOLUME_INFO interface, then do you really need the AMD version or superset of a basic RISC instruction? (Note, I am talking about user-level instructions - for now). In one sense, the problem is less severe than in switching from from a proprietary OS to Unix (non-prop?). All you need to do is recompile your HLL programs with the "universal compiler". With such a standard you could have a huge net with machines from many vendors, and ship executables about as if it was all one big system. It would be a new age where the only thing that mattered was speed, capacity, and the applications -which would become standardized. The marketing people should love it: "If you want to be modern, get rid of those old machines that don't have the IEEE standard RISC instruction set". This may be the wrong way to express it, but aren't standard Operating System interfaces and standard instruction interfaces simply levels of abstraction? Aren't the arguments for and against the same? The downside is the usual problems with standards dampering innovation. After all, we could have agreed on the VAX instruction set in 1980, which would have made the RISC innovation a much harder sell. Hmmm, might Unix create the same dangers? Nah... These are my personal opinions and not those of my employer. ...uunet!ingr!b11!case!case (UUCP) ingr!b11!case!case@uunet.uu.net (ARPANET)