Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: 16 & 32 bit vs 32 bit only instructions for RISC. Message-ID: <1697@winchester.mips.COM> Date: 27 Feb 88 19:32:24 GMT References: <9651@steinmetz.steinmetz.UUCP> <9678@steinmetz.steinmetz.UUCP> <2574@im4u.UUCP> <2116@saturn.ucsc.edu> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 36 In article <2116@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes: >In article <2574@im4u.UUCP> rajiv@im4u.UUCP (Rajiv N. Patel) writes: >I'm glad somebody brought this up, and while we're also at it let's debate >the value of including 16 bit data types in RISC machines. A variety >of data sizes slows a machine down almost as much as a variety of >instruction sizes. I was rather surprised to see that Sun included >16-bit data in SPARC in this day and age of cheap memory. 8-bit data >has the obvious utility for character strings; but do we really need >16-bit integers anymore? I encourage all potentially competitive RISC machines to avoid 16-bit integer support. :-) More seriously: -UNIX user-level programs don't use 16-bit quantities very much. -A few applications use halfwords a lot: Berkeley timberwolf, for example, has 11% of its instrucitons (on MIPS R2000) as load/store halfword. -The UNIX kernel uses halfwords frequently, because it has large arrays of structs whosedatra must be tightly packed. You might argue that some of these could be expanded (and they can), but others are painful. -If you want to do data communications, and write device drivers, both cases where data structuring is beyond your control, you will be very sorry if you don't have halfwords: both of these applications use them frequently. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086