From mboxrd@z Thu Jan 1 00:00:00 1970 From: ralph@inputplus.co.uk (Ralph Corderoy) Date: Fri, 10 Nov 2017 23:58:33 +0000 Subject: [TUHS] PowerPC, bit twiddling - was Re: origins of void* -- Apology! In-Reply-To: <92767af5-6aa5-666a-4a61-4956c2dbbd74@telegraphics.com.au> References: <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com> <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com> <20171108174450.5564F20334@orac.inputplus.co.uk> <20171108212550.56005156E7D7@mail.bitblocks.com> <7wzi7wt0sc.fsf@junk.nocrew.org> <42D46D6E-46F4-49E9-A76B-360A812DBBB0@gmail.com> <92767af5-6aa5-666a-4a61-4956c2dbbd74@telegraphics.com.au> Message-ID: <20171110235833.BE2511FF9D@orac.inputplus.co.uk> Hi Toby, > It's funny you should mention "1-bit bytes" and PowerPC close > together, because the PowerPC has an architectural feature that I have > not seen discussed much - the 8 x 4 bit CR register set [...] and of > course the usual branch tests. > > I have been curious about whether a compiler could make good use of > this facility. POWER, PowerPC's predecessor, had this too, at least on the IBM RS/6000s running AIX I used. A lot of the work was performance related, so I spent much time looking at disassembly of the output of xlc, their cc. It seemed to make use of more than one CR quite often, but never very many of them. I recall thinking it could have done better. Certainly, re-doing bits in assembler allowed that to be exploited as long as one could track which CR was tracking what previous test and whether it was still valid. Perhaps the compiler's architecture, probably not written from scratch?, didn't adapt well to that possibility? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy