jbs@mit-eddie.MIT.EDU (Jeff Siegal) (11/10/86)
In article <9081@sun.uucp> guy@sun.uucp (Guy Harris) writes: >>[...] But I definitely want the >> next generation of desktop processors to support bit addressing. > >If you're going to convince Motorola, Intel, National Semiconductor, DEC, >MIPS, etc., etc. to put bit-addressing into their next generation of chips, >[...] I realize this has nothing to do with the issue being discussed, but let's keep the technical references accurate. DEC's current generation of processor chips (the 78032, aka MicroVAX-II) _does_ support bit addressing and manipulation. It may be an interesting question as to whether this is a good idea, so I've directed discussion to comp.arch. Jeff Siegal
guy@sun.uucp (Guy Harris) (11/10/86)
> I realize this has nothing to do with the issue being discussed, but > let's keep the technical references accurate. DEC's current > generation of processor chips (the 78032, aka MicroVAX-II) _does_ > support bit addressing and manipulation. The MicroVAX-II supports the *bit field instructions of the VAX*. This is *not* the same as supporting "bit addressing". Does the MicroVAX-II have the ability to do a "movl" to an arbitrary *bit* boundary in memory? A "movc5" to an arbitrary *bit* boundary in memory? Unless it's got a whole set of bit-boundary instructions (i.e., unless they've added a bit-boundary version of most of the instructions it supports), it doesn't support "bit addressing" in the general sense. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
pec@necntc.UUCP (Paul Cohen) (11/11/86)
On the subject of bit addressing, NEC's new V60 and V70 microprocessors come very close to full bit addressing. In particular, bit-string operations can move, search or perform primitive logic operations on strings of bits starting at any bit in the virtual address space and ending up to 4 giga-bits later. Additional bit-field and bit operations are available, but for these instructions the bit address must be formed using a bit offset of no more than 32 from a designated byte. The bitstring operations have no limitation on the size of the offset. On a related subject, are there any strong feelings out there about whether a high level language like C should support bit addressing? For example, what about arrays of bits? This would seem to be very useful at least for graphics applications. K & R, not to mention the proposed ANSI C standard have nothing to say about the permitted size of bitfields. Does anyone know of a C compiler that supports bitfields in excess of 32 bits?
jbs@mit-eddie.MIT.EDU (Jeff Siegal) (11/11/86)
In article <9116@sun.uucp> guy@sun.uucp (Guy Harris) writes: >[...] >The MicroVAX-II supports the *bit field instructions of the VAX*. This is >*not* the same as supporting "bit addressing". Does the MicroVAX-II have >the ability to do a "movl" to an arbitrary *bit* boundary in memory? >[...]it doesn't support "bit addressing" in the general sense. In the general sense, no, but you can move any string of up to 32 bits from any bit boundry in memory to any other. I don't see the difference between this and a movl to any bit location. It is certainly much different than having to read memory in byte (or word) boundries and do shifts. Jeff Siegal
hansen@mips.UUCP (Craig Hansen) (11/12/86)
> >>[...] But I definitely want the > >> next generation of desktop processors to support bit addressing. > > > >If you're going to convince Motorola, Intel, National Semiconductor, DEC, > >MIPS, etc., etc. to put bit-addressing into their next generation of chips, > >[...] > One reason to avoid bit-addressing is that it uses up three more bits of addresses, pointers, offsets, etc. Given a 32-bit word-size, which can be reasonably expected to be the norm for some time, and that the IBM XA conversion (as well as the 68010->68012/68030 conversion) indicates that 24-bit addressing isn't nearly enough, those three bits are remarkably precious. Of course, one can use word- or byte-address pointers with bit offsets, but that isn't quite the same thing as a simple linear bit-address, and is harder to manipulate. -- Craig Hansen | "Evahthun' tastes MIPS Computer Systems | bettah when it ...decwrl!mips!hansen | sits on a RISC"
mouse@mcgill-vision.UUCP (11/23/86)
In article <3853@mit-eddie.MIT.EDU>, jbs@mit-eddie.MIT.EDU (Jeff Siegal) writes: > In article <9116@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> Does the MicroVAX-II have the ability to do a "movl" to an arbitrary >> *bit* boundary in memory? Yes, but it's called INSV. Look it up. > In the general sense, no, but you can move any string of up to 32 > bits from any bit boundry in memory to any other. I can't see any way of doing this without using a longword-aligned intermediate stopping place (such as a register). How? > It is certainly much different than having to read memory in byte (or > word) boundries and do shifts. It is. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu [USA NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode]
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/24/86)
In article <3853@mit-eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes: >In article <9116@sun.uucp> guy@sun.uucp (Guy Harris) writes: >>The MicroVAX-II supports the *bit field instructions of the VAX*. This is >>*not* the same as supporting "bit addressing". >In the general sense, no, but you can move any string of up to 32 bits >from any bit boundry in memory to any other. I'm surprised Guy didn't jump on this (or did we just miss it?). The Vax EXTV/EXTZV and INSV (and CMPV/CMPZV) instructions go between an arbitrary string of 0-32 bits and a byte-aligned longword of 4 8-bit bytes. Not the same as any 0-32 bits to any 0-32 bits. If I want to move bits 4-19 of word 10 to bits 5-20 of word 14, I'd have to do an EXTZV/INSV pair, clobbering a longword somewhere in memory (or a register) as a temporary holding place. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)