steckel@alliant.UUCP (04/10/87)
The distinction between _addressing granularity_ for the program and _bus width_ to the memory is a good one to keep in mind. These two items should not be confused (especially by hardware designers). Chip designers have another problem: they don't get to design the memory system. They have to design a memory interface with which other designers can create a useful product. They should design a simple, flexible interface. My observations in the following are as a board level designer. I have not found anyone who'll pay me to play with chip design yet (:-) Re bus width, byte extraction, unaligned operands, and memory speed: 1) Byte extraction from words should be free in time; it'll cost a few gates. Basically this requires one or more cross-couplings in the memory path. 2) Bit extraction is one of the very good reasons for a barrel shifter. It will cost you a pass through the shifter. 3) Cost of byte writes is very memory implementation dependent. On many systems it will be free. Read-modify-write is only necessary if the memory system uses ECC over long words (certainly a common practice). 4) Unaligned operands are expensive. A memory subsystem which takes care of this problem looks like the 68020 interface, which does repeated fetches/stores until done. Costs cycles. I suspect that the unaligned fetch/store in the AMDAHL was special-cased all the way from ALU through memory boards. This option is not available for chip makers. Summary: I see no reason a useful chip should not support byte read/write at the hardware level. Those skilled in the art, please enlighten me why this would be different at the chip level. Bit read/write might cost more. Re: addressing granularity: As a confirmed C programmer, it is very useful to have a uniform address space down to the byte level. C is/was unable to deal with bit arrays because the PDP11 didn't have bit pointers. I would be very curious to hear how many programs/programmers would _use_ bit fields & bit arrays on a regular basis if they were easier to use. Note that in operating systems bit fields are extremely useful for resource allocation and are so used frequently. As a counterexample - the PDP10 (and DEC20) had three disjoint address spaces: byte pointer, halfword (no pointers usefully possible), and fullword. Byte pointer space was addressable on word boundaries from 1-36 bits. Needless to say, no higher-level language could cope with this. Almost all programming either was in assembler or ignored major capabilities of the machine. The bit level addressing capability was especially flawed in that it did not span word boundaries automatically. This led to some quite peculiar software being written. This leads me to formulate a rule: any data type not easily addressed is a 'second-class datatype' and will be avoided by programmers. Any agreement or disagreement? Re: software impact of alignment: This seems closer to a religious debate. Padding/packing issues certainly shouldn't be something that a low-level applications programmer has to fix. Geoff Steckel (steckel@alliant.uucp, gwes@wjh12.uucp)
mouse@mcgill-vision.UUCP (der Mouse) (04/26/87)
In article <466@alliant.UUCP>, steckel@alliant.UUCP (Geoff Steckel) writes: > C is/was unable to deal with bit arrays because the PDP11 didn't have > bit pointers. I would be very curious to hear how many > programs/programmers would _use_ bit fields & bit arrays on a regular > basis if they were easier to use. I certainly would. I regularly waste 87.5% of the space in some arrays because I need only a boolean but I can't have an array of single bits without great pain, while memory is cheap. Of course, if the difference is a lot of memory, I will go to bit arrays (eg, mark bits for a lisp garbage collector I implemented - need one per datum, datum can be as small as 8 bytes; using one byte to mark eight seemed excessive). > This leads me to formulate a rule: any data type not easily > addressed is a 'second-class datatype' and will be avoided by > programmers. Any agreement or disagreement? Strong agreement. I even find myself avoiding long and short integers because their names are 5 and 6 characters (respectively) longer than simple integers. (Yes, I know this is not a teriffically good practice and will probably bite me someday.) der Mouse (mouse@mcgill-vision.uucp)