rentsch@unc.UUCP (Tim Rentsch) (11/18/86)
(OK, just one more note on net.lang.st80....) I know some people out there are wondering about running BS on sun-3's. For those that haven't been able to get this going, here is a hint or two. We got BS running on a sun-3 mostly just by recompiling the sources (sun-3 a.out format is different, remember?). My recollection is that this is straightforward, i.e., no strange machine dependencies. There is one thing that had to be changed. Several of the BS modules are compiled to produce assembly output, then an 'awk' script is used on the intermediate assembly (before running it through the assembler) to do some form of peephole optimization. To make a long story short, the 'awk' peephole optimization doesn't work; the reason the same thing worked on the sun-2's is that the particular optimization case never happened. (In fairness to the Berkeley people, I should say that it is my opinion that the 'awk' script does not work. But BS ran fine after I removed that step.) So, change the makefile to delete the 'awk' step on those modules that formerly used it, and things should work fine. Also, those with BS should know that the multiplication primitive sometimes fails, due to the way it is done, and how overflow is detected. (Also true on sun-2, as I recall.) The fix is to multiply A times B to give C, then see if C/B == A, since if it does then overflow will not have occurred. (Maybe I posted this before, I have forgotten.) cheers, txr
obrien@randvax.UUCP (Michael O'Brien) (11/20/86)
In article <255@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes: > >I know some people out there are wondering about running BS on >sun-3's. For those that haven't been able to get this going, here >is a hint or two. > >We got BS running on a sun-3 mostly just by recompiling the sources >(sun-3 a.out format is different, remember?). My recollection is >that this is straightforward, i.e., no strange machine dependencies. > >There is one thing that had to be changed. Several of the BS >modules are compiled to produce assembly output, then an 'awk' >script is used on the intermediate assembly (before running it >through the assembler) to do some form of peephole optimization. To >make a long story short, the 'awk' peephole optimization doesn't >work; >... >cheers, > >txr Well, I've kept the "awk" stuff; I just fix it up for each new compiler I come across. There's a test in the optimized switch statement to see if the target is > 256. Since these are bytecodes, it never is. The "awk" script is supposed to get rid of this in the two big byte-code switches (one for blocks, one for methods). It's unclear to me how much good this really does but since the switch occurs for every bytecode I've just kept it, adjusting the script for the location of the test & branch instructions. Principle of minimal fiddling and all that. There's an "asm()" in the source to stick a comment in the assembler output to mark the location of the switch code. Life got real interesting there for awhile when there was a compiler whose optimizer stripped out the comment, and the "awk" script had to locate the switch by pattern-matching the code, but that's what keeps life interesting, eh? Interestingly enough, the 3.1 and 3.2 C compilers seem to have an optimizer bug that bites these same two modules, independently of the "awk" thing. After days of boiling code down, and several go-rounds with Sun, it has been discovered that "execBlock.c" and "execMethod.c" can only be optimized by calling "c2" directly with the flags "-dcoalesce -dshorten -20", at least for Sun-3's. The last argument is obviously for 68020 stuff, but the first two arguments turn off the broken optimizations. A more serious problem under Sun OS release 3.0 is the fact that the Notifier won't let you get up-down keycodes any more, though I've heard they've had their heads bashed real good and you can do it under 3.2...I haven't seen that yet. In rage and despair I just reloaded the keyboard mapping tables for shifted, controlled, and caps-locked keymaps to be the same as unshifted, which gave me the same keycodes every time, AND unique codes for every key. I reload the maps when I exit. I will junk all of this when we move to 3.2, with a prayer of profound thanks. The multiplication fooble is news to me. Thanks, Tim! Didja ever get the process stuff in BS II to work? I just love software archaeology! -- Mike O'Brien The Rand Corporation {sdcrdcf,decvax}!randvax!obrien obrien@rand-unix.arpa
rentsch@unc.UUCP (Tim Rentsch) (11/29/86)
In article <699@randvax.UUCP> obrien@rand-unix.UUCP (Michael O'Brien) writes: > > The multiplication fooble is news to me. Thanks, Tim! Didja ever get the > process stuff in BS II to work? I just love software archaeology! No, I never did, though I did look at it for a while. The problem is, I can't figure out why it doesn't work! I am a believer in the "if you can't figure out the bug, rewrite the code from scratch" school of thought, but this never got high enough on my priority list to get rewritten. So it goes. If anyone else out there has gotten the process stuff working in BS, I would vote for a posting. (The Xerox interpreter we have has lots of systems calls but no obvious way to run a unix program -- I really miss 'unix it'. On the other hand PS has sockets, we hope to have 'rlogin' implemented soon, and as soon as we do I will give up on sun windows.) At the end of this message is the BS multiplication code diffs, for those that want it. Next message: a BS primitive for 'stat'ing files. cheers, -txr ('diff newsource/SIPrims.c oldsource/SIPrims.c' generates:) 234,247c234,236 < SmallIntegerRATest; < SmallIntegerRAConvert; < if( reg1 ){ /* if self != 0 */ < int result = reg1 * reg2; /* compute answer */ < if( result / reg1 != reg2 ){ /* if wrong answer */ < reg1 = 0x7fffffff; /* insure primitive fails */ < } else { /* else */ < reg1 = result; /* yield right answer */ < } /* fi */ < }/**** 0 * anything == 0 ****/ /* else (return self) fi */ < SmallIntegerOperationFinish; /* (done January 21, 1986 -txr) */ < /************************************************************************** < The code that failed to work correctly: (why?) < reg1 *= reg2; --- > SmallIntegerRATest; > SmallIntegerRAConvert; > reg1 *= reg2; 249d237 < ***************************************************************************/