eliot@cs.qmc.ac.uk (Eliot Miranda) (01/21/89)
There is a problem with the bfins instruction on SUN 3/60s using a CG4 frame buffer. Here's a message to comp.sys.sun outlining the problem in detail: >> Path: qmc-cs!icdoc!ukc!mcvax!uunet!ncrlnk!ncrcae!hubcap!gatech!purdue!mailrus!cornell!uw-beaver!rice!sun-spots-request >> From: spaf@purdue.edu (Gene Spafford) >> Newsgroups: comp.sys.sun >> Subject: Help! Sun 3/60+CG4 strangeness >> Message-ID: <5832@medusa.cs.purdue.edu> >> Date: 19 Jan 89 02:58:27 GMT >> Sender: usenet@rice.edu >> Organization: Department of Computer Science, Purdue University >> Lines: 51 >> Approved: Sun-Spots@rice.edu >> Original-Date: 14 Jan 89 04:19:14 GMT >> X-Sun-Spots-Digest: Volume 7, Issue 111, message 8 of 18 >> >> Here's a really strange problem I'm having. Any ideas or suggestions will >> be greatly appreciated! >> >> First, let me set the scene. I'm working on putting in speedups to the >> X11R3 server. I'm working with my "Purdue" speedups, and I'm merging in >> some new ideas and the "PurduePlus" speedups. So far, so good. People >> all over the country are using these changes on their systems and they >> work great. However, on some systems, the screen suffers severe bit rot. >> Some extensive debugging and enquiries reveal the following: >> >> * The bitrot only appears on Sun 3/60+CG4 combinations. The same code on >> 3/60+BW2, 3/50+BW2, 3/50+CG2, and 3/100+CG4 behaves perfectly. It appears >> to be OS independent, but I have no way to be 100% sure. >> >> * The bitrot occurs when trying to execute a "bfins" instruction into a >> location in the frame buffer. >> >> * If the destination field is some set of nibbles (bytes) like: >> 12345678 ABCDEFGH >> and the destination is the bytes 45678ABC, then the insert goes fine, but >> nibbles 1 & 2 also get trashed in seemingly random ways (I can't discern a >> pattern). The destruction is always to the first 8 bits, the stores are >> always offset more than 8 bits, and it doesn't always happen. >> >> * All bitfield addresses presented to the "bfins" instruction are 32-bit >> aligned. >> >> * Use of adb and trace statements show that the correct values are going >> into the registers for the "bfins" instruction -- no registers are getting >> trashed along the way. The perfect behavior of the code on all other Sun >> 3 systems bears this out. >> >> * Shift and mask instructions to those locations work fine, albeit much >> slower. >> >> The end result of all this is that the nicely tuned GCC "asm" macros in >> the modified PurduePlus package just won't work for a 3/60+CG4 combo! >> >> I'm pretty well stumped. I have tried nearly everything I can think of to >> figure out why this is happening and how I might circumvent this behavior. >> If any of you out there have any idea at all why this might be happening >> or how I can investigate further, please let me know! I've got a stack of >> server optimizations I want to try, but I need a stable server platform >> first, and I'd really like this as part of that platform! >> >> Thanks in advance. >> -- >> Gene Spafford >> NSF/Purdue/U of Florida Software Engineering Research Center, >> Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 >> Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf In ParcPlace Smalltalk-80 V2.2 & V2.3 paragraphs displayed with instances of DisplayScanner are garbled. Text display using instances of TextDisplayScanner is ok. I've kluged a fix by copying the scanCharacters:... method down to DisplayScanner & removing the primitive but this reduces performance to 1/4 of the primitive. How do I fix DisplayScanner so that it invokes the primitive as does TextDisplayScanner? -- Eliot Miranda eliot@cs.qmc.ac.uk Dept of Computer Science, Queen Mary College, Mile End Road, LONDON E1 4NS 01 975 5220
hmm@laura.UUCP (Hans-Martin Mosner) (01/23/89)
In article <807@sequent.cs.qmc.ac.uk> eliot@cs.qmc.ac.uk (Eliot Miranda) writes: >There is a problem with the bfins instruction on SUN 3/60s using a CG4 frame >buffer. Here's a message to comp.sys.sun outlining the problem in detail: > [other message deleted] > >In ParcPlace Smalltalk-80 V2.2 & V2.3 paragraphs displayed with instances of >DisplayScanner are garbled. Text display using instances of TextDisplayScanner >is ok. I've kluged a fix by copying the scanCharacters:... method down to >DisplayScanner & removing the primitive but this reduces performance to 1/4 >of the primitive. How do I fix DisplayScanner so that it invokes the primitive >as does TextDisplayScanner? As you might see from the TextDisplayScanner code, this beast first scans into a normal Form and then pushes this Form onto the screen using one BitBlt call. It would be possible to do the same (or nearly the same) for DisplayScanner. Just write a scanCharactersFrom:to:in:rightX:stopConditions:displaying: method that just calls the superclass method when displaying is false, else builds up a Form big enough to hold the characters (Form extent: ((rightX min: clipX+clipWidth) - destX) @ height), save its current destForm, destX and destY, set destForm to the newly created Form, destX and destY to 0, adjust the clipping rectangle, and call the superclass method with modified rightX. Display the part of the Form actually modified onto the real destForm at the right position, restore all variables and there you are. Take care of the combinationRule as well (best is to set it to 3 (Form over) for calling the superclass method and using the original to display the scanned Form). For better performance you might want to use a cached Form to scan into so that the machine does not have to create and throw away thousands of little Forms. But I think this is hardly necessary. Sorry if this was so long-winded, I suspect the actual code is a bit shorter :-) Hope the information helps anyway. Hans-Martin -- Hans-Martin Mosner | Don't tell Borland about Smalltalk - | hmm@unido.{uucp,bitnet} | they might invent Turbo Smalltalk ! | ------------------------------------------------------------------------ Disclaimer: Turbo Smalltalk may already be a trademark of Borland...