Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!neon!kaufman From: kaufman@Neon.Stanford.EDU (Marc T. Kaufman) Newsgroups: comp.arch Subject: Re: RISC hard to program? (was: Moto's data predicts...) Message-ID: <1990Jul13.071511.22250@Neon.Stanford.EDU> Date: 13 Jul 90 07:15:11 GMT References: <40088@mips.mips.COM> <2162@opus.cs.mcgill.ca> Organization: Computer Science Department, Stanford University Lines: 35 In article <2162@opus.cs.mcgill.ca> peterd@opus.cs.mcgill.ca (Peter Deutsch) writes: >** Opinions wanted, raging debated expected. Join now! Avoid the rush! ** -Preamble: From my own exposure to user complaints about -unportable software, etc I would allege that that the SPARC -architecture appears to be inherently less forgiving of the -programmer than the 68k architecture. I keep receiving -reports of software that ran fine on machine 'x' (often -68k machines, Vaxen etc) but that either wont compile or -wont run on the Sun 4's. I have had this explained to me -(by a defender of the SPARC architecture) as being due to -the fact that the SPARC architecture is less forgiving of -poor programming (eg byte alignment problem in structures, -ignoring warning messages, etc). It was stated to me that -"well-wrtten programs work, if not it's the programmer's -fault." SPARC requires fullword alignment for 32-bit operands and DOUBLEword alignment (e.g. 8-bytes) for 64-bit operands, in memory. This is more restrictive than the 68K, which was prepared (at the 68020 and above) to accept byte alignment for all operand sizes. The 68000 only required 16-bit alignment at worst, but then it was only a 16-bit machine. I am not surprised that there is trouble trying to use a data structure on the SPARC that was created on a machine with less restrictive alignment requirements. It seems to me that, if downward compatibility is absolutely required, it is the C (or other language) compiler's fault, not the user's. After all, the SPARC is fast enough that executing extra code to piece together misaligned data operands is a small price to pay. :-) Data misalignment problems are independent of how well a program is written, especially if the program was written for another target architecture. Marc Kaufman (kaufman@Neon.stanford.edu)