From: pm215@watchdragon.demon.co.uk (Peter Maydell) Newsgroups: alt.folklore.computers Subject: shifting (was: Re: YKYBHTL... 1) Date: 20 Oct 1998 21:30:46 +0100 Organization: dragon cluster Message-ID: <70irtm$hpr$1@watchdragon.demon.co.uk> References: <362547ED.345CD25C@stoneweb.com> <709339$lit$1@irk.zetnet.co.uk> <70aoh4$j5@p850ug1.demon.co.uk> Reply-To: pmaydell@chiark.greenend.org.uk NNTP-Posting-Host: watchdragon.demon.co.uk X-NNTP-Posting-Host: watchdragon.demon.co.uk:158.152.121.201 X-Trace: news.demon.co.uk 908996985 nnrp-06:20356 NO-IDENT watchdragon.demon.co.uk:158.152.121.201 X-Complaints-To: abuse@demon.net Lines: 28 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!newsfeed.wirehub.nl!ayres.ftech.net!news.ftech.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!watchdragon.demon.co.uk!not-for-mail In article <70aoh4$j5@p850ug1.demon.co.uk>, Tony Duell wrote: >The PERQ (to tie in another thread) has a 16 bit barrel shifter as part >of the CPU. I was about to post something to that effect :-> >For any PERQ-fanatics reading this, it's actually a lot more complex. The >barrel shifter is also used for the raster-op graphics processor. ..which is why we're justified in putting in the hardware to make it fast; IIRC the shifter is used continuously for the bitmap copy, since the source and destination are probably not word-aligned. The graphics copy on a PERQ is *fast*. [The microcode source for the raster-op stuff is a thing of great beauty, incidentally...] >I'll leave the joys of the semi-pipeline register and read-modify-write >cycles to another time :-) Mmm. That was about the point at which I stopped reading the CPU manual; must finish that at some point :-> Theorem: there is always at least one thread on afc in to which one can insert a PERQ reference. Peter Maydell (powered up my PERQ 3a yesterday; didn't want to boot at first (dodgy hard disk?) but working fine now...) ###### From: ard@p850ug1.demon.co.uk (Tony Duell) Newsgroups: alt.folklore.computers,alt.sys.perq Subject: Re: shifting (was: Re: YKYBHTL... 1) Date: 21 Oct 1998 23:48:47 +0100 Organization: P850 User Group Message-ID: <70locf$1ep@p850ug1.demon.co.uk> References: <362547ED.345CD25C@stoneweb.com> <709339$lit$1@irk.zetnet.co.uk> <70aoh4$j5@p850ug1.demon.co.uk> <70irtm$hpr$1@watchdragon.demon.co.uk> NNTP-Posting-Host: p850ug1.demon.co.uk X-NNTP-Posting-Host: p850ug1.demon.co.uk:158.152.97.199 X-Trace: news.demon.co.uk 909011757 nnrp-03:3612 NO-IDENT p850ug1.demon.co.uk:158.152.97.199 X-Complaints-To: abuse@demon.net X-Newsreader: TIN [version 1.2 PL2] Lines: 86 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!btnet-peer!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!p850ug1.demon.co.uk!not-for-mail Peter Maydell (pm215@watchdragon.demon.co.uk) wrote: : In article <70aoh4$j5@p850ug1.demon.co.uk>, : Tony Duell wrote: : >The PERQ (to tie in another thread) has a 16 bit barrel shifter as part : >of the CPU. : I was about to post something to that effect :-> Yes, well, you're a PERQ fanatic :-) : >For any PERQ-fanatics reading this, it's actually a lot more complex. The : >barrel shifter is also used for the raster-op graphics processor. : ..which is why we're justified in putting in the hardware to make it : fast; IIRC the shifter is used continuously for the bitmap copy, since : the source and destination are probably not word-aligned. The graphics Indeed. The basic point is that the screen is an array of bits (as are the bitmaps you want to put on the screen), but accessing individual bits in memory is slow. In fact the PERQ memory is read/written 16 bits (1 word) at a time, and accessing 4 consecutive words (a quadword) is faster than doing 4 separate word accesses. Updating 16 bits at a time is simple in theory. You just build the combiner logic 16 times. The problems come from the facts that (a) the source and destination bitmaps may not be aligned on word boundaries, and may not be aligned with each other (b) there may be bits in the destination word that are outside the area to be updated. The basic operation of the rasterop system is as follows : a) Read some words of the source bitmap into a FIFO on the CPU board. b) The output of that goes into the barrel shifter (but see below) which is set to shift it by the right amount to align with the destination bitmap. c) The destination word is read as part of a read-modify-write cycle d) The shifted source word and the destination word are fed into the combiner logic. This also takes a mask word from the control logic which causes bits outside the region to be passed unchanged, and the ones inside it to be updated. e) The updated destination word is written back to memory. All that is done by special hardware. The main CPU is used to calculate the memory addresses of the various words. : copy on a PERQ is *fast*. [The microcode source for the raster-op stuff : is a thing of great beauty, incidentally...] : >I'll leave the joys of the semi-pipeline register and read-modify-write : >cycles to another time :-) : Mmm. That was about the point at which I stopped reading the CPU manual; : must finish that at some point :-> OK... I've oversimplified a few things.. The main one is the description of the barrel shifter. It doesn't rotate a 16 bit word, it extracts a 16-bit bit field from a 31 bit word. When it's used as part of the CPU data path, that 31 bit words consists of 2 copies of the 16 bit R register. The result is therefore a simple rotate of that word. But rasterops are different. Each word of the destination area (at least in the middle of the bitmap) combines with part of 2 words of the source. THe semi-pipeline register stores the 16 bits of the previous word, which are then stuck alongside the new 16 bit source word to provide the 31 bits that the shifter extracts a field from. Which half is latched? Well, that depends on whether you're going L->R or R->L, and of course the PERQ allows you to do either. : Peter Maydell : (powered up my PERQ 3a yesterday; didn't want to boot at first (dodgy : hard disk?) but working fine now...) Hmm.. A common cause of hard disk problems on the 3a is bad connections on the power cable. In particular on the in-line fuseholder if you have that fitted (it's not present on all machines AFAIK). The 3a rasterop machine is strange. IIRC it uses a pair of 29116 ALUs and a 64-bit microcode store. One of the ALUs calculates memory addresses, the other processes the data. It runs separately from the main processor (a 68020), and operates by requesting the system bus to do a transfer to main memory. Somehow it's not as elegant as the classicPERQ rasterop machine. -tony