Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.arch Subject: Re: What *should* architectural pointers point at? Message-ID: <3713@goanna.cs.rmit.oz.au> Date: 10 Sep 90 01:44:57 GMT References: <0887@sheol.UUCP> <0923@sheol.UUCP> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 38 > From: pauls@apple.com (Paul Sweazey) > It is obvious to most that today's computing systems would not get faster > by having the hardware support bit-level addressing, ... I'll agree with that, but not for Sweazey's reason. Computing systems wouldn't get faster if bit-level addressing were supported because some of them (such as the NS32?32) *already* support bit-level addressing. The NS32?32 series has CBIT[I] offset, base (base).[offset:1] := 0 IBIT offset, base (base).[offset:1] ^= 1 SBIT[I] offset, base (base).[offset:1] := 1 TBIT offset, base (base).[offset:1] ^= 0 all of which first do F := (base).[offset:1] Here the base can be a register (in which case offset is 0..31) or a memory address (in which case offset can be anything). There is also CVTP offset, base, dest dest := (&base)*8 + offset which converts a byte address and a bit offset to a bit address. Thus: struct { int a:2, b:1; } x; int (*p):1 = &(x.b); *p = 1; would turn into ; x at -4(FP), p at -8(FP) CVTP 2, -4(FP), -8(FP) ; p := &(x.b) SBITD -8(FP), @0 ; *p := 1 I haven't an M68020 manual handy, but I believe the bit-field instructions there could be used similarly. (The 32?32 also has bit-field instructions.) This might suggest a compromise position: a machine with 64-bit data paths and ALU, 32-bit *word* addresses, but load/store 1/8/16/32 instructions which combined a word address with a 32-bit bit offset. A 32-bit word address would let you address 32Gb. -- Psychiatry is not about cure. Psychiatry is about power.