Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.arch Subject: Re: RISC hard to program? Message-ID: Date: 25 Jul 90 16:40:19 GMT References: <40088@mips.mips.COM> <2162@opus.cs.mcgill.ca> <1139@carol.fwi.uva.nl> <9895@pt.cs.cmu.edu> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 95 In-reply-to: lindsay@MATHOM.GANDALF.CS.CMU.EDU's message of 13 Jul 90 16:47:20 GMT In article <9895@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: | In article <1139@carol.fwi.uva.nl> beemster@fwi.uva.nl | (Marcel Beemster) writes: | >In general my feelings towards | >software development are: "If it runs on s SPARC, it runs everywhere", | | It's good for portability to develop code on the _least_ forgiving | machine that you can find. Back when I worked at Data General, some of us (and a lot of customers) thought the DG MV/Eclipse computers were the least forgiving. Among it's features: 1) Four different representations for pointers (2 different bit, 1 byte, and 1 word/double word pointers). The bit pointers were rarely used in high level languages. One format used two double words, one for the word, and the other as a positive offset from that word. The other format had the word address shifted left 4 bits, and the bit offset inserted. The word pointer format used the top bit for indirection if the instruction itself used indirection, and the next 3 bits were the segment/ring bits, with 0 being the OS, and 7 being user programs. The byte pointer format shifted everything left one bit, dropping the indirection bit. This meant that for user programs the use of a byte pointer where a word pointer was expected or vica versa would cause a segmentation violation. Because multiple indirections where not used in the high level languages, it meant for user programs, you could check at runtime whether a pointer was of the appropriate sex, by looking at the top bit. This lead to several C compiler options to insert such checks in user code, and to enable the checks in the library. Typically though if a program had been linted, it would be passing type correct pointers (except to qsort though) and all would be fine. It was really amazing to find how many sloppy programs there out there. Because 'all struct pointers smell the same' rules, to allow pointing to an unknown structure, all structure and unions were required to be aligned on a 16-bit word boundary. 2) Dereferencing a null pointer always caused a segmentation violation (inward address trap in MV-speak), since ring 0 was the operating system, and protected from outer rings except for calls to a protected gate list. There was no way with linker switches to get it to change behavior. 3) Characters were unsigned by default, since there was no sign extending load byte sequence. I did put in a compiler option for VAX weanies who couldn't read the warning in K&R that plain chars might be unsigned. 4) Shifting signed ints right was logical rather than arithmetic (again K&R allows this) because the arithmetic shift was slower than logical (which in itself was no speed demon). 5) The MV hardware stack grew upwards from low memory, rather than downwards as it is in nearly every other machine in existance. It was also surprizing the number of people who still do not use varargs/stdargs (I just got a request in today to add a GCC option to add a warning for this case, since we are uncovering it in porting commands to OSF/1). Another side effect of the stack growing the 'wrong' way, is that it causes havoc for sbrk, since it wants to grow in the same direction. 6) The compiler and linker reordered variables based on the size and alignment of the variables. Thus programs that expect successive extern (or auto) declarations to be contigous were surprized. 7) The floating point format used is the IBM 360 format rather than the newer IEEE format. This meant you got more exponent range for floats, and less for doubles as compared to IEEE. Also because the base is in hex, and not binary, it leads to a loss of average precision of 2-3 bits. The one kludge it did allow was the single precision format was exactly the same as the double precision format, except for the extra bits. 8) The MV is big endian which causes the usual problems when importing little endian VAX code (ie, taking the address of an int, and treating the pointer a pointer to a character). We did have some companies who ported their software to our machines thank us for finding the bugs in their code. Of course we had the others who said that their code ran on two different flavors of VAX, and therefore was portable. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Do apple growers tell their kids money doesn't grow on bushes?