Xref: utzoo comp.lang.c++:6503 comp.lang.c:25964 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!apollo!nelson_p From: nelson_p@apollo.HP.COM (Peter Nelson) Newsgroups: comp.lang.c++,comp.lang.c Subject: Re: Zortech "limitation" Message-ID: <48aa63d6.20b6d@apollo.HP.COM> Date: 15 Feb 90 22:04:00 GMT Sender: root@apollo.HP.COM Distribution: usa Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 58 bright@Data-IO.COM (Walter Bright) posts... >< If I wanted to do pointer arithmetic all over the place I would >< use Assembler! Zortech C/C++ is allegedly a high-level language >< but their manual describes this as a "limitation" of their product. >< I would call it a bug. > >There's no assembler in the example above. One man's bug is another's feature. >C is not a high-level language, it's a "portable assembler", thus the >limitations and capabilities of the underlying instruction set are >reflected in the source code. I occasionally get "bug" reports that the >compiler does not make the PC look like a VAX. I don't think its the job of the compiler to make one brand of com- puter look like another, whether it's a case of a PC looking like a VAX or a Mac looking like a Sun. Rather, it is to make all computers look like the same virtual machine, in this case a "C" computer. The key word in Mr. Bright's above paragraph is "portable". Languages achieve portability by allowing the programmer to write his code in a way which is not dependent on the architectual whims or affectations of a particular hardware vendor. In order to achieve this it is necessary to obscure the underlying features of the target machine's architecture. In principle I ought to be able to take a program which I wrote on my HP/Apollo DN10000 and port it to my PC or my friend's Mac or my wife's DG Aviion just by recompiling it. This is NOT achieved by making the Aviion, PC, or Mac look like a DN10000. In practice, of course, mapping C to a particular architecture may be much harder in some cases than others. 80x86's certainly offers some challenges to the compiler writer and the programmer may sacrifice some performance to have the architecture hidden from him, but that should be his choice. In today's heterogeneous environments, portability is becoming increasingly important and I may prefer to take a performance hit if it means not having to rewrite my code when I go from an Apollo to a PC. ---Peter PS- A philosophical point: The average computer has become vastly more powerful in recent years. An XT might be a 0.5 MIPS machine, but 386's are running 5-7 MIPS and '486's are claiming 10-15 MIPS. Motorola is claiming 20 MIPS for their 25 MHz 68040 and say they will have a 50MHz part out in a year. In such an environment productivity, ease of maintenance, readability of code and portability of code may outweigh the small loss of efficieny suffered by having the compiler generate some DS-register manipulations behind the scenes, however much a hack this might seem to the compiler-writer. Memory and CPU cycles are a LOT cheaper than they used to be and our priorities should reflect this.