🚀 go-pugleaf

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)