> and then they made TTL and pMOS and nMOS and cMOS...
Don't forget DTL, RTL, etc... Boy, now I'm really showing my age :-)
> yes but what I am trying to get at is that i still need the ability to
> be able a. fetch from 0x1001 ---004 (which theoratically would be say
> 8 bit aligned since uncle Sam makes everything in banks) b. put them
in
> 1 reg. c. but still have the ability to say that i want "8 bits here
and
> 8 bits there and 16 bits there" to be different entities
In most cases you can put any allocation unit (byte, short, int, etc.)
anywhere you want. It is just that you may have a performance issue if
it is not aligned. SPARC, and PDP-11s are the only machines I can
remember, at the moment, that can generate an exception if the memory
alignment does not agree with the allocation associated with the
instruction. (I.e., trying to reference a 16 bit value from an odd byte
address.) And if I remember correctly with the PDP-11s it was more
related to the hardware/driver level.
Actually this whole discussion is a good example of why byte and short
values are falling out of favor. Since the compiler will most likely
pad the storage, why not use 32 bits. And then you most likely even
avoid having to increase the size of the member in the future.
> anyways ....thanks for your comments.. I liked it.. even if it comes
> in the era of plenty..
Yep. There was a time when 8 Kb was a lot of memory :-) :-)
BTW, Guy Harris make a *very* good point about checking with the
author of the protocol draft specification.
- Mark
